Hi Edson,
i have some problem...
*core_preference_text* this my table name.Row like "VARIABLE_CODE"
VARCHAR2(60 BYTE)"
i need write dsl,dslr files related data validation to the table.
1. variable_code should be unieque per enterprise_id
2. variable_code can not be updated
give me some suggestion ..how to write dsl,dslr file related two
conditions.ASAP..
=====
Chanti
On Fri, Jun 6, 2008 at 8:19 PM, Edson Tirelli <tirelli(a)post.com> wrote:
Drools 5 implements a completely new propagation algorithm that
allowed us to get rid of shadow proxies from the core engine. So, you will
not have the problem.
But for 4.0.x, if you are a community user, best you can do is open a
JIRA with a test case to reproduce your problem. If we release a 4.0.8
version, we can fix your issue there, but at this moment we don't know if
there will be a 4.0.8 release or if the next release will be 5.0.
If you are a Drools subscriber at Red Hat, then you can simply open a
support case there and they will fix and provide a patch for you.
[]s
Edson
2008/6/6 Sibylle Duerr <sibylle.duerr(a)mymail.ch>:
> Thanks Edson,
>
> but the collections do return an empty collection. hm, I just tested this
> ones again and it worked fine. no exception when the set was empty. I will
> keep an eye on this and test some more but seems to work now for me.
>
> and for the other problem I then hope for 5.0 :).
>
> and what about the last problem I described before?
>
> best regards
> Sibylle
>
>
>
> Edson Tirelli wrote:
>
>>
>>
>> Sibylle,
>>
>> Unfortunately, this is the way it was implemented to be, under a
>> kind-of "fail-fast" philosophy we were following. I do think there is
value
>> in changing things in 5.0 so that, for instance:
>>
>> ProcessModel($activities : activities) from $models
>>
>> Simply does not match, instead of raises a CCE, in case the model is a
>> TypeModel.
>> But for 4.0.x, that is how things work.
>>
>> The only suggestion I can give you is, in your second problem, to not
>> return null on your collections. Simply return empty collections:
>>
>> class Project {
>> ...
>> public List getModels() {
>> if( this.models == null ) {
>> return Collections.emptyList();
>> }
>> return this.models;
>> }
>> ...
>> }
>> This is usually a good thing, unless you have a specific semantics
>> for null collections in your domain model.
>>
>> []s
>> Edson
>>
>> 2008/6/6 Sibylle Duerr <sibylle.duerr(a)mymail.ch>:
>>
>> Hi there,
>>
>> I have three issues, where I'm not sure if these are bugs in
>> drools, or if this is just the way it has to be.
>>
>> the used classes in this case are:
>>
>> Project
>> Model
>> ProcessModel extends Model
>>
>> only the Project is in the working memory, because I didn't want
>> to load all elements due to performance issues (there can be
>> thousends of elements to load at startup).
>>
>> if I have the following rule:
>>
>> Project($models : models)
>> ProcessModel($activities : activities) from $models
>>
>> there happen to be two problems. if the project does not only
>> contain ProcessModels but also TypeModels or others (all extend
>> Model), this leads to a ClassCastException.
>> I can solve this by writing the rule as follows:
>>
>> Project($models : models)
>> $m : Model(eval($m instanceof ProcessModel)) from $models
>> ProcessModel($activities : activities) from $m
>>
>> but this is not really nice and I hope there is a better solution
>> for this, is there?
>>
>> the second problem this rule gives me, is when the set 'models' is
>> empty. that will also throw an exception. to solve this I write:
>>
>> $p : Project(eval($p.hasModels()), $models : models)
>> $m : Model(eval($m instanceof ProcessModel)) from $models
>> ProcessModel($activities : activities) from $m
>>
>> and I need to use this in each case where I have possible empty sets.
>>
>>
>> the last problem I encountered when I tried to load all elements
>> to the working memory and then redefine some rules. used classes:
>>
>> Aggregation extends DomainElement
>>
>> rule:
>>
>> Aggregation(owner.owner != type.owner)
>>
>> causes some exception. the root exception is a ClassCastException:
>> ProxyShadowProxy cannot be cast to Aggregation.
>> when I rewrite the rule as:
>>
>> $element : DomainElement(eval($element instanceof Aggregation))
>> Aggregation(owner.owner != type.owner) from $element
>>
>> everything works fine. but that again is not a nice solution.
>>
>> any help?
>>
>> best regards
>> sibylle
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>>
>> --
>> Edson Tirelli
>> JBoss Drools Core Development
>> Office: +55 11 3529-6000
>> Mobile: +55 11 9287-5646
>> JBoss, a division of Red Hat @
www.jboss.com <
http://www.jboss.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
>
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @
www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users