|Yes, touchpoints are your friend. For example, you could write a touch point that does the migration and then trigger it when the related IU is installed. Rolling back the migration is effectively an open-ended problem that will be specific to your situation. p2 gives you some discrete points at which you can do things but there is no rollback magic. You have to code your migration to support it.|
On 2010-11-29, at 10:13 AM, Taylor, Richard wrote:
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
So what are best practices for migrating data? Certainly P2 facilitates updating code, but what about migrating the data bases or (root) data files associated with a product? Simply coping files around can help, but migration probably involves running code that takes the current state of the product (data bases and/or data files) and updates their structures per the updated code. It would be helpful if the migration could be run as a part of the P2 update itself … even to the point of rolling back the entire update should the migration fail.
So what are people doing to migrate data? Are custom touchpoint handlers or actions helpful?
Also, my specific problem involves a head-less OSGi based server … no Eclipse IDE. Upgrade is un-attended.
Thanks for your thoughts,
p2-dev mailing listp2-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/p2-dev