As we are in the upgrade process from Ref App distro 2.2 to 2.3, I realised that one of our HFE forms would not load anymore because of a missing concept mapping.
After a lot of digging, it appears that the Reference Term behind the mapping is in fact gone after I start the Ref App distro 2.3 on our production database. I could point it out to openmrs-module-referencemetadata 2.3.1 (and later), that is in fact the culprit module.
Would anyone know where/how this module would delete Reference Terms that may exist in the database before it is started?
I am afraid it may delete more than what I could obviously see so far…
@mksd, concepts and mappings in Reference Application come from the CIEL dictionary and are loaded by Reference Application in a way that guarantees an easy path to upgrade to the full CIEL dictionary using SQL script. It means that database IDs must match those in the CIEL dictionary, thus any local rows may be overwritten if they use the same IDs, which most likely happens in your case.
The key takeaway is that managing concepts locally in Reference Application is currently not supported. The way to introduce changes to the concept dictionary is to upgrade to the full CIEL dictionary and send requests to Andy to add your changes so that you can import them with the next CIEL release.
The question is if you can change the approach and get rid off your local changes at this point.
(I say ‘obvious’ because I am afraid there may be others, but, if any, their effects haven’t been observed yet.)
As I said, our module’s activator adds a few concepts and mappings initially, then this code is never run again since the target database already carries the changes. Through doing this a Concept Reference Term ID’d 278819 was created… and hence overwritten by Reference Metadata’s activator through processing the above line of its XML resource.
It is actually not that easy for me to change our code since the mappings are created alongside with the concepts, so I would need to separate all that… etc.
(Q) Anyway my question is, as much as I understand that it could be necessary to ensure the existence of specific concept IDs (for the CIEL CD for instance), why does it ever matter to hardcode the Concept Reference Terms IDs?
Surely those IDs are never used anywhere in forms and such and could just be generated by Reference Metadata when it creates those terms based on the XML data. Or, if any piece of code should ever point to a specific Concept Reference Term then it should use its UUID and not its ID, but does this even ever happen?
We have to hardcode Concept Reference Term IDs as they are distributed with the CIEL sql script, which is basically a dump of all concept_* tables. If ids in any table do not match those in the sql script then it cannot be easily imported.
Maybe you could adjust your code to create concept reference terms and concepts with IDs of a very high value so that they do not conflict with those from CIEL dictionary?
Well, those are already used in a production database, they were generated 5 months ago…
Is this still possible to change those IDs?
That sounds strange to me. So if someone was to create a concept mapping manually through the admin interface, they would be at risk that eventually the underlying auto-generated ID could be overridden by Reference Metadata at some point?
Customized metadata has this kind of risk. One possible solution without adding extra columns is to determine a range of IDs provided the product (e.g. 1 - 1M product, >1M custom).
I went back to this issue and, as I currently can’t spend much time on this, I would like to know if in your opinion fixing the module version to referencemetadata-2.3.omod would cause any troubles?
As a reminder, it is the upgrade to version 2.3.1 that starts causing deletions of our custom metadata (hence the choice to remain for now on version 2.3.)
P.S. FYI the tag 2.3 of openmrs-module-referencemetadata doesn’t build anymore.