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.

image-20240110-043333.png
View Showing Select Columns From public.graffiti.

The view’s geometry_columns metadata entry is as follows.

SELECT * FROM public.geometry_columns WHERE f_table_name = 'vw_graffiti';
image-20240110-011256.png
Geometry Metadata Entry for 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 spatialEnginetable 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.