Skip to content

21.9 missing field protection

Nicholas Styles requested to merge nstyles/athena:21.9-missingFieldUpdate into 21.9

Potential updates to make pixel geometry building more robust - comments very welcome.

In this model, each Xml CLOB in the geometry database gets its "VERSION" number incremented when a new field is added. In this way, access to these new fields can be protected behind a check on the version number so that it can be enforced (via exceptions being thrown) from then on that this field must be filled, even if zero/null, to avoid cases where fields are quietly being set to a default value accidentally.

Older geometry tags will still run by virtue of having an older version number, and so the accessors will return a dummy value (printing a message to DEBUG) that can be ignored as necessary in the code.

This seems to work, but there are some unexpected changes caused to step 3.0 geometries that need to be understood before this is merged. Nevertheless it would be good to get feedback on the general concept already. Also still TBD is how to apply an equivalent schema for local Xml files in development. Without this, any local Xml used will always have to obey the latest version for the schema. In principle this is not a big problem as this can be avoided by adding the necessary fields which is a rather robust situation, but people may prefer a way to work on files in the old schema without doing this.

Any thoughts @nreadiof @nova @hhayward @npetters @lmijovic @goblirsc @tstreble @ncalace @asalzbur @npetters ?

UPDATED SUMMARY

These changes now work without introducing unexpected changes for step-3-type geometries. Retesting is ongoing for step 2.2, but it was agreed that conserving step 2.2 identically while a nice goal is practically speaking not a necessary requirement if it proves difficult, as these geometries are unlikely to be revisited in any significant way.

It was also agreed that no versioning for local geometry Xml files will be implemented, meaning that local geometry developments must be aligned with the latest schema requirements from the code (i.e. include values for all accessed fields), since this was felt to be a robust situation.

Edited by Nicholas Styles

Merge request reports