[rules-dev] Package based import/export in Guvnor
Jervis Liu
jliu at redhat.com
Fri Aug 6 04:32:19 EDT 2010
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 at redhat.com
> <mailto:jliu at 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 at redhat.com
> <mailto:jliu at redhat.com>
> > <mailto:jliu at redhat.com <mailto:jliu at 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
> > 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
> > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> <mailto:rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>>
> > 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
> > rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> >
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> 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
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
More information about the rules-dev
mailing list