Set audit sql

[ponceta]

Set audit sql for history viewer

Fix #246

[cymed]

The example with tww_app poses a problem for CI

[ponceta]

The example with tww_app poses a problem for CI

My main concern is :

Is this to be included in the changelog or in the application ? Especially because we will drop the audit triggers before any application update and recreate these afterwards.

I should maybe separate the logging table creation (which has to be persistent) with the audit trigger functions (which could evolve with time but sometimes without having a base datamodel change).

[cymed]

What if we add a metadata table somewhere that we can use to re-create the triggers on the app schema?

[ponceta]

@cymed @3nids I suggest we continue discussion here :

I'm not sure I make myself clear.
I approved the PR before the addition of the hstore extension, added after and merged.
I think it is a good practice to prefer dedicated PRs for each change.
We had former discussions with Arnaud where I think we decided to have this audit functionality apart from the definition of the model. To my opinion, this should be at least optional.

• I can reset the hstore extension status and integrate in this PR too keep track of why we have to have hstore as extension

• As discussed, this functionnality is optional for the user / BUT the implementation stays as it is in QWAT and QGEP. (otherwise I won't be able to push a Release)
  Meaning

• if the user wants to activate the logging, he has to set :

SELECT tww_sys.audit_view('tww_app.vw_tww_wastewater_structure', 'true'::BOOLEAN, 'field_to_ignore'::text[], 'obj_id'::text[])

https://github.com/teksi/wastewater/pull/249/files#diff-a0a816e4d5f6f64e6bcedba2a5c4f030afb95e787cb7046293737931c1d96387R286

As documented in https://teksi.github.io/wastewater/fr/user-guide/history/history.html#database-configuration.

[ponceta]

[3nids]

I'm -1 on integrating such an old piece of code in a brand new solution as is. I think it would deserve first a point of situation on other solutions to avoid going with custom code here.

If you still want to move forward with, I think the trigger should lie in app at least.

[3nids]

you should not create stuff in tww_sys from app!

[cymed]

Better move audit function into changelogs

[cymed]

I'm -1 on integrating such an old piece of code in a brand new solution as is. I think it would deserve first a point of situation on other solutions to avoid going with custom code here.

If you still want to move forward with, I think the trigger should lie in app at least.

For many end users, the functionality is necessary in production and we can't simply drop functionalities without notice. It is up to the technical group to decide if the functionality needs an overhaul or not. I suggest migrating it as it was and if needed overhaul it in a second step.

[ponceta]

I agree with both of you :

• We need such a functionnality
• It would be much easier to level it to a new standard, this will not be trivial to upgrade afterwards

@3nids I check with you how and what we could support in this new module architecture.