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.
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?
$ 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)’
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.