I
can turn that question around...
If
the user has written objects MyFact and MyEvent is it fair to expect
them to have to declare it in the DRL?
I
don't know what Events are to do in Drools so don't which is the more
reasonable approach. Is it just for network optimisation as you say, or
will Drools be calling into members?
This
is much more interesting than (my) work ;-)
Michael,
Yes, the
session.insertEvent() API is something other engines (like iLog
JRules) have. I initially discarded that idea, but since you
mentioned, we may need to reconsider it.
Anyway, the
API would solve this part of the problem, but the whole scenario is:
The engine must know at the compile time exactly what
classes/interfaces used in rules are events, so that it can optimize
the network. That is achievable by using any of the syntaxes bellow
(I'm not sure which one to use yet):
import event a.b.c.Foo;
(or)
import event a.b.c.*;
or explicit
saying:
declare event
a.b.c.Foo;
Once the user declared that
something is an event, do you think it is fair/acceptable to force the
user to use a different API to insert events into the engine?
session.insert(); for regular facts
session.insertEvent();
for events
[]s
Edson
2007/11/8, Anstis, Michael (M.) <manstis1@ford.com
>:
Here's
my 2 cents - as a non-contributor to Drools codebase ;-)
You
could add insertEventFactTypeThingie to the API? Then you need just
check that the class has been declared as an event in the DRL
similar to
what must already happen for normal DRL imports. I
personally don't have
issue with implementing a marker interface
(this is what frameworks like
Hibernate, EJB3 and Spring etc
have been imposing for years). What "wiring"
does the POJO need
to become an Event for use in Drools? Are you trying
to
internalise too much at the risk of making the event mechanism
inflexible?
Cheers,
Mike
-----Original
Message-----
From: rules-dev-bounces@lists.jboss.org
[mailto:
rules-dev-bounces@lists.jboss.org] On Behalf Of
Matthias
Sent: 08 November 2007 13:09
To: rules-dev@lists.jboss.org
Subject: Re:
[rules-dev] Determining if a class is an event or not
Edson
Tirelli <tirelli <at> post.com>
writes:
>
>
> All,
I reached a point where I need to make a design decision
and
would
like your opinion about it. Imagine the
following scenario: A user has a
domain model like
this:package a.b.c
> ;public interface Event { ... }package
x.y.z;public class MyEvent
implements
a.b.c.Event
{...} Then, in his DRL file he writes:package
p.q.r;import
event
a.b.c.* ; rule
Xwhen
> Event( ...
)then ...end So, it is clear that
a.b.c.Event should
be
handled as an event by the
engine. At runtime, the user asserts an
object
of
the class x.y.z.MyEvent into the working memory.
Seems clear to me (and
probably
to the user) that MyEvent
should be handled as an event, since by DRL
semantics,
>
a.b.c.* are all events, and by OO class hierarchy concept,
since
a.b.c.Event
is an event, x.y.z.MyEvent is an event
too. My question is: how the engine
knows that
MyEvent is an event, since it only has the
x.y.z.MyEvent
> class as input? The
only answer I have is that when the first MyEvent
instance is
asserted into the working memory, we must get the class name and
iterate over all event import declarations checking for a match.
In case no
one
is found, we need to repeat the process for
each interface and each class up
in
the MyEvent hierarchy.
Once this process is complete, we cache the results
in
the
ObjectTypeConf.
> This may be a quite
heavy process to be executed each time a fact of a
different
class is asserted in the working memory for the first time, but
I
can't think a different user-friendly way to solve the
question.
> The alternatives would be
intrusive, IMO, breaking the drools premise
to
work with
user-defined POJOs as facts: use anotations to annotate
classes
that
are events, or mandate users implement a specific
interface for events.
> Any better
idea? []s Edson --
Edson Tirelli Software
Engineer
- JBoss Rules Core
Developer Office: +55 11 3529-6000 Mobile: +55
11
9287-5646
> JBoss, a division of Red
Hat <at> www.jboss.com
>
>
>
_______________________________________________
> rules-dev
mailing list
> rules-dev <at> lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
Edson,
I got your striving not to mandate users implement a
specific interface for
events. However, why not at least
introducing an empty event interface (i.e.
a
marker interface,
similar to the Serializable interface in Java) the
user-defined
event class(es) have to implement? This way, when inserting a
MyEvent instance, you can simply check whether it implements the
event
interface
(by means of 'instanceof'). Moreover, while
parsing the import statements of
a
rule file, it enables you
to double-check whether all the "event imports"
really
refer
to classes implementing the (empty) event interface.
In this
regard, for me another question raises: Without making
any
restrictions
on the structure for a user defined event
class, how do you make sure it has
all
the required attributes of an event (which in
my opinion must be a
timestamp,
at least) and how do you
access them (necessary for temporal relationships)?
Having said
this, in my opinion defining an empty event interface may not be
sufficient; in addition, it must force the user to implement a
method
returning
the event's occurrence date (i.e. the
timestamp) at least... Or how would
you
handle this
issue?
Matthias
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev
mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software
Engineer - JBoss Rules Core Developer
Office: +55 11
3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com