Links Workflows - Giswater/giswater_dbmodel GitHub Wiki

The system architecture is:

This workflow acts in combination of stored procedures and trigger functions in order to solve links management acording this rules:

  • Links are one giswater object. They can be inserted with a button, they have their own state independent of the state of their connect. Some rules need to be followed according state topocontrol issues
  • Only one link with state=1 for one connect with state =1
  • As many links as you like wiht state =2 or state=0 for each connect.
  • Links are filtered as same as other giswater objects using selectors strategy.
  • On plan strategy the key is the pair againts connect_id - arc_id stablished in the table plan_psector_x_connect. For each connect in each psector a new link is created. This can be created manually or automatically.
  • Automatic if the variable is activated, searching for the specified arc_id or copying the one in service if it exists (connect2network). Then it can be modified and taken wherever you want.
  • For connects, on operative state values of mapzones attributes and pjoint are showed from source table as well as on planned are this values re showed from link table by join againts connect.

Performance issues

  1. Links will cause impact on v_edit_connec and v_edit_gully because of join to propagate mapzones and pjoint's (solved by using only on state = 2)
  2. Links with state = 2 may cause an impact for themselves because concanetation of UNION & EXCEPT, specially for UD (solved by using active column and separate gully-connec)

Future improvements, if are need for large projects

Step 1: Remove join links againts connects. This creates disconnection of mapzones and pjoints propagation, reducing usability for undestanding planned objects Step 2: Do not use plan for connecs & gullys