But from a consumer's perspective the export could demormalise Guvnor's internals and contain the referenced artifact. When imported normalisation would be reimposed. I don't know whether UUIDs need to be preserved across JCR repositories; or whether provided they are consistent within a single repository they are transient.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jervis Liu Sent: 06 August 2010 08:12 To: Rules Dev List Subject: Re: [rules-dev] Package based import/export in Guvnor 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]>> 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]> > 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
