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
