[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