Hi Elmo, my ideas just a tiny bit different. I am always for using an API instead of directly going to the DB and changing things.
What I would do is: - end the old processInstance - create a new processInstance and map the state of the old processInstance to the new one - I would NOT change existing processInstances (except for ending them) as that's just hot air a more detailed version: - create a migration base class that takes an active processInstance (with an old process definition) and a new process definition. The migration class would end the old processInstance, create a new one and try to create and correctly place matching tokens in the new processInstance. It could furthermore create a log, migrate variables, keep a link to the old processInstance, etc. The main motivation to do this is to keep data integrity and being able to reproduce what happened. If you just change the database you don't have a chance of ever reproducing a process (including the defintion change). - the migration base class will only work if the old and new processDefinition structures match, otherwise it should throw an excpetion. In this case you need a specific implementation. - if the structure of the processDefinition has changed or specific actions are needed to migrate, implement a specific subclass that would override a "mapNode()" method. This would e.g. allow you to merge two tokens in a fork if the fork no longer exists or do other - possibly very complex - addaptions required by the changes to the processDefintion. You would only need to implement those node migrations that will not work by default. It would probably make more sense to change all active processInstances of a deprecated processDefinition. But that doesn't effect the overall concept. Now none of these things are trivial, but it shouldn't be that hard to do. Depends on how important this will be for you. Problems would be: - how to recognize the versions of processDefinitions. You can't rely on the version as that would / could change depending on deployment. You would problably have to implement your own - static - versioning that would survive e.g. multiple deployments. - almost same problem: mapping specific migrations (processDefA.1=> processDefA.4) to a specific migration class implementation. - how to recognize structures (node, etc.) By Name? By path? Again, an id will change so you would have to implement so kind of logic / convention that could figure this out. - plus lots of other things you only find out when you write the code :-) Subprocesses? No idea. I guess changing the subprocess and relinking the main process should do, but then again you'll probably run into a lot of problems. New Years hangover? :-) Your questions will go unnoticed in that respect. Too much background noise.... Hope this helps. Might even implement it myself. Depends on what my current project requires. Rainer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3915286#3915286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3915286 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
