Feature views strategy - Giswater/giswater_dbmodel GitHub Wiki

The strategic issue for giswater is to manage filters on database and to provide all information related to the feature. As a result, views using a current_user() capability of PostgreSQL and doing lots of JOINS are defined to work with. The system architecture is:

Source tables: Here you can find the source data.

Unfiltered views: Data FROM source table JOIN ON catalogs, mapzones, etc. in order to get all the information necessary for end-user related to that feature.

Filtered views: Data FROM unfiltered views with JOIN ON filter views (v_state_*) which provide the exploitation and state selection chose by user (selector_tables) using the current_user() strategy and providing amazing filters on the fly.

Editable parent views: Data FROM filtered views with trigger INSTEAD OF with the purpose of making the view editable. Two types of parent editable views are defined (user and system) v_edit_ views: User parent views. Parent views ready to use for end-user. ve_ views: System parent views. Parent views used for system to create the editable child views (see below).

Editable child views: Views created by system, one view for each cat_feature element. Data FROM system parent views with JOIN ON system_table (man_*) and JOIN ON addfields table (man_addfields_value) in order to provide full additional information for each cat_feature.

**TIP ABOUT EDITION:** It is not recommended to edit directly the source tables because the transaction will not use the edition triggers of editable views which have loads of controls and also manage additional information related to tables and columns futher that parent table. As as result we recommend to work always with editable views, parent as well as childs in depending on what you are looking for.

Editable views are amazing to work with and transaction operations of INSERT, UPDATE and DELETE are 100% avaliable. Enjoy it!!!