What happened. Added the audit add-on the usual way:
implementation 'io.jmix.audit:jmix-audit-starter'
implementation 'io.jmix.audit:jmix-audit-flowui-starter'
compileJava clean, clean test green, application started. And the audit tables did not
exist. The project's master changelog lists module changelogs BY HAND:
<include file="/io/jmix/data/liquibase/changelog.xml"/>
<include file="/io/jmix/flowuidata/liquibase/changelog.xml"/>
<include file="/io/jmix/securitydata/liquibase/changelog.xml"/>
<includeAll path="/com/company/app/liquibase/changelog"/>
A new add-on does not add itself to that list. The failure surfaces as one ERROR line at
startup (relation "audit_logged_entity" does not exist) and then the application runs
normally — with the feature silently dead. In an audit log that is the worst possible
failure mode: you discover it when you need to know who changed a record.
Fix.
<include file="/io/jmix/audit/liquibase/changelog.xml"/>
Why the skills should say this. Jmix Studio adds the include automatically when you
install an add-on, so the step does not exist in the documented workflow and is invisible
to an agent working without Studio. jmix-create-liquibase-changelog covers writing your
own changesets and reaching them via includeAll, but says nothing about module
changelogs of add-ons. One line would prevent it:
When adding a Jmix add-on that owns persistent entities, add its changelog to the master
changelog: <include file="/io/jmix/<addon>/liquibase/changelog.xml"/>. Verify the add-on's
tables exist after startup — the application starts fine without them.
Second-order point for the same skill: after adding an add-on, GREP THE STARTUP LOG for
does not exist / relation .* does not exist. A green clean test proves the context
loads; it does not prove the add-on's schema was created, because the missing table is only
touched when the feature is used.
Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).
What happened. Added the audit add-on the usual way:
compileJavaclean,clean testgreen, application started. And the audit tables did notexist. The project's master changelog lists module changelogs BY HAND:
A new add-on does not add itself to that list. The failure surfaces as one ERROR line at
startup (
relation "audit_logged_entity" does not exist) and then the application runsnormally — with the feature silently dead. In an audit log that is the worst possible
failure mode: you discover it when you need to know who changed a record.
Fix.
Why the skills should say this. Jmix Studio adds the include automatically when you
install an add-on, so the step does not exist in the documented workflow and is invisible
to an agent working without Studio.
jmix-create-liquibase-changelogcovers writing yourown changesets and reaching them via
includeAll, but says nothing about modulechangelogs of add-ons. One line would prevent it:
Second-order point for the same skill: after adding an add-on, GREP THE STARTUP LOG for
does not exist/relation .* does not exist. A greenclean testproves the contextloads; it does not prove the add-on's schema was created, because the missing table is only
touched when the feature is used.
Found while building a real Jmix 2.8 application (document registry, Vaadin UI, PostgreSQL, deployed behind nginx).