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.
/ cc: @mksd, @mogoodrich, @dkayiwa
uuid field was not originally part of the data model. It was added in OpenMRS Core version 1.5
After which, modules followed the pattern of adding it. This looks like an obvious miss. Therefore, i vote YES to your suggestion. https://tickets.openmrs.org/browse/TRUNK-2448
Opened ticket at:
@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.
Opened Pull Request at: