adapt maintenance event view

[3nids]

fixes #33

Now 3 views are created:

• one big view (similar to reach/cover) with the 3 subclasses (I added the prefixes)
• 3 views: vw_maintenance, vw_examination and vw_bio_ecol_assesmement

[ponceta]

OK for me on the technical POV.
@sjib does this approach fits the requirements from VSA? (I think so)

[sjib]

vw_maintenance.yaml should be renamed to vw_maintenance_event, as the supclass is called like this.

I suggest the following naming convention:

• subclass views that integrate the superclass attributes are named vw_subclass. Also the corresponding yaml should be named like this
• views of a superclass that integrate all subclass attributes with prefixes to the attributes of the subclass should be named vw_superclass - here vw_tww_maintenance_event . Also the corresponding yaml should be named like this
• Bigger views that include several tables should be named vw_tww_xxx - xxx beeing the focus class like vw_tww_reach or vw_tww_wastewater_structure.
• Can we integrate this in the Developers Guide when agreed on: https://github.com/teksi/Home/wiki/TEKSI-Developer-Guide#views

[sjib]

@ponceta @urskaufmann Is this in line with your thoughts?

[ponceta]

My proposal for naming convention and views :

Views

ALL views are created in the txx_app schema.
Scripts are store in the datamodel/view folder. The corresponding scripts should be named accordingly (.sql,.yaml,.py).

Naming convention :

• subclass views that integrate the superclass attributes are named vw_subclass. (example: vw_maintenance)
• superclass views are named vw_superclass. (example: vw_channel)
• BIG superclass views (superclass views that integrate all subclass attributes with prefixes to the attributes of the subclass) should be named vw_txx_superclass (example: vw_tww_maintenance_event).
• Extension views are prefixed with there extension name (example : swmm_vw_conduits)

Warning :
We strongly discourage users to create views referencing other views. This can lead to overly complicated upgrades when dealing with datamodel alterations (postgreSQL locks).

[sjib]

@ponceta thanks for this suggestion

superclass views are named vw_superclass. (example: vw_channel)

channel is a subclass of wastewater_structure. So we would need to change this example.

What would be the difference of a superclass view and a BIG superclass view?
e.g. maintenance_event is a superclass. What would be the difference between the superclass view of it vw_maintenance_event (not clear to me) and a BIG superclass view vw_tww_maintenance_event (as described above: superclass views that integrate all subclass attributes with prefixes to the attributes of the subclass) should be named vw_txx_superclass)?

[ponceta]

• superclass views are named vw_superclass. (example: vw_channel)
  channel is a subclass of wastewater_structure. So we would need to change this example.

I thought of vw_channel being a superclass of reaches but it is not. I've no diagram of the 2020 Model but it would be a nice thing to add.

What would be the difference of a superclass view and a BIG superclass view?
e.g. maintenance_event is a superclass. What would be the difference between the superclass view of it vw_maintenance_event (not clear to me) and a BIG superclass view vw_tww_maintenance_event (as described above: superclass views that integrate all subclass attributes with prefixes to the attributes of the subclass) should be named vw_txx_superclass)?

Actually we don't have created views for superclass (we use the table directly : wastewater_structure, organisation, ... so if needed these views would be called vw_wastewater_structure, vw_organisation, ...) I'm not sure there is any advantage of using this kind of views.

I think the vw_txx_superclass / vw_txx_focusclass are mainly views we use in modules to avoid complexity on the client side with multiple joins which can be tricky in terms of performance. The txx syntax being here to remind the user of a potentially complex mechanic running in background?

[sjib]

Good from my side and good discussion for conventions that should be integrated in the Developers guide

[sjib]

I have now added this version to the developers guide with all conclusions:

Views

ALL views are created in the txx_app schema.
Scripts are store in the datamodel/view folder. The corresponding scripts should be named accordingly (.sql,.yaml,.py).

Naming convention :

• subclass views that integrate the superclass attributes are named vw_subclass. (example: vw_maintenance)
• superclass views (superclass views that integrate all subclass attributes with prefixes to the attributes of the subclass) should be named vw_txx_superclass (example: vw_tww_maintenance_event).
• dito big views that integrate other classes like the main views vw_tww_reach and vw_tww_wastewater_structure that JOIN together a series of related classes.
• other class views are named vw_class (if ever needed).
• Extension views are prefixed with their extension name (example : swmm_vw_conduits)

[3nids]

I thought of vw_channel being a superclass of reaches but it is not. I've no diagram of the 2020 Model but it would be a nice thing to add.

@ponceta I've added a schemaspy generation in the CI. If you look in the artifacts of the create dumps workflow (e.g. https://github.com/teksi/wastewater/actions/runs/7112177922), you can download it.