Error when regenerating the warehouse

[Ghislain Hachey]

‌

[Brian Lewis]

I think this is something you will see only in development environment: and I think it relates to the grunt script ‘deploy’ which may not release the file after it has copied it.

That said, this error occurs rewriting the ‘vermdata.xml’ file held in assets_local. These days, we don’t source that indicator file from that static file: instead, it is stored on to table ‘warehouse.indicators’ when it is created, and it is read from there.

see warehouse.VermPAF stored proc.

‌

So I think the highlighted code here:

can all go.

we don't need to be concerned with maintaining or distributing vermdata.xml files in assets_local; which is a simplification.

‌

[Ghislain Hachey]

Ok, lowering priority and yes would be nice to clean up what is not needed but not urgent.

For what it’s worth, Newton did see this at least once in production. But I have ran the regenerate since and did not see it.

[Brian Lewis]

There are a lot of vermdata files in assets_local that could be deleted - but before we do we should check if some of the non-current ones (palemis? etc) are stored somewhere else…

[Brian Lewis]

issue1143 branch removes the highlighted code above and refactors a little to ensure indicators are up-to-date. Specifically, there is a check in the REST endpoint api/indicators that the indicators requested have been calculated from the latest warehouse data, if not they are calculated on the spot then returned to the client.

In practice the admin/warehouse page rebuild the warehouse and then builds the indicators, so they should not get out of sync. This change will protect if the warehouse is rebuilt directly from sql.

[Brian Lewis]

task(indicators): refactor reading and creation of indicator xml files - dispense with file versions and rely on indicator tables

Resolves #1143

→ <<cset 01e3ce3c3c8a>>