How entities should handle data model customizations?

[ponceta]

• Keep model evolutions scripts to be able anytime to regen the custom data-model
  (actually these ones are missing for Pully's demo data but I could provide part of these scripts)
• Document these scripts, how, what elements to consider?
• Where and how to store these?
  (considering model upgrade validation, this should be taken into account since data model initialization should be able to take these into account. How means what naming should be set to be qwat compliant?)
• What naming conventions should be used for data model customizations? tables prefixes or schemas?
• Enhancing value lists should consider a number rule to avoid conflicts with qwat base datamodel (Should custom values in the qwat_vl schema tables start from id 10000 on? #122)

These aspects should be all explained in the data manager documentation.

• Add value
• Add field
• Add table
• Add trigger
• Add type
• Add rule
• Add view

[haubourg]

Another requirement discussed with @sylvainbeo : local customization scripts should also be injected in the conformity version testing scripts. Beyond naming convention, we should reserve versionning namespaces or numbers.

[haubourg]

So we took advantage of PUM to test the customization logic, as discussed at the PSC last week

From what we see, a very simple option would be:

• allow only one unversionned local cutomization file
• play all the core update as today using PUM
• at the end, drop all the views, apply the unique local SQL file, recreate views. This can be done outside of the PUM, but it could probably be leaner if PUM could do that.

Another point found is that most frequent customization are value list insert / delete or update for labels / translations.
Running a QWAT specific step to display those value list changes would be nice too.

@3nids @m-kuhn . Any opinion?

[m-kuhn]

Let's consider some examples:

• An added field
• An added table
• An added view
• An added trigger

I guess most of the customizations are additions like this.
What would the local customization logic look like in this case?
I guess most of them would need nothing at all, (added tables, and fields will just be kept unless incompatible upstream changes land), for the views, it will probably also require a second script to kill the views before starting the pumpdate, for triggers as well.
For additional values I'd also say, they will be just kept without requiring migration logic (99% of the time at least). For removing values, I'd discourage people and add a disabled flag to value lists if this is required.

[ponceta]

@m-kuhn Miss an added schema, an added group_role, an added rule, an added type. With that we should be exhaustive?

Edit: set group_role instead of role after @haubourg's comment.

[ponceta]

With these rules and guidelines, any organization should be able to be "PUM compliant"!

[haubourg]

@ponceta about ROLES, I think we should only check "group" roles, ie those with NO LOGIN option. The connection roles will be too much variant (imagine you connect a LDAP to PG, they change virtually at any moment).

[ponceta]

Documentation is here:

https://qwat.github.io/docs/master/en/html/developer-guide/local_customizations.html

I keep this open until 1.3.3 Release and deployement in Pully.

[lbartoletti]

@ponceta should we leave this issue opened?

[ponceta]

@lbartoletti I miss Custom values in the value lists customization the #122

We agreed with @tudorbarascu and @3nids on this in 2016.

@kandre thoughts?

Can I add it in the documentation too?

[ponceta]

And Pully is up to date on QWAT 1.3.3 (freshly updated to postgres 9.6)