I’m working on adding new domain and implementation for AutoGenerationOption, the practical challenge I have encountered with the current data model is bootstrapping an existing option since the AutoGenerationOption doesn’t have an identifier apart from it’s internal id(Database PK). This domain being an OpenmrsObject, I would except it to have a uuid, was this by design or we just missed out adding the uuid property to the hibernate mapping?
I also found this:
The above looks too hacky
My suggestion is adding full support of a uuid property like any other OpenmrsObject and maybe later, expanding the Service layer to retrieve instances by the property.
@samuel34 This is a good catch! We probably should also have a strategy to fill in UUIDs for existing AutoGenerationOption instances (the data model usually allows the UUID to be blank, even though, in practice, its usually set via Java code). I think I just got through telling someone not to worry about migrating UUIDs in Postgres, but there are examples where similar things have been done in the core liquibase files.
Yes, agreed! AutoGenerationOption was probably created prior uuid’s existing, and we should add them in at this point.
And as @ibacher says when we made this change we should add a liquibase changeset (or other mechanism) to assign a UUID to any existing entries in the auto generation option table.
