Thanks Edson for clarifying that in DRL, the "==" is the equals() method.
However, as this is not the case with java, can I tell the engine that "=="
means "==" and not "equals()"?
While the "equals()" will not return a wrong value, in my case, it might be
more expensive than "=="
Regards,
Prem
On 3/26/07, Edson Tirelli <[EMAIL PROTECTED]> wrote:
Prem,
I think you may be misunderstanding something. In DRL language, "==" is
the equals() method. So, if you write a rule:
rule A
when
UserId( name == "ABC" )
then
// do something
end
What the engine will do behind the scenes is name.equals("ABC"). So,
don't be afraid of doing that.
Also, "huge" means don't worry about it. :) You will get something like
log(n) comparisons in the worst case, so, leave that to the engine.
[]s
Edson
2007/3/26, Premkumar Stephen <[EMAIL PROTECTED]>:
>
> Hi Edson,
>
> Thanks for your reply.
>
> WRT your reply below (highlighted):
> In our environment, we only have one class and several instances of that
> class.
>
> We currently do not use the "==" constraint and we do a equals() on the
> name string. However, I am going to use "==" since there will be only one
> object with a particular name.
>
> Also, can you define what the number for "huge" is? How many buckets get
> defined initially for the hashing. Can I modify the initial size of this
> collection so that I will not have clashes. ( I happen to know exactly how
> many objects will be thrown into the engine)
>
> Is this set through configuration or would I have to recompile code to
> do this?
>
> Thanks,
> Prem
>
> On 3/23/07, Edson Tirelli < [EMAIL PROTECTED]> wrote:
> >
> >
> > Stephen,
> >
> > As long as you use an "==" constraint as your example shows, the
> > first alternative will be more performatic. This is because drools
> > indexes facts based on your constraints. So, your first case will
> > require a single "==" comparison to find user name "A" and a single
> > comparison to find user name "B". Of course, if you have huge amound
> > of
> > objects where hashcode for name start to clash, you may have more than
> > one comparison, but the effect is negligible when compared to all
> > other
> > costs of having that many facts.
> >
> > Second alternative works and will also hash object types, but it
> > will
> > create a lot more infrastructure classes and Rete Nodes to deal with
> > your 500 different classes. So it is a worst alternative for the
> > proposed scenario.
> >
> > []s
> > Edson
> >
> >
> > Premkumar Stephen wrote:
> >
> > > Hi,
> > >
> > > Consider that I have 500 instances of interface userI. Now, there
> > are
> > > 3000 rules currently written based on a combination of these
> > instances.
> > >
> > > if {
> > > $a : userI (name = "A")
> > > $b : userI (name = "B")
> > > }
> > > then
> > > {
> > > //do some actions
> > > }
> > >
> > > How many tests are needed for a match in the RETE network for this
> > rule?
> > >
> > > If I created 500 classes, one for each object, such as UserA
> > > implements userI and so on... my rule will look like:
> > >
> > > if {
> > > $a : UserA()
> > > $b : UserB()
> > > }
> > > then
> > > {
> > > //do some actions
> > > }
> > >
> > > Will this lead to better performance since there will only be one
> > such
> > > instance of this object?
> > >
> > > As for class-loading concerns, will there be a parsing/memory
> > penalty
> > > to be paid for having 500 classes now instead of one?
> > >
> > > Thanks!
> > >
> >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >rules-users mailing list
> > >rules-users@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> > >
> >
> >
> > --
> > Edson Tirelli
> > Software Engineer - JBoss Rules Core Developer
> > Office: +55 11 3124-6000
> > Mobile: +55 11 9218-4151
> > 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
> >
>
>
>
> --
> Regards,
> Prem
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
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
--
Regards,
Prem
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
