Forwarded to drools-user sent on the move
---------- Forwarded message ---------- From: "Michael Anstis" <[email protected]> Date: 17 Feb 2012 21:24 Subject: Re: [rules-users] Fwd: Migrating repository data from Drools 5.0 to 5.3Final To: "jian zhi" <[email protected]> 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" <[email protected]> wrote: > Sorry, the error was Unable to save this asset, as it has been recently > updated by [xxx]. > > ------------------------------ > *From:* jian zhi <[email protected]> > *To:* Michael Anstis <[email protected]> > *Cc:* Rules Users List <[email protected]> > *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 <[email protected]> > *To:* jian zhi <[email protected]> > *Cc:* Rules Users List <[email protected]> > *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 <[email protected]> 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 <[email protected]> > *To:* jian zhi <[email protected]> > *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 <[email protected]> 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 <[email protected]> > *To:* jian zhi <[email protected]> > *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 <[email protected]> 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 <[email protected]> > *To:* jian zhi <[email protected]>; Rules Users List < > [email protected]> > *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 <[email protected]> > > 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 <[email protected]> > *To:* drools-user <[email protected]> > *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 <[email protected]> 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 <[email protected]> > *To:* jian zhi <[email protected]>; Rules Users List < > [email protected]> > *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 <[email protected]> > > Mike, > > Is it possible to release a patch of 5.3? > > Thanks, > Jian > > ------------------------------ > *From:* Michael Anstis <[email protected]> > *To:* Rules Users List <[email protected]> > *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" <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
