I'd be more surprised if companies used the same instance! Separation of PROD, QA and DEV data seems to be at the heart of many organisations for auditing, security, backup and other requirements. It gives lots of "internal control" people lots of jobs.
You could consider building a denormlalised tree in JCR representing the export; export with JCR, import de-normalised tree into the target and then worry about merge\normalisation as part of the import API. Keeps the "public" data JCR compliant and the described difficulties internal. Might be a better option than proprietary file format but the temporary growth in the repository could be a concern... You could consider the use of a transient "secondary" repository for the denormalisation/normalisation process too... -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jervis Liu Sent: 06 August 2010 09:32 To: Rules Dev List Subject: Re: [rules-dev] Package based import/export in Guvnor Michael Neale wrote: > yes, I know that - but if you don't try and export/import via JCR then > you can do what you want. > > The "correct" JCR way to have multiple regions (QA, DEV etc) is > actually Workspaces if you read the JCR spec - it is designed for this > in mind (and allows this to some extent) - but not sure how that helps > with per-package stuff. > > IS this exporting and importing a package to a completely separate > guvnor instance? Yes, a separate Guvnor instance. This is because I believe, some companies run different instances of Guvnor for different life cycles, eg, one instance of Guvnor for testing stage, one instance of Guvnor for production stage. > > if so - JCR will not be able to be used - it will have to be a custom > file format which can be imported in the other and and adjusted. > > On Fri, Aug 6, 2010 at 5:12 PM, Jervis Liu <[email protected] > <mailto:[email protected]>> wrote: > > Michael Neale wrote: > > well for category things - it could be that if a category doesn't > > exist in the target "space" then it is created, if not, it is used. > > There are other things though, which are interlinked - but the same > > issue you bring up applies (which is why this wasn't done a > while back). > > > > So a simple JCR partial export won't really do - needs to be a bit > > more programmatic than that. > > > > The question is - in the target space - do we want to create the > > missing things, or remove the links from them as part of the export > > etc... > > > > So if RuleA depends on categoryX and categoryY, but only categoryX > > (same name) exists in the target place, then do we create categoryY > > there, or strip it? > > > Things are a little bit more complex than this. The category (and > other > things like status etc) attribute is not a plain text value, its a > reference type, essentially its a UUID point to the category > nodes. This > UUID value is always invalid in another repository. > > > > On Fri, Aug 6, 2010 at 4:44 PM, Jervis Liu <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > Hi, > > > > I am currently evaluating a Guvnor feature request which is to > > implement > > package based import/export. The idea is to use this feature > to move a > > rule package from the DEV repo to QA to Stage to the Prod > repo. For > > details please check > https://jira.jboss.org/browse/GUVNOR-311. My > > initial investigation shows that it is not possible to do a > single > > package import/export technically. A single package in Guvnor > > repository > > is never a self-contained unit. For example, every asset > under the > > package has a mandatory attribute which is a reference link to > > category > > information. In short, package can not be exported/imported > as long as > > it contains references to entities outside package. > > > > There are two things I would like to ask for your opinions. > > Firstly, can > > you think of any way to implement this import/export feature? > > Personally > > I dont see how this can be done. This is similar to relational > > database, > > generally it is impossible to export and import data from/to > a single > > non-isolated table in database. Or sometimes it is possible > but with > > extensive care normally involved in manual work to deal with > dirty > > data. > > In our case, one example of dirty data is category, but what > can we do > > with category information, we discard package information > when we do > > package export? > > > > Secondly, if such feature can not be implemented, can we > figure out a > > different way to help users to better manage the life cycle > in Guvnor? > > The current version of Guvnor is not very strong on this > part yet. If > > you are a Guvnor user or you have experience of using similar > > products, > > how did you manage and how do you want to manage the > lifecycle of > > assets > > in your repository? > > > > > > Thanks, > > > > Jervis > > > > > > _______________________________________________ > > rules-dev mailing list > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > > > -- > > Michael D Neale > > home: www.michaelneale.net <http://www.michaelneale.net> > <http://www.michaelneale.net> > > blog: michaelneale.blogspot.com > <http://michaelneale.blogspot.com> <http://michaelneale.blogspot.com> > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > rules-dev mailing list > > [email protected] <mailto:[email protected]> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > -- > Michael D Neale > home: www.michaelneale.net <http://www.michaelneale.net> > blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com> > ------------------------------------------------------------------------ > > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
