[rules-users] Fwd: Migrating repository data from Drools 5.0 to 5.3Final
Michael Anstis
michael.anstis at gmail.com
Fri Feb 17 16:27:49 EST 2012
Forwarded to drools-user
sent on the move
---------- Forwarded message ----------
From: "Michael Anstis" <michael.anstis at gmail.com>
Date: 17 Feb 2012 21:24
Subject: Re: [rules-users] Fwd: Migrating repository data from Drools 5.0
to 5.3Final
To: "jian zhi" <jianpzhi at yahoo.com>
I could not set the bound name to the same value as the Fact Type in
"master". There have been a lot of changeable for 5.4 so I assume it has
been fixed.
The other issue is a known regression affecting all asset editors. Jervis
Liu is looking into it. The workaround us to close and reopen.
sent on the move
On 17 Feb 2012 21:15, "jian zhi" <jianpzhi at yahoo.com> wrote:
> Sorry, the error was Unable to save this asset, as it has been recently
> updated by [xxx].
>
> ------------------------------
> *From:* jian zhi <jianpzhi at yahoo.com>
> *To:* Michael Anstis <michael.anstis at gmail.com>
> *Cc:* Rules Users List <rules-users at lists.jboss.org>
> *Sent:* Friday, February 17, 2012 4:08 PM
> *Subject:* Re: [rules-users] Fwd: Migrating repository data from Drools
> 5.0 to 5.3Final
>
> Thanks for the update. I wa able to set the bound name same as the fact
> type on RHS in both R5.3Final and R5.3.2 snapshort.
> I also have problem to save the decision table if I open a decision
> table(web guided editor), edit it, save it(successful), then edit it
> again(on the same table) and save it. I got "No able to save DT after make
> a change, save it, then make another change.". It happened in R5.3.2
> snapshort. Is this the new feature added? I have no problem to edit, save,
> edit again and save in R5.3Final.
>
> Thanks,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* jian zhi <jianpzhi at yahoo.com>
> *Cc:* Rules Users List <rules-users at lists.jboss.org>
> *Sent:* Friday, February 17, 2012 9:32 AM
> *Subject:* Re: [rules-users] Fwd: Migrating repository data from Drools
> 5.0 to 5.3Final
>
> I just tried setting the bound name to be the same as the Fact type in
> both the LHS and RHS with "master" and it is not allowed.
>
> It sounds like your export has issues introduced as a result of bugs in
> 5.0.x. This is over 2 years old and you're unlikely to find much community
> support now.
>
> I believe the workaround you have identified is the only course of action.
>
> With kind regards,
>
> Mike
>
> On 16 February 2012 18:59, jian zhi <jianpzhi at yahoo.com> wrote:
>
> Mike,
>
> Thanks a lot for the response. There are some confusions. Although I had
> the bound name same as the fact type in 5.0.1 I still got fact0 in the rule
> source, which in the code you showed me it should not happen.
>
> There is a bug reported in Jira
> https://issues.jboss.org/browse/JBRULES-2843. The workaround was
> provided, however manually fixing the problem for each decision table is
> not an good option if we have a lot of decision tables. I guess the
> workaround for us is to remove the bound name from the exported repository
> before I import it back to 5.3.
>
> The linked issue (https://issues.jboss.org/browse/GUVNOR-171, Don't allow
> that 'Fact Name' has the same name as the 'Fact Type' or an empty value)
> indicated that the feature was added in drools-5.0.0CR1, however in 5.0.1 I
> still entered the fact name same as the fact type. The repository I sent
> you was created by 5.0.1. Also the new feature only exists in LHS in 5.3.
> On the RHS you still can enter the bound name same as the fact type.
>
> Again, thanks a lot for your help,
> Jian
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* jian zhi <jianpzhi at yahoo.com>
> *Sent:* Thursday, February 16, 2012 3:22 AM
>
> *Subject:* Re: [rules-users] Fwd: Migrating repository data from Drools
> 5.0 to 5.3Final
>
> This issue is not related to the migration from 5.0 to 5.3.
>
> The repository export XML contains the following:-
>
> <actionCols>
> <insert-fact-column>
> <width>-1</width>
> <hideColumn>false</hideColumn>
> <header>SetEligible</header>
> <factType>RuleEligibilityResult</factType>
> * <boundName>RuleEligibilityResult</boundName>*
> <factField>eligible</factField>
> <type>Boolean</type>
> <valueList>,true,false</valueList>
> </insert-fact-column>
> </actionCols>
>
> The name of the bound fact is "RuleEligibilityResult" which is what you
> are seeing in 5.3.
>
> Furthermore the code in BRDRLPersistence (that creates the DRL) remains
> the same in both 5.0 and 5.3:-
>
> if (action.getBoundName()==null) {
> generateSetMethodCalls("fact" + idx, action.fieldValues);
> } else {
> generateSetMethodCalls(action.getBoundName(), action.fieldValues);
> }
>
> "fact0" would only be created if the column does not have a bound name
> which is not the case in the repository export you provide.
>
> With kind regards,
>
> Mike
>
> On 15 February 2012 22:00, jian zhi <jianpzhi at yahoo.com> wrote:
>
> The repository is attached. The sources are listed below. On RHS the fact
> name was fact0 in 5.0, however it's RuleEligibilityResult(the fact name is
> same as the fact type) in 5.3.
>
> Source in Drools 5.0:
> then
> RuleEligibilityResult fact0 = new RuleEligibilityResult();
> fact0.setEligible( true );
> insert(fact0 );
> end
>
> Source in Drools 5.3
> then 9. | RuleEligibilityResult RuleEligibilityResult = new
> RuleEligibilityResult(); 10. | RuleEligibilityResult.setEligible(
> true ); 11. | insert(RuleEligibilityResult ); 12. | end
>
> Thanks,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* jian zhi <jianpzhi at yahoo.com>
> *Sent:* Tuesday, February 14, 2012 3:49 PM
>
> *Subject:* Re: [rules-users] Fwd: Migrating repository data from Drools
> 5.0 to 5.3Final
>
> Can you give some more information?
>
> This doesn't sound like it relates to the decision table but Drools
> Expert's handling of declared fact types.
>
> Can you provide another repository export demonstrating the problem?
>
> On 14 February 2012 20:27, jian zhi <jianpzhi at yahoo.com> wrote:
>
> As long as the result of the evaluation is same we are fine with it.
>
> One more question regarding to the data migration. In Drools 5.0 there is
> no restriction between the fact type and name so the fact name could be
> same as the fact type. After we migrated the data to 5.3 we got the IllegalArgumentException:
> object is not an instance of declaring class. Is it possible to fix the
> problem by converting the fact name to the 'Fact Type' with first character
> in lowercase during importing so the data is backward compatible?
>
> Thanks a lot,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* jian zhi <jianpzhi at yahoo.com>; Rules Users List <
> rules-users at lists.jboss.org>
> *Sent:* Monday, February 13, 2012 3:53 PM
> *Subject:* Re: [rules-users] Fwd: Migrating repository data from Drools
> 5.0 to 5.3Final
>
> This is fine.
>
> 5.2 onwards groups columns for the same pattern together - if you looked
> at the DRL fo 5.0 you'd have seen the columns are effectively grouped
> together too.
>
> For example; given the following 5.0 configuration (taken from what you
> describe you have done):-
>
> Pattern $a : Column A - Condition 1
> Pattern $b : Column B - Condition 1
> Pattern $c : Column C - Condition 1
> Pattern $d : Column D - Condition 1
> Pattern $a : Column E - Condition 2
> Pattern $b : Column F - Condition 2
>
> 5.0 DRL
>
> $a : Pattern( Condition 1, Condition 2 )
> $b : Pattern( Condition 1, Condition 2 )
> $c : Pattern( Condition 1 )
> $d : Pattern( Condition 1 )
>
> Importing this into 5.3 groups the columns:-
>
> Pattern $a : Column A - Condition 1
> Pattern $a : Column B - Condition 2
> Pattern $b : Column C - Condition 1
> Pattern $b : Column D - Condition 2
> Pattern $c : Column E - Condition 1
> Pattern $d : Column F - Condition 1
>
> 5.2 DRL
>
> $a : Pattern( Condition 1, Condition 2 )
> $b : Pattern( Condition 1, Condition 2 )
> $c : Pattern( Condition 1 )
> $d : Pattern( Condition 1 )
>
> Furthermore, at the request of the community, the behavior of "default
> values" changed so that the are only the default value for a new row (5.2
> onwards) and not the value used for an empty cell (5.0). I know this has
> caused some re-work for people migrating a legacy decision table from 5.0
> to 5.2 but since the impact, to date, has been small I do not plan on
> making any programmatic changes.
>
> With kind regards,
>
> Mike
>
> 2012/2/13 jian zhi <jianpzhi at yahoo.com>
>
> Mike,
>
> Thanks for the detail explanation.
>
> I found that the order of the conditions were changed again after I added
> two more conditions to the same package I used last time.
> I added default value to the first two conditions. Added the fifth
> condition by using the binding name created for the first condition.Add the
> sixth condition by using the binding name created for the second condition.
> After I import the data to 5.3 the fifth condition became the second and
> the sixth condition became the fourth. Also the default value for the first
> and second conditions are not listed in the rule source in 5.3. Could you
> please take a look? I attach the modified repository in the email.
>
> Thanks a lot,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* drools-user <rules-users at lists.jboss.org>
> *Sent:* Friday, February 10, 2012 12:59 PM
> *Subject:* [rules-users] Fwd: Migrating repository data from Drools 5.0
> to 5.3Final
>
> I suspect ConsumerAccountAssociationFact.hasAnyAccountClosed is a boolean.
>
> In 5.3 we handle data-types better than 5.0, so String, Numbers, Dates are
> Booleans have editors appropriate for the data-type and the resulting DRL
> only escapes values with quotation marks where needed (i.e. Strings and
> Dates). Boolean's in the table are now shown as Checkboxes. If the value is
> "true" it is ticked, if the value is "false" the checkbox is not ticked.
>
> I don't therefore believe there is any problem.
>
> On 10 February 2012 16:35, jian zhi <jianpzhi at yahoo.com> wrote:
>
> Mike,
>
> Thanks for the quick response. I downloaded the war and tested the fix.
> The order of the conditions are correct now. There is still a small problem
> in the last condition.
>
> In Drools 5.0 the source is consumerAccount :
> ConsumerAccountAssociationFact( hasAnyAccountClosed == "false" ).
> In Drools 5.3 the source is consumerAccount :
> ConsumerAccountAssociationFact( hasAnyAccountClosed == false ). It displays
> a square check box in the cell.
>
> Could you please take a look?
> Thanks,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* jian zhi <jianpzhi at yahoo.com>; Rules Users List <
> rules-users at lists.jboss.org>
> *Sent:* Thursday, February 9, 2012 4:55 AM
>
> *Subject:* Re: [rules-users] Migrating repository data from Drools 5.0 to
> 5.3Final
>
> You can get a build containing the fix from Nexus:
>
>
> https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.drools~guvnor-webapp~5.3.2-SNAPSHOT~~
>
> 2012/2/8 jian zhi <jianpzhi at yahoo.com>
>
> Mike,
>
> Is it possible to release a patch of 5.3?
>
> Thanks,
> Jian
>
> ------------------------------
> *From:* Michael Anstis <michael.anstis at gmail.com>
> *To:* Rules Users List <rules-users at lists.jboss.org>
> *Sent:* Wednesday, February 8, 2012 3:17 AM
>
> *Subject:* Re: [rules-users] Migrating repository data from Drools 5.0 to
> 5.3Final
>
> The problem has existed since 5.2 and would potentially affect loading any
> earlier version.
> Prior to 5.2 the object model used by the guided decision table did not
> hold a Pattern to which individual condition columns are bound.
> The conversion code groups individual condition columns into the
> appropriate group and moves the underlying column data accordingly (as
> there was no guarantee columns with the same bound name were consecutive).
> There was a problem with the creation and insertion of the new Pattern
> objects that relied upon the order of entries in a HashMap being
> consistent. This has now changed.
> I know others have been using the new guided decision table with old
> repositories without problem and our unit tests did not detect the problem
> either.
> AFAIK this is the first report of any such issue since the release of
> 5.2's betas, however I would be wrong to say there is no risk.
> sent on the move
> On 8 Feb 2012 01:22, "vadlam" <sreeram.vadlamudi at wellsfargo.com> wrote:
>
> does this issue happen for any previous version of Guvnor data such as 5.0
> or 5.1 or 5.2 exported and imported into a Guvnor 5.3 repository ?
>
> does this mean, we cannot rely on 5.3.0 version of Guvnor code when
> migrating data from a previous version and should rather apply the fix ?
>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/rules-users-Migrating-repository-data-from-Drools-5-0-to-5-3Final-tp3715772p3724570.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120217/0e2774c3/attachment.html
More information about the rules-users
mailing list