For the database connection and schema evolution for the Editorial Comments feature Hibernate and Liquibase are used. Both frameworks support multiple databases and therefore must be configured correctly.

Editorial Comments works with all our supported databases. The database drivers are already included in the studio-server-app via a dependency to com.coremedia.blueprint:database-drivers.

The default schema, username and password is: cm_editorial_comments.

In case you want to provide a schema or username, different to cm_editorial_comments, use the properties editorial.comments.db.username, editorial.comments.db.schema and editorial.comments.db.password.

The datasource url has to be set for the respective database with the property editorial.comments.datasource.url like this:

MySQL / MariaDB: Ensure Proper Character Set And Collation

To ensure proper encoding and collation behavior, ensure using character set utf8mb4 and collation utf8mb4_bin for your created database.

MariaDB: Respect Password Check Plugins

MariaDB Enterprise Server comes with a password check plugin enabled by default. Ensure, that your password meets the requirements of that password check plugin.

PostgreSQL on Azure

Should you use PostgreSQL hosted on Azure, it is necessary to provide a postfix with the domain to the username. Use editorial.comments.db.username to set the username with the postfix:

editorial.comments.db.username=cm_editorial_comments@domain

editorial.comments.db.schema=cm_editorial_comments

Working with Liquibase

Run modes

Liquibase can run either on startup of each server automatically or get executed manually. The default for the Studio-Server is the automatic run on each server startup. This means that on each startup liquibase checks if the schema contains all entries of the defined changesets. During startup of the Studio-Server Liquibase sets a lock in the database if the actual schema is not fully applied. If the Studio-Server startup is interrupted during the process of applying the schema, the lock might be left in the database. This is very unlikely but if this occurs the lock can be released. For instructions see Section “Release locks”.

Even if it is recommended to run Liquibase automatically in some deployment scenarios it might make sense to execute Liquibase manually. To reach this, automatic runs can be disabled by setting the property editorial.comments.liquibase.enabled=false. Afterwards you have to take care to run an database schema upgrade on each upgrade of CMCC. This can be done by either running a Studio Server instance once with the property editorial.comments.liquibase.enabled=true or by using the Liquibase command line tool. The following example shows a liquibase.properties file for a MySQL setup used by the command line tool:

          changeLogFile=db/changelog/db.changelog-editorial-comments.xml
username=cm_editorial_comments
password=cm_editorial_comments
driver=com.mysql.cj.jdbc.Driver
url=jdbc:mysql://localhost:3306/cm_editorial_comments
classpath=>pathToMySqlDriver>/mysql-connector-j-8.2.0.jar
:<pathTo_editorial-comments-data-jar>editorial-comments-data-1-SNAPSHOT.jar

        

Release locks

By default liquibase runs automatically on Studio Server startup. In very rare cases (e.g. interruption on startup) the database might contain a lock entry that has not been cleaned up. As a result starting Studio Servers is blocked by Liquibase. The lock can either be removed manually manually or with the Liquibase cmd tool which can be also executed via Docker:

          docker run --rm -e INSTALL_MYSQL=true liquibase/liquibase \
--url="jdbc:mysql://host:port/cm_editorial_comments" \
--username=cm_editorial_comments \
--password=cm_editorial_comments \
releaseLocks