1:44 a.m.
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
2 a.m.
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?
On Fri, Aug 6, 2010 at 4:44 PM, Jervis Liu <jliu(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
2:12 a.m.
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(a)redhat.com
<mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
2:46 a.m.
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: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] 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 <jliu(a)redhat.com
<mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
3:20 a.m.
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?
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(a)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(a)redhat.com
> <mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
3:32 a.m.
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(a)redhat.com
<mailto:jliu@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(a)redhat.com
<mailto:jliu@redhat.com>
> <mailto:jliu@redhat.com <mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
<mailto:rules-dev@lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4:04 a.m.
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(a)lists.jboss.org
[mailto:rules-dev-bounces@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(a)redhat.com
<mailto:jliu@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(a)redhat.com
<mailto:jliu@redhat.com>
> <mailto:jliu@redhat.com <mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
<mailto:rules-dev@lists.jboss.org
<mailto:rules-dev@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/rules-dev
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:10 a.m.
Good points and ideas. I think it is a valuable feature.
On Friday, August 6, 2010, Anstis, Michael (M.) <manstis1(a)ford.com> wrote:
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(a)lists.jboss.org
[mailto:rules-dev-bounces@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(a)redhat.com
> <mailto:jliu@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(a)redhat.com
> <mailto:jliu@redhat.com>
> > <mailto:jliu@redhat.com <mailto:jliu@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
> >
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
6:37 a.m.
Hi,
In my experience having implemented this functionality, there is much more to
import-export of rules than what meets the eye.
When we look at Dev - QA not everything goes. This is purely based upon what is it that we
are releasing to QA and only those many rules / configurations would need to be sent
across.
Then we ship from QA to client site (maybe directly to staging or pre-staging depending
upon how much testing is being done at client side). During this time we would typically
export everything from what is QA passed to client. The challenges faced during this
transition increases manifold when the "business" user is allowed to define a
rule (apart from developers). SO what this means is that in the destination repository
there may be additional rules than what we are shipping with. But the object structure is
new one. This is not related to drools per se but nevertheless is an issue faced during
export-import.
Lastly we move from staging to production. Here the export and import is now a business
user choice. Typically the business users would prepare some data on the staging and run
some business transactions to test that setup. Once they are happy they would want to
migrate the entire data setup (along with rules). E.g. if there are 3 new banking products
setup in staging and out of those we would want to export only one product (it's data
in different modules and also rules associated with it) to the production box. The choice
of rekeying the entire data and rules does not go down well with the business user as it
may happen that there may be a mistake during rekeying of data.
To summarize the additional challenges faced during export - import of
Dev to QA - Need ability to select based on package / flags (authorized or marked for
moving to QA).
QA to Staging - Need ability to select based on package / flags (authorized or marked for
moving to Staging).
Staging to Production - Need API for developers to state which rules would be exported.
The list would be picked up based on the configuration UI that is exposed by the
application for exporting functional entities.
If alternatively a refactoring tool can be provided to accommodate object structure
changes it would be great. This is needed only when rules are defined by business user and
hence the developer is not aware of them.
p.s. Although this is dev list, I thought a user's point of view may be helpful in
development of this feature.
Thanks.
Regards,
- Nimesh
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of Michael Neale
Sent: Friday, August 06, 2010 4:41 PM
To: Rules Dev List
Subject: Re: [rules-dev] Package based import/export in Guvnor
Good points and ideas. I think it is a valuable feature.
On Friday, August 6, 2010, Anstis, Michael (M.) <manstis1(a)ford.com> wrote:
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(a)lists.jboss.org
[mailto:rules-dev-bounces@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(a)redhat.com
> <mailto:jliu@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(a)redhat.com
> <mailto:jliu@redhat.com>
> > <mailto:jliu@redhat.com <mailto:jliu@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
> >
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
MASTEK LTD.
In the US, we're called MAJESCOMASTEK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek
Limited, unless specifically indicated to that effect. Mastek Limited does not accept any
responsibility or liability for it. This e-mail and attachments (if any) transmitted with
it are confidential and/or privileged and solely for the use of the intended person or
entity to which it is addressed. Any review, re-transmission, dissemination or other use
of or taking of any action in reliance upon this information by persons or entities other
than the intended recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility of the recipient to
run the virus check on e-mails and attachments before opening them. If you have received
this e-mail in error, kindly delete this e-mail from desktop and server.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7:21 p.m.
On 2010/8/6 19:37, Nimesh Muley wrote:
Hi,
In my experience having implemented this functionality, there is much more to
import-export of rules than what meets the eye.
When we look at Dev - QA not everything goes. This is purely based upon what is it that
we are releasing to QA and only those many rules / configurations would need to be sent
across.
Then we ship from QA to client site (maybe directly to staging or pre-staging depending
upon how much testing is being done at client side). During this time we would typically
export everything from what is QA passed to client. The challenges faced during this
transition increases manifold when the "business" user is allowed to define a
rule (apart from developers). SO what this means is that in the destination repository
there may be additional rules than what we are shipping with. But the object structure is
new one. This is not related to drools per se but nevertheless is an issue faced during
export-import.
Lastly we move from staging to production. Here the export and import is now a business
user choice. Typically the business users would prepare some data on the staging and run
some business transactions to test that setup. Once they are happy they would want to
migrate the entire data setup (along with rules). E.g. if there are 3 new banking products
setup in staging and out of those we would want to export only one product (it's data
in different modules and also rules associated with it) to the production box. The choice
of rekeying the entire data and rules does not go down well with the business user as it
may happen that there may be a mistake during rekeying of data.
To summarize the additional challenges faced during export - import of
Dev to QA - Need ability to select based on package / flags (authorized or marked for
moving to QA).
QA to Staging - Need ability to select based on package / flags (authorized or marked for
moving to Staging).
Staging to Production - Need API for developers to state which rules would be exported.
The list would be picked up based on the configuration UI that is exposed by the
application for exporting functional entities.
If alternatively a refactoring tool can be provided to accommodate object structure
changes it would be great. This is needed only when rules are defined by business user and
hence the developer is not aware of them.
p.s. Although this is dev list, I thought a user's point of view may be helpful in
development of this feature.
Nimesh, this is exactly what we want to hear from. Thanks.
Jervis
Thanks.
Regards,
- Nimesh
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of Michael Neale
Sent: Friday, August 06, 2010 4:41 PM
To: Rules Dev List
Subject: Re: [rules-dev] Package based import/export in Guvnor
Good points and ideas. I think it is a valuable feature.
On Friday, August 6, 2010, Anstis, Michael (M.)<manstis1(a)ford.com> wrote:
> 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(a)lists.jboss.org
> [mailto:rules-dev-bounces@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(a)redhat.com
>> <mailto:jliu@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(a)redhat.com
>> <mailto:jliu@redhat.com>
>> > <mailto:jliu@redhat.com<mailto:jliu@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
>> >
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
MASTEK LTD.
In the US, we're called MAJESCOMASTEK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek
Limited, unless specifically indicated to that effect. Mastek Limited does not accept any
responsibility or liability for it. This e-mail and attachments (if any) transmitted with
it are confidential and/or privileged and solely for the use of the intended person or
entity to which it is addressed. Any review, re-transmission, dissemination or other use
of or taking of any action in reliance upon this information by persons or entities other
than the intended recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility of the recipient to
run the virus check on e-mails and attachments before opening them. If you have received
this e-mail in error, kindly delete this e-mail from desktop and server.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
7:48 p.m.
yeah - that is a valid case.
In which case it isn't just cloning things so much as migrating for
management purposes... so perhaps not all the metadata that is in JCR is
require - its all about the rules themselves for that purpose?
On Mon, Aug 9, 2010 at 10:21 AM, Jervis Liu <jliu(a)redhat.com> wrote:
On 2010/8/6 19:37, Nimesh Muley wrote:
> Hi,
>
> In my experience having implemented this functionality, there is much
more to import-export of rules than what meets the eye.
>
> When we look at Dev - QA not everything goes. This is purely based upon
what is it that we are releasing to QA and only those many rules /
configurations would need to be sent across.
>
> Then we ship from QA to client site (maybe directly to staging or
pre-staging depending upon how much testing is being done at client side).
During this time we would typically export everything from what is QA passed
to client. The challenges faced during this transition increases manifold
when the "business" user is allowed to define a rule (apart from
developers). SO what this means is that in the destination repository there
may be additional rules than what we are shipping with. But the object
structure is new one. This is not related to drools per se but nevertheless
is an issue faced during export-import.
>
> Lastly we move from staging to production. Here the export and import is
now a business user choice. Typically the business users would prepare some
data on the staging and run some business transactions to test that setup.
Once they are happy they would want to migrate the entire data setup (along
with rules). E.g. if there are 3 new banking products setup in staging and
out of those we would want to export only one product (it's data in
different modules and also rules associated with it) to the production box.
The choice of rekeying the entire data and rules does not go down well with
the business user as it may happen that there may be a mistake during
rekeying of data.
>
> To summarize the additional challenges faced during export - import of
> Dev to QA - Need ability to select based on package / flags (authorized
or marked for moving to QA).
> QA to Staging - Need ability to select based on package / flags
(authorized or marked for moving to Staging).
> Staging to Production - Need API for developers to state which rules
would be exported. The list would be picked up based on the configuration UI
that is exposed by the application for exporting functional entities.
>
> If alternatively a refactoring tool can be provided to accommodate object
structure changes it would be great. This is needed only when rules are
defined by business user and hence the developer is not aware of them.
>
> p.s. Although this is dev list, I thought a user's point of view may be
helpful in development of this feature.
Nimesh, this is exactly what we want to hear from. Thanks.
Jervis
> Thanks.
> Regards,
> - Nimesh
>
> -----Original Message-----
> From: rules-dev-bounces(a)lists.jboss.org [mailto:
rules-dev-bounces(a)lists.jboss.org] On Behalf Of Michael Neale
> Sent: Friday, August 06, 2010 4:41 PM
> To: Rules Dev List
> Subject: Re: [rules-dev] Package based import/export in Guvnor
>
> Good points and ideas. I think it is a valuable feature.
>
> On Friday, August 6, 2010, Anstis, Michael (M.)<manstis1(a)ford.com>
wrote:
>> 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(a)lists.jboss.org
>> [mailto:rules-dev-bounces@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(a)redhat.com
>>> <mailto:jliu@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(a)redhat.com
>>> <mailto:jliu@redhat.com>
>>> > <mailto:jliu@redhat.com<mailto:jliu@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
>>> >
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> MASTEK LTD.
> In the US, we're called MAJESCOMASTEK
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Opinions expressed in this e-mail are those of the individual and not
that of Mastek Limited, unless specifically indicated to that effect. Mastek
Limited does not accept any responsibility or liability for it. This e-mail
and attachments (if any) transmitted with it are confidential and/or
privileged and solely for the use of the intended person or entity to which
it is addressed. Any review, re-transmission, dissemination or other use of
or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. This e-mail and
its attachments have been scanned for the presence of computer viruses. It
is the responsibility of the recipient to run the virus check on e-mails and
attachments before opening them. If you have received this e-mail in error,
kindly delete this e-mail from desktop and server.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
4:11 a.m.
Hi,
Oops I had missed out this mail :(
Ultimately it is about Rules always :). But if business user also authors the rules then
we need to package some meta-data too. In my case the dev team would also author the
meta-data which the business user would need. E.g. package definition being done by dev
team whereas adding a new package is not allowed for the business user. This meta-data
would be primarily be driven by the solution architecture.
Thanks.
Regards,
- Nimesh
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of Michael Neale
Sent: Monday, August 09, 2010 6:19 AM
To: Rules Dev List
Subject: Re: [rules-dev] Package based import/export in Guvnor
yeah - that is a valid case.
In which case it isn't just cloning things so much as migrating for management
purposes... so perhaps not all the metadata that is in JCR is require - its all about the
rules themselves for that purpose?
On Mon, Aug 9, 2010 at 10:21 AM, Jervis Liu
<jliu@redhat.com<mailto:jliu@redhat.com>> wrote:
On 2010/8/6 19:37, Nimesh Muley wrote:
Hi,
In my experience having implemented this functionality, there is much more to
import-export of rules than what meets the eye.
When we look at Dev - QA not everything goes. This is purely based upon what is it that
we are releasing to QA and only those many rules / configurations would need to be sent
across.
Then we ship from QA to client site (maybe directly to staging or pre-staging depending
upon how much testing is being done at client side). During this time we would typically
export everything from what is QA passed to client. The challenges faced during this
transition increases manifold when the "business" user is allowed to define a
rule (apart from developers). SO what this means is that in the destination repository
there may be additional rules than what we are shipping with. But the object structure is
new one. This is not related to drools per se but nevertheless is an issue faced during
export-import.
Lastly we move from staging to production. Here the export and import is now a business
user choice. Typically the business users would prepare some data on the staging and run
some business transactions to test that setup. Once they are happy they would want to
migrate the entire data setup (along with rules). E.g. if there are 3 new banking products
setup in staging and out of those we would want to export only one product (it's data
in different modules and also rules associated with it) to the production box. The choice
of rekeying the entire data and rules does not go down well with the business user as it
may happen that there may be a mistake during rekeying of data.
To summarize the additional challenges faced during export - import of
Dev to QA - Need ability to select based on package / flags (authorized or marked for
moving to QA).
QA to Staging - Need ability to select based on package / flags (authorized or marked for
moving to Staging).
Staging to Production - Need API for developers to state which rules would be exported.
The list would be picked up based on the configuration UI that is exposed by the
application for exporting functional entities.
If alternatively a refactoring tool can be provided to accommodate object structure
changes it would be great. This is needed only when rules are defined by business user and
hence the developer is not aware of them.
p.s. Although this is dev list, I thought a user's point of view may be helpful in
development of this feature.
Nimesh, this is exactly what we want to hear from. Thanks.
Jervis
Thanks.
Regards,
- Nimesh
-----Original Message-----
From: rules-dev-bounces@lists.jboss.org<mailto:rules-dev-bounces@lists.jboss.org>
[mailto:rules-dev-bounces@lists.jboss.org<mailto:rules-dev-bounces@lists.jboss.org>]
On Behalf Of Michael Neale
Sent: Friday, August 06, 2010 4:41 PM
To: Rules Dev List
Subject: Re: [rules-dev] Package based import/export in Guvnor
Good points and ideas. I think it is a valuable feature.
On Friday, August 6, 2010, Anstis, Michael
(M.)<manstis1@ford.com<mailto:manstis1@ford.com>> wrote:
> 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@lists.jboss.org<mailto:rules-dev-bounces@lists.jboss.org>
>
[mailto:rules-dev-bounces@lists.jboss.org<mailto:rules-dev-bounces@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@redhat.com<mailto:jliu@redhat.com>
>> <mailto:jliu@redhat.com<mailto:jliu@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@redhat.com<mailto:jliu@redhat.com>
>> <mailto:jliu@redhat.com<mailto:jliu@redhat.com>>
>> >
<mailto:jliu@redhat.com<mailto:jliu@redhat.com><mailto:jliu@redhat.com<mailto:jliu@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
>> >
--
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@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
MASTEK LTD.
In the US, we're called MAJESCOMASTEK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek
Limited, unless specifically indicated to that effect. Mastek Limited does not accept any
responsibility or liability for it. This e-mail and attachments (if any) transmitted with
it are confidential and/or privileged and solely for the use of the intended person or
entity to which it is addressed. Any review, re-transmission, dissemination or other use
of or taking of any action in reliance upon this information by persons or entities other
than the intended recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility of the recipient to
run the virus check on e-mails and attachments before opening them. If you have received
this e-mail in error, kindly delete this e-mail from desktop and server.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@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>
MASTEK LTD.
In the US, we're called MAJESCOMASTEK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of Mastek
Limited, unless specifically indicated to that effect. Mastek Limited does not accept any
responsibility or liability for it. This e-mail and attachments (if any) transmitted with
it are confidential and/or privileged and solely for the use of the intended person or
entity to which it is addressed. Any review, re-transmission, dissemination or other use
of or taking of any action in reliance upon this information by persons or entities other
than the intended recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility of the recipient to
run the virus check on e-mails and attachments before opening them. If you have received
this e-mail in error, kindly delete this e-mail from desktop and server.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2:42 a.m.
If the use-case of migrating packages through the environments holds
true I'd expect the meta-data associated with packages to remain
constant.
Perhaps I've made an assumption that you don't have categories called
"Production rules", "QA rules" etc.
Thinking wider; is there a requirement to allow export\import to be
sliced and diced many different ways:-
*
Export\import a category
*
Export\import a package
*
Export\import working set
*
etc
________________________________
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Michael Neale
Sent: 06 August 2010 08:00
To: Rules Dev List
Subject: Re: [rules-dev] Package based import/export in Guvnor
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?
On Fri, Aug 6, 2010 at 4:44 PM, Jervis Liu <jliu(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
3 a.m.
Anstis, Michael (M.) wrote:
If the use-case of migrating packages through the environments holds
true I'd expect the meta-data associated with packages to remain constant.
Perhaps I've made an assumption that you don't have categories called
"Production rules", "QA rules" etc.
Thinking wider; is there a requirement to allow export\import to be
sliced and diced many different ways:-
*
Export\import a category
*
Export\import a package
*
Export\import working set
*
etc
The thing is that there are lots of external dependencies associated
with a package and package assets. To name a new, category, status (Dev,
QA, STAGE, PROD), permissions, comments etc.The list will grow bigger
and bigger when new features get implemented as long as the data
structure required by these features are not internal to a package. So
far we've figured one possible way that might solve the problem: when we
do package export, we export a data bundle that contains the package and
all essential data associated with this package (eg, category nodes,
status nodes etc). And when we do the import, we somehow deal with dirty
data programmatically (recover or discard the dirty data).
This is doable, but is this a practical approach? I would imagine a
single package data exported may contains over 60% data of that
repository. Not to mention the complexity of dealing with dirty data
during package import.
------------------------------------------------------------------------
*From:* rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] *On Behalf Of *Michael
Neale
*Sent:* 06 August 2010 08:00
*To:* Rules Dev List
*Subject:* Re: [rules-dev] Package based import/export in Guvnor
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?
On Fri, Aug 6, 2010 at 4:44 PM, Jervis Liu <jliu(a)redhat.com
<mailto:jliu@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(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5219
days inactive
5223
days old
13 comments
4 participants
participants (4)
-
Anstis, Michael (M.) -
Jervis Liu -
Michael Neale -
Nimesh Muley