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(a)gmail.com&gt; *To:* jian zhi <jianpzhi(a)yahoo.com&gt; *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:- &lt;actionCols&gt; &lt;insert-fact-column&gt; &lt;width&gt;-1&lt;/width&gt; &lt;hideColumn&gt;false&lt;/hideColumn&gt; &lt;header&gt;SetEligible&lt;/header&gt; &lt;factType&gt;RuleEligibilityResult&lt;/factType&gt; * &lt;boundName&gt;RuleEligibilityResult&lt;/boundName&gt;* &lt;factField&gt;eligible&lt;/factField&gt; &lt;type&gt;Boolean&lt;/type&gt; &lt;valueList&gt;,true,false&lt;/valueList&gt; &lt;/insert-fact-column&gt; &lt;/actionCols&gt; 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(a)yahoo.com&gt; 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(a)gmail.com&gt; *To:* jian zhi <jianpzhi(a)yahoo.com&gt; *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(a)yahoo.com&gt; 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(a)gmail.com&gt; *To:* jian zhi <jianpzhi(a)yahoo.com>; Rules Users List < rules-users(a)lists.jboss.org&gt; *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(a)yahoo.com&gt; 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(a)gmail.com&gt; *To:* drools-user <rules-users(a)lists.jboss.org&gt; *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(a)yahoo.com&gt; 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(a)gmail.com&gt; *To:* jian zhi <jianpzhi(a)yahoo.com>; Rules Users List < rules-users(a)lists.jboss.org&gt; *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... 2012/2/8 jian zhi <jianpzhi(a)yahoo.com&gt; Mike, Is it possible to release a patch of 5.3? Thanks, Jian ------------------------------ *From:* Michael Anstis <michael.anstis(a)gmail.com&gt; *To:* Rules Users List <rules-users(a)lists.jboss.org&gt; *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(a)wellsfargo.com&gt; 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-f... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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

Again, thanks a lot for your help, Jian ________________________________ From: Michael Anstis <michael.anstis(a)gmail.com&gt; To: jian zhi <jianpzhi(a)yahoo.com&gt; 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:- &lt;actionCols&gt;     &lt;insert-fact-column&gt;       &lt;width&gt;-1&lt;/width&gt;       &lt;hideColumn&gt;false&lt;/hideColumn&gt;       &lt;header&gt;SetEligible&lt;/header&gt;       &lt;factType&gt;RuleEligibilityResult&lt;/factType&gt;       &lt;boundName&gt;RuleEligibilityResult&lt;/boundName&gt;       &lt;factField&gt;eligible&lt;/factField&gt;       &lt;type&gt;Boolean&lt;/type&gt;       &lt;valueList&gt;,true,false&lt;/valueList&gt;     &lt;/insert-fact-column&gt;   &lt;/actionCols&gt; 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(a)yahoo.com&gt; wrote: The repository is attached. The sources are listed below. On RHS the fact

> > >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

>10. |         RuleEligibilityResult.setEligible( true ); >11. |         insert(RuleEligibilityResult ); >12. | end > > >Thanks, >Jian > > > >________________________________ > From: Michael Anstis <michael.anstis(a)gmail.com&gt; >To: jian zhi <jianpzhi(a)yahoo.com&gt; >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(a)yahoo.com&gt; wrote: > >As long as the result of the evaluationis 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(a)gmail.com&gt; >>To: jian zhi <jianpzhi(a)yahoo.com>; Rules Users List <rules-users(a)lists.jboss.org&gt; >>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(a)yahoo.com&gt; >> >>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

>>> >>> >>>Thanks a lot, >>>Jian >>> >>> >>> >>>________________________________ >>> From: Michael Anstis <michael.anstis(a)gmail.com&gt; >>>To: drools-user <rules-users(a)lists.jboss.org&gt; >>>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(a)yahoo.com&gt; 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(a)gmail.com&gt; >>>>To: jian zhi <jianpzhi(a)yahoo.com>; Rules Users List <rules-users(a)lists.jboss.org&gt; >>>>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(a)yahoo.com&gt; >>>> >>>>Mike, >>>>> >>>>> >>>>>Is it possible to release a patch of 5.3? >>>>> >>>>> >>>>>Thanks, >>>>>Jian >>>>> >>>>> >>>>> >>>>>________________________________ >>>>> From: Michael Anstis <michael.anstis(a)gmail.com&gt; >>>>>To: Rules Users List <rules-users(a)lists.jboss.org&gt; >>>>>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(a)wellsfargo.com&gt; 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-f... >>>>>>Sent from the Drools: User forum mailing list archive at Nabble.com. >>>>>>_______________________________________________ >>>>>>rules-users mailing list &gt;&gt;&gt;&gt;&gt;&gt;rules-users(a)lists.jboss.org >>>>>>https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> >>>>>_______________________________________________ >>>>>rules-users mailing list &gt;&gt;&gt;&gt;&gt;rules-users(a)lists.jboss.org >>>>>https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>rules-users mailing list &gt;&gt;&gt;&gt;&gt;rules-users(a)lists.jboss.org >>>>>https://lists.jboss.org/mailman/listinfo/rules-users >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>>_______________________________________________ >>>rules-users mailing list &gt;&gt;&gt;rules-users(a)lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> >>>_______________________________________________ >>>rules-users mailing list &gt;&gt;&gt;rules-users(a)lists.jboss.org >>>https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> >> > > >