O3 Distribution | Reference Application 3.0.0-beta.18 | Cohort Module error

I was setting up OpenMRS using the SDK.

Options I selected:

  • O3 Distribution
  • Reference Application 3.0.0-beta.18
  • MySQL

I am using OpenJDK 17.0.10.

Error starting Module - Cohort Module
close
Error while trying to start module
Unable to update data model using liquibase.xml. Module: Cohort Module
WARN - ModuleFactory.startModuleInternal(783) |2024-04-30T07:55:01,813| Error while trying to start module: cohort
org.openmrs.module.ModuleException: Unable to update data model using liquibase.xml. Module: Cohort Module
        at org.openmrs.module.ModuleFactory.runLiquibase(ModuleFactory.java:1002) ~[openmrs-api-2.6.4.jar:?]
        at org.openmrs.module.ModuleFactory.startModuleInternal(ModuleFactory.java:723) ~[openmrs-api-2.6.4.jar:?]
        at org.openmrs.api.context.Daemon$1.run(Daemon.java:86) ~[openmrs-api-2.6.4.jar:?]
Caused by: liquibase.exception.LiquibaseException: liquibase.exception.LiquibaseException: Unable to execute change set: liquibase.xml::add_cohort_member_attribute_20210607::corneliouzbett
        at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:124) ~[liquibase-core-4.4.3.jar:?]
        at org.openmrs.util.DatabaseUpdater.executeChangelog(DatabaseUpdater.java:237) ~[openmrs-api-2.6.4.jar:?]
        at org.openmrs.module.ModuleFactory.runLiquibase(ModuleFactory.java:994) ~[openmrs-api-2.6.4.jar:?]
        ... 2 more
Caused by: liquibase.exception.LiquibaseException: Unable to execute change set: liquibase.xml::add_cohort_member_attribute_20210607::corneliouzbett

Tried with OpenJDK 1.8, Reference Application 3.0.0-SNAPSHOT:

Now two modules are failing to start with same error:

Error while trying to start module
Unable to update data model using liquibase.xml. Module: Patient Flags Module

Hello @binokary what is the output when you run mvn -v Also had you run mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:setup-sdk before you run the openmrs sdk.

@binokary Please post the full server log using a service like pastebin. The snippets you’ve posted don’t have enough information to help you.

1 Like
$ mvn -v
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.8.0_402, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.146.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

Yes, I had run it.

@binokary your environment setup seems to be okay.

You may need to share full log.

It looks like the beta.18 runs fine on amd64. I had tried it on arm64, where it was showing the above problem with the Cohort Module:

$ mvn -v
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/apache-maven-3.9.6
Java version: 1.8.0_402, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-arm64/jre
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-1051-oracle", arch: "aarch64", family: "unix"

Here is the full log: [WARNING] [WARNING] Some problems were encountered while building the effectiv - Pastebin.com

That doesn’t make a whole lot of sense. The error from the log is:

Caused by: liquibase.exception.DatabaseException: Can't create table `openmrs`.`cohort_member_attribute` (errno: 150 "Foreign key constraint is incorrectly formed") 

Which is an issue with the syntax in the generated SQL.

The generated SQL looks like this:

CREATE TABLE openmrs.cohort_member_attribute (
  cohort_member_attribute_id INT AUTO_INCREMENT NOT NULL, 
  cohort_member_id INT NOT NULL, 
  value_reference TEXT NOT NULL, 
  cohort_member_attribute_type_id INT NOT NULL, 
  date_created datetime NOT NULL, 
  creator INT NOT NULL, 
  changed_by INT NULL, 
  date_changed datetime NULL, 
  voided TINYINT(1) DEFAULT false NOT NULL, 
  voided_by INT NULL, 
  date_voided datetime NULL, 
  void_reason VARCHAR(255) NULL, 
  uuid CHAR(38) NOT NULL, 
  CONSTRAINT PK_COHORT_MEMBER_ATTRIBUTE PRIMARY KEY (cohort_member_attribute_id), 
  CONSTRAINT cohort_member_attribute_editor_fk FOREIGN KEY (changed_by) REFERENCES openmrs.users(user_id), 
  CONSTRAINT cohort_member_attribute_voided_by_fk FOREIGN KEY (voided_by) REFERENCES openmrs.users(user_id), 
  CONSTRAINT cohort_member_attribute_type_fk FOREIGN KEY (
    cohort_member_attribute_type_id
  ) REFERENCES openmrs.cohort_member_attribute_type(
    cohort_member_attribute_type_id
  ), 
  CONSTRAINT cohort_member_attribute_creator_fk FOREIGN KEY (creator) REFERENCES openmrs.users(user_id), 
  CONSTRAINT cohort_member_attribute_cohort_member_fk FOREIGN KEY (cohort_member_id) REFERENCES openmrs.cohort_member(cohort_member_id)
)

