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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
 
_______________________________________________
rules-users mailing list
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

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users