Current continuous integration fails to detect differences in value lists

[haubourg]

Work in #qwat/qwat-data-model#268 (comment) shows that if a delta files loads value lists but is not inlined with generation scripts, Travis fails to catch those differences.

The check is done by PUM which only check database structure (tables, views, functions, triggers, constraints, etc) but not value list.

In QWAT, we can consider that some value lists are part of the core and should be controlled by continuous integration.

However, local customisation and extensions can add value lists, so we need to handle this case.

We could add a type field to value lists to track their origin (custom, core, extension) and check only core and extensions in Travis.

This could be done in the sh wrapper files, or maybe pushed upstream in PUM.

[haubourg]

@elemoine @lbartoletti @tudorbarascu @3nids @marioba @ponceta

Any opinion on that?
Arnaud, I think this deserves some work to avoid nasty issues. I let you see if we schedule that in a PSC.

[marioba]

Hi @haubourg,
I'm not sure I understood correctly the problem.

In qwat, you create value lists such as qwat_vl.pipe_material. If I'm not mistaken, these are considered actually as tables by PUM and then pum check shows the possible lack of the table.

Would you like that PUM is able to show the difference also on the content? E.g. when a value is added to pipe_material? Is what I say correct?

[haubourg]

@marioba Hi Mario, yes the actual lack is content checking. We have add one PR changing core value list and adding deltas that lead to different contents in migration process but Travis didn't catch the difference.
I just raised the issue, but we have no time allocated yet. @elemoine would be hot on proposing a pull request to PUM if we get funded. I'll keep you informed.

[elemoine]

Hi @marioba. Yep, seconding what Régis said. Value-lists tables belong more to the structure of the database, rather than its content. So the idea would be to extend Pum to make it possible to pass pum check (and pum test-and-upgrade) a list of tables whose contents should be checked. I think that would make sense to add this to Pum, and I'd be happy to do it :)

[marioba]

Hi @elemoine, yes, I think it's a good idea.

[3nids]

The distinction in qwat for custom VL should be that id > 10'000.
I like the idea of integrating content checking. But going to the point of introducing a customizable rule to determine which line should be check is too much.
I would be more inclined on implementing customizable tests that we could subclass in Python which would be cleaner and more flexible.