Which looks fine to me.

I don’t think processor architecture figures into this at all. I routine run the Ref App on a Macbook M2. What version of MySQL do you have installed on the aarch64 machine? What are the contents of the my.cnf file?

1 Like

Thanks @ibacher for looking into it.

$ mysql --version
mysql  Ver 15.1 Distrib 10.6.16-MariaDB, for debian-linux-gnu (aarch64) using  EditLine wrapper
$ cat /etc/mysql/my.cnf
# The MariaDB configuration file
#
# The MariaDB/MySQL tools read configuration files in the following order:
# 0. "/etc/mysql/my.cnf" symlinks to this file, reason why all the rest is read.
# 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults,
# 2. "/etc/mysql/conf.d/*.cnf" to set global options.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options.
# 4. "~/.my.cnf" to set user-specific options.
#
# If the same option is defined multiple times, the last one will apply.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# If you are new to MariaDB, check out https://mariadb.com/kb/en/basic-mariadb-articles/

#
# This group is read both by the client and the server
# use it for options that affect everything
#
[client-server]
# Port or socket location where to connect
# port = 3306
socket = /run/mysqld/mysqld.sock

# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

I am getting the same error when trying to create the table openmrs.cohor_member_attribute:

MariaDB [openmrs]> CREATE TABLE openmrs.cohort_member_attribute (
    ->   cohort_member_attribute_id INT AUTO_INCREMENT NOT NULL,
    ->   cohort_member_id INT NOT NULL,
    ->   value_reference TEXT NOT NULL,
    ->   cohort_member_attribute_type_id INT NOT NULL,
    ->   date_created datetime NOT NULL,
    ->   creator INT NOT NULL,
    ->   changed_by INT NULL,
    ->   date_changed datetime NULL,
    ->   voided TINYINT(1) DEFAULT false NOT NULL,
    ->   voided_by INT NULL,
    ->   date_voided datetime NULL,
    ->   void_reason VARCHAR(255) NULL,
    ->   uuid CHAR(38) NOT NULL,
    ->   CONSTRAINT PK_COHORT_MEMBER_ATTRIBUTE PRIMARY KEY (cohort_member_attribute_id),
    ->   CONSTRAINT cohort_member_attribute_editor_fk FOREIGN KEY (changed_by) REFERENCES openmrs.users(user_id),
    ->   CONSTRAINT cohort_member_attribute_voided_by_fk FOREIGN KEY (voided_by) REFERENCES openmrs.users(user_id),
    ->   CONSTRAINT cohort_member_attribute_type_fk FOREIGN KEY (
    ->     cohort_member_attribute_type_id
    ->   ) REFERENCES openmrs.cohort_member_attribute_type(
    ->     cohort_member_attribute_type_id
    ->   ),
    ->   CONSTRAINT cohort_member_attribute_creator_fk FOREIGN KEY (creator) REFERENCES openmrs.users(user_id),
    ->   CONSTRAINT cohort_member_attribute_cohort_member_fk FOREIGN KEY (cohort_member_id) REFERENCES openmrs.cohort_member(cohort_member_id)
    -> );
ERROR 1005 (HY000): Can't create table `openmrs`.`cohort_member_attribute` (errno: 150 "Foreign key constraint is incorrectly formed")

I had the same issue. The issue is with: ‘CONSTRAINT cohort_member_attribute_cohort_member_fk FOREIGN KEY (cohort_member_id) REFERENCES openmrs.cohort_member(cohort_member_id)’

It appears that the DB doesn’t have primary key on openmrs.cohort_member(cohort_member_id). It is only when you setup with SDK, which loads openmrs-sdk/maven-plugin/src/main/resources/openmrs-platform.sql at master · openmrs/openmrs-sdk · GitHub as an initial DB and then liquibase changesets are applied. They are applied incorrectly for some reason…

The workaround is to force SDK to stop importing openmrs-platform.sql with:

mvn openmrs-sdk:setup -DdbSql=null

In the newer versions of openmrs-core preloading openmrs-platform.sql is not needed anyway, because schema-only files are used for the respective version and the process of DB creation is as fast.

1 Like

Addressed in [SDK-330] - OpenMRS Issues

I’ll shortly release SDK with the fix.

1 Like