Use single sequenced PK for PartyIdentification with history

[jenshp]

Change primary key definition for PartyIdentification, allowing a history of Ids to be retained, as well as supporting several Ids for one party.
See also related pull requests in repositories mantle-usl and SimpleScreens.

[jonesde]

A couple of years ago I would have been more willing to just do this and not worry about breaking backward compatibility (other than noting it in the release notes). At this point there is much more significant impact on users of Mantle for changes like this (especially since the 2.1.0 release series).

Going forward I don't want to do this sort of data model change without some sort of automated way to update existing databases, along with very clearly communicating that to update clusters need to be completely shut down and the DB update done (automated on startup of a single instance, or done manually while all app servers are down) before bringing clusters back up. This is the sort of model change that requires maintenance downtime.

Currently the only automated database meta data changes are for missing tables, columns, etc. There has been some discussion of using Liquibase for things like this, but what we need is really the opposite of Liquibase which only works well when live databases are maintained from the beginning with Liquibase given it's forward through time only change sets. What I mean by the opposite is for things like this we need some way to specify prior vs current entity definitions so that if a current database table definition doesn't match the current entity definition it knows what to do with it based on prior versions of the definition of a particular entity.

In this case it needs to know not just that a column needs to be added for the partyIdentificationId field but also that it needs to be populated with sequenced values. It also needs to know that after doing so the primary key constraint on the table needs to be removed and a new one added with the single column PK. Adding the fromDate and thruDate fields isn't an issue, ie no backward compatibility concerns or issues with old and new code on different server instances running against the same database.

[acetousk]

Should this be closed?

[jonesde]

I don't think it should be closed, some solution is likely needed for certain use cases (multiple ID values for a given type). One solution might be to do what was done with ProductIdentification and ProductOtherIdentification. One downside of that approach is having ID values in multiple tables, but one upside is having a structure with a forced single value for an ID type and another that allows multiple.

For history on PartyIdentification it might worth adding an audit log to it.