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

Anstis, Michael (M.) manstis1 at ford.com
Fri Aug 6 05:04:30 EDT 2010


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 at lists.jboss.org
[mailto:rules-dev-bounces at 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 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
>   

_______________________________________________
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