Good points and ideas. I think it is a valuable feature. On Friday, August 6, 2010, Anstis, Michael (M.) <[email protected]> wrote: > 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 >> >
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
