… but I already found out the issue!
In the reporting liquibase
the name of the constraint contains the word “for”. The h2 database which is used by openmrs sdk thinks (and its right about that) “oh, thats the word “for” it tells me I need to do something”.
Which leads to the following error:
ALTER TABLE REPORTING_REPORT_PROCESSOR ADD CONSTRAINT CREATOR FOR[*] REPORTING_REPORT_PROCESSOR FOREIGN KEY (CREATOR) REFERENCES USERS (USER_ID) "; expected "., COMMENT, PRIMARY, INDEX, KEY, CHECK, UNIQUE, FOREIGN"; SQL statement:
ALTER TABLE reporting_report_processor ADD CONSTRAINT creator for reporting_report_processor FOREIGN KEY (creator) REFERENCES users (user_id) [42001-190]
I forked the reporting module and created a “quick’n’dirty” fix by renaming all constraints and indexes which contain “for” in their name. See my liquibase file.
Could anybody confirm the issue and its reason? @mseaton
As for the reason, I’m sure it wasn’t a good one. Likely just a silly oversight or following a poor pattern at the time.
I’m happy to see this get fixed. We’ll need to ticket it in the reporting module project. For the fix, we would likely need to:
- Introduce a new changeset that modifies the constraints (with the pre-condition that the bad constraint names are found). This will serve to fix existing installations.
- Change the old changeset to create constraints with the desired names, adding in the necessary “valid checksums” to pass for both existing implementations that have already run the “bad” changeset, and now implementations that are running the new one for the first time. This will serve to ensure things are setup correctly for new installs (eg. if running on H2 for the first time)
Does this sound right to you? Is this something you’d be willing to write up and/or contribute to?
FYI - I have gone ahead and created this ticket for this issue: https://issues.openmrs.org/browse/REPORT-767
Thank you. I am quite busy with university right now, final phase of my bachelor. I’ll take a look on monday whether if I can manage to do that or not.
I have picked up issue REPORTING-767, unfortunatley I am facing issues when trying to apply the changed liquibase to my 1.11.4 installation.
I followed this guide, but the validation of the check sum fails with the following error:
INFO 6/14/16 7:31 AM:liquibase: Reading fromliquibasechangelog`
WARN - ModuleFactory.startModuleInternal(792) |2016-06-14 07:31:28,245| Error while trying to start module: reporting
org.openmrs.module.ModuleException: Unable to update data model using liquibase.xml. Module: Reporting
Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
11 change sets check sum
liquibase.xml::reporting_report_design_1::mseaton is now: 3:fb024ffca387bb2cd2660ef5d6eeaf74
liquibase.xml::reporting_report_design_2::mseaton is now: 3:53d4d52a5348199bf50072c6cc9f03e2
liquibase.xml::reporting_report_design_3::mseaton is now: 3:ca73c1e4449d80ada271cb7987723311
liquibase.xml::reporting_report_design_4::mseaton is now: 3:e557ea83775089ed9e636768b25de9a0
liquibase.xml::reporting_report_design_5::mseaton is now: 3:fb616e6539c63bb47adb1ca2465eb144
liquibase.xml::reporting_report_design_resource_1::mseaton is now: 3:da8a85bfc5a5df8e63a21cb42114aed8
liquibase.xml::reporting_report_request_1::mseaton is now: 3:bd87291005df8dff187cd2aa94f343cc
liquibase.xml::reporting_report_processor_1::mseaton is now: 3:779193b8124f3299601ca74ff7699dfe
liquibase.xml::reporting_report_processor_4::mseaton is now: 3:f0db0f44c0b4b4f7af9df45394564e71
liquibase.xml::reporting_migration_1::mseaton is now: 3:cbbf303e451a8f87493a891520ed42f4
liquibase.xml::reporting_migration_2::mseaton is now: 3:530b605a2c3035b9c9b996783897601a
... 2 more
As you can see in my branch REPORT-767. I added the correct new changeset checksums. What may I be doing wrong?
Someone else reported the same issue on the wiki page. A couple of years ago.l…
I also found this old discussion of @dkayiwa @lluismf and @wyclif . Or maybe @darius may help, as he created the wiki page.
Thanks in advance!
Most probably you did run the snapshot version of the module while these changesets were being changed. If you are not on a production server, you can just delete changesets with these ids from the liquibasechangelog table.
Could you make clear for me, what you mean by “you did run the snapshot version of the module” I know what a snapshot is, but why should there be a difference about snapshot releases?
Thank you for the hint of deleting the changeset sums form the table, of course this would do for me, anyway:
@mseaton suggested to alter the liquibase file in a way, that it works on existing and new installations. But the “delete changesets with these ids from the liquibasechangelog table” approach would hurt the “existing installations” constraint.
This deleting of changesets is for you as a developer. End users do not have to do so because they do not run snapshot versions of the module. In summary, a changeset can be changed during development, hence affecting other developers who may be using the snapshot version, as in your case. But once released, the changesets are normally not changed.
@bgevam, is your code committed somewhere? Are you sure you put the right valid checksum on the changeset? I think you need to make sure the checksum that is reported to you back in the error message is the one included.
As for what @dkayiwa is saying, if you are developing a changeset and you keep tweaking it as you develop it, you will need to delete from the changelog as you go, as each tweak you make to your new code will invalidate the previous checksum you ran with. He’s not saying that you should delete from the changelog table for final testing - just that you might be hitting this issue during development if you are making iterative changeset changes.
thanks for the reply!
yes, as stated above, the commit is in my branch REPORT-767