nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

DB Version check very unhandy for process deployment

bernd_ruecker

Hey guys.

One problem I currently face with our examples, demos, showcases. But they could get a real life problem as well, so I think we should give it some thought (or maybe you did already and I missed it?).

When I want to deploy a process via ant, the activiti-engine.jar is used together with a activiti.cfg.xml pointing to the database. When I now change the Activiti version (either in the development project or in the Activiti server) I cannot deploy any longer, because I get the exception that the database version doesn't match.

But for pure deployment there is normally no need that they match.

Any ideas how to remedy that? Or can I configure to skip that check (which would solve the deployment scenario)?

Thanks
Bernd

Find more posts tagged with

Comments

jbarrez

If you change the schemaUpdate property of the config it should automatically update to the latest version.

See http://activiti.org/userguide/index.html#databaseUpgrade

In production environments, obviously you want that exception to happen, since you want to put some more love in the upgrade 😉

bernd_ruecker

Hi Joram.

I was aware of that, but I just want to deploy with a different jar version of the engine without changing the database. Obviously on my own risk, that the database is still compatible… So that is not possible?

Hmm, then a thought crossed my mind: Maybe the Ant Deployment Task should be able to talk to the REST-Interface, than we don't need any db connection and just rely on the documented REST API. What do you think?

Cheers
Bernd

jbarrez

I just want to deploy with a different jar version of the engine without changing the database.

I don't see the use case of it. When would you require such behavior?
Even if you are deploying with ant, you can easily set the auto update to true, no?
And calling the REST api throigh ant would require to have a server running, which is not always the case.

bernd_ruecker

Use Case:

You have an activiti installation running. You want to deploy a new application to it, for the moment maybe a demo just downloaded (like the Incident Management Showcase from us: http://www.bpm-guide.de/activiti/). Deploying should not depend on the version you have on the server on for god sake the deployment MUST NOT change the database of the server, otherwise the server installation is broken.

Otherwise you force all installed apps to have the same version of Activiti used in their Maven/Ant dependencies. This is in the long run unmanageable in my eyes and unnecessary.

Sure, REST requires the server, but if I want to deploy on the server, it must be there 😉
As an alternative it would be handy (as I wrote earlier) to be able to disable the version checking for a configuration.

tombaeyens

I think removing the DB version check is asking for trouble.

That said, if you really want it, you could add a
  public static final String DB_SCHEMA_UPDATE_UNCHECKED = "unchecked";<br>in ProcessEngineConfigurationImpl

if you add it, make sure you don't expose this as a public feature.