• FEATURES
  • PRICING
  • MARKETPLACE
  • CASE STUDIES
  • BLOG
    •

    Upgrade 3.3 to 3.4 fails with add_cfg_prop does not exist

    Technical Questions
    #1

    We have an existing 3.3 installation and are trying to upgrade to 3.4. Here is what has been done:

    • cloned the latest github source
    • did a checkout on v3.4.x to set the branch
    • cd to www and did the npm install and bower install
    • changed build.properties to match the settings in the 3.3 instance
    • gradle clean
    • gradle deploy

    The application fails to start and I see this in /$tomcat/webapps/openspecimen/osData/logs/os.log:

    2017-01-30 17:50:08,860 [localhost-startStop-5] WARN  org.springframework.web.context.support.XmlWebApplicationContext- Exception encountered during context initialization - cancelling refresh attempt
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'os-liquibase' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is liquibase.exception.MigrationFailedException: Migration failed for change set db/3.4/schema.xml::Enable/disable specimen barcoding::ckhilosiya:
     Reason: liquibase.exception.DatabaseException: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: PROCEDURE osdb.add_cfg_prop does not exist
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1514)

    Any idea as to what might be causing this error?

    Thanks in advance for any insight you can provide.

    #2

    Hi Glen,

    The error is because “add_cfg_prop” procedure does not exist in the database.

    It seems the database is missing procedures and triggers.

    Are you running the upgrade on a database, which is created using db dump exported from another OpenSpecimen database?

    There might be a chance that exported dump is without routines. If this is the case you can export routines from running os instance and import it into this database.

    Please use below commands to export and import routines

    1. Export routines:
      mysqldump -u <user_name> -p --routines --no-create-info --no-data --no-create-db --skip-opt <database_name> > routines.sql

    2. Import routines:
      mysql <database_name> < routines.sql

    Note - It is better to use same user for export and import routines. Otherwise, you need to change definer in exported dump.

    #3

    Thanks for your prompt response!

    This was a new installation of version 3.3 as of about 2 months ago. There was no db dump done at all, just an in place upgrade on a working 3.3 database.

    We have another instance running so I’ll try to follow your advice and export the routines from there and import them in to this database. Once I have done that I’ll post back the results.

    #4

    Hi @Glen_McGhie

    Can you please execute and send output of below MySQL command using same DB user credentials that is configured for use by OpenSpecimen?

    $ mysql -u<user> -p osdb -e "show procedure status like 'add_cfg_prop'"

    Stored procedure - add_cfg_prop was added in very early versions of v2x and is still in use.

    Thanks,
    Vinayak

    #5

    Success! I was able to create a new OS database, use it to dump the routines, and then import those routines into my prior database. This allowed the 3.4 upgrade to succeed. The application appears to be working fine with the 3.4 code.

    I do see one error in the log file:

    2017-02-01 16:45:31,887 [localhost-startStop-1] ERROR com.krishagni.catissueplus.core.de.services.impl.QueryServiceImpl- Error rendering query forms
java.io.FileNotFoundException: class path resource [query-forms/specimen/] cannot be resolved to URL because it does not exist

    …but, as I said, the application seams to be working. This just looks like there is a directory missing?

    In any case, thanks for your awesome help and suggestions. I am back in business!

    Glen

    #6

    Hi @Glen_McGhie

    You can ignore that error message as it is harmless. Actually, this message should have been logged at debug level. That being said, we’ll cleanup this in next release, as this feature was added in v2.5 to allow adopters extend query forms with additional custom fields. With custom fields enhancement in core app, this is no longer needed.

    Thanks for reporting the issue.