Overriding the Edit Object
It is possible to override the database object (accessed through an entity and a spatial mapper) that Weave will update when the user submits a spatial edit. This helps when working with views that can't be updated but the table that underlies the view can be.
The database view we will use in this section is defined as follows.
DROP VIEW IF EXISTS public.vw_graffiti;
CREATE VIEW public.vw_graffiti
AS
SELECT ID,
DESCRIPTION,
REPORTEDBY,
TO_CHAR(REPORTEDON, 'DDth Month YYYY') AS reportedon,
GEOM
FROM public.graffiti;
SELECT *
FROM public.vw_graffiti
WHERE id = 1;
The data for id = 1
visible in the view is as shown.
public.graffiti.
The view’s geometry_columns
metadata entry is as follows.
SELECT *
FROM public.geometry_columns
WHERE f_table_name = 'vw_graffiti';
vw_graffiti.
Firstly we create an entity and spatial mapper for the vw_graffiti
view which our primary edits will be focused.
<entity:entity id="v.graffiti" label="Graffiti" />
<!-- Create mapper that points to the view -->
<mapper:mapper id="me.v.graffiti">
<spatialengine>se.postgresql</spatialengine>
<mapping entity="v.graffiti">
<table>vw_graffiti</table>
<key>id</key>
</mapping>
</mapper:mapper>
To visualise this vw_graffiti
based data we need to create a mapengine (me.view
), modify the table of contents (toc.main
) to include an entry for vw_graffiti
, then add me.view
to the client XML.
The relevant part of the client XML which is modified to include the me.view
mapengine is:
The client should now look like this.
Now, an example of how the view cannot be used to insert a new graffiti record is shown as follows.
We can’t insert a new record because the reportedon
column in the public.graffiti
table is not directly accessible via the view.
To tell Weave to update a different table than vw_graffiti,
an edit configuration needs to be created in which a spatialEngine
, table
and key
are defined.
To create a new graffiti point using the view, first we set the Graffiti (View) entity active.
Then we can create a new graffiti point via the Graffiti (view) edit configuration as follows:
Checking the database shows that the record has been successfully written to the Graffiti table.
The inserted data is now visible via the view.
Editing via a view can also be implemented at the database level via what is known as an “INSTEAD OF” trigger.
An INSTEAD OF trigger, say for insert, is fired when Weave creates (inserts) a new entity through the view.
The trigger, when fired, could grab all the values supplied with the view’s attributes and write them to an associated table. It could also compute additional column values e.g. audit values, polygon areas, etc. (Once the INSTEAD OF trigger terminates, no values are written to the view.)
This example shows the power of combining Weave processing and/or database processing.