Condition Domain Object Table name

Hello all,

We are currently working on the core data model and we have created a table to support the condition domain object. We have named it condition table. However, “condition” is a mysql keyword. We cannot use “conditions” because it is already used by the emrapi module.

This is a call for suggestions on what to do.

@dkayiwa @darius

By convention module tables should be namespaced i.e. should have the module id as a prefix but I guess because the eventual goal was to move that code into core at some point therefore it was intentionally named conditions, with that in mind I’d think that it should be safe to add an extra liquibase changeset that renames the module’s table to add the moduleId prefix and should precede the one that creates the conditions table in core.

Just out of cusiority, why was it necessary to create a new table in core? Was there no way to just modify and continue using the module’s table in core? That way there would neither be the need to create a new one nor migrate any data.

Is it possible to modify the emrapi condition table purely using liquibase to get it to the state of the desired core table? Or is there any data that needs the Java API to be able to migrate?

(I know that for diagnoses I’ve been pushing to use the Java API to do the migration after things have started up, but I don’t remember about the condition table.)

From my checks, it is possible to modify the emrapi condition table purely using liquibase to get it to the state of the desired core table.

Then I think that’s what we should be doing rather than introducing a new table.

@paradise, have you all already implemented the migration code? (I remember discussing this on talk, but maybe it was for diagnoses, not conditions…)

The scenario here is a bit tricky:

  • The emrapi module has a “conditions” table, which was intended by its authors to get migrated to core
  • but some step in the process got missed, because when we were analyzing TRUNK-5015 we didn’t realize the emrapi table was called conditions.
  • therefore we weren’t strict about ensuring that design for TRUNK-5015 is strictly compatible with what was done earlier in emrapi
  • However, reviewing this previous thread, I think things are pretty safe: Migrating existing condition data captured via the emrapi module

In other words, yes, do what Wyclif says and use “conditions”, but you’ll need to handle the case where that table might already exist from the emrapi module, so your liquibase changesets and preconditions may look more complicated than usual.

Keep in mind that not everyone running OpenMRS will be running the emrapi module (it’s not included in the basic Platform download, for example), so I think you’re going to need to have two sets of liquibase changesets (or some conditional ones) depending on whether the table exists already or not.

The changesets should be such that if the table exists (the module was installed before) execute the changesets that modify the existing table and data migration otherwise run the changeset that creates the table.

@darius I had already implemented the migration changeset for the condition object.

However, I would revert that. @wyclif explanation is clearer and I would implement that.

@paradise when you’re done do you mind sharing the pull request with the changeset so we can take a look.

Here is the pull request link https://github.com/openmrs/openmrs-core/pull/2662

@dkayiwa @darius @wyclif