Re: [rules-dev] Package based import/export in Guvnor

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: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] 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 <jliu(a)redhat.com > <mailto:jliu@redhat.com>> 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 <jliu(a)redhat.com >     <mailto:jliu@redhat.com> >     > <mailto:jliu@redhat.com <mailto:jliu@redhat.com>>> 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 >     >