Edson,
As I see it,
Solutions (1) and (2) lend the responsabilitie of knowing what
they are doing on developers, and can be tricky...but at the end
could be
an optimal solution...so they should exists.. solution (3) makes all
the work clean and easy, but can introduce over load work, so for first
instance I'll set up solution (3) so an advanced developer coul
deactivated by developer with some config API, so they could make their
application work faster if they know what they are doing...
OF course i dont like to break the POJO paradigm on drools, is one of
the things make drools THE choice... but introduce extra check to
add a feature that maybe not all devs will use is something that an
advanced dev should decide...
my 2 cents..
:)
btw: Im a little lost on this event feature (last moths Iv been
working on other things) so, where can I read about this event
handle?..is a new
feature from 4.0.2?...is on the docs? Thx.
On 12-11-2007, at 13:54, Edson Tirelli wrote:
Mike, Felipe and Matthias,
Thank you for all your feedback. It really helps to understand
the different point of views.
I will try to summarize my understanding of the issue based on
your comments so far and on the technical requirements of the
system. First we need to understand the 2 different times where the
information about an instance of a class (fact) being an event or
not is needed:
* At compile time: this is required to actually create the
optimized network (including the ObjectTypeNodes that Mike
mentions). It is a must have and we can't avoid it. The best way to
do that IMO is using a specific declarative statement in the rules
files. I'm thinking about either an "import event x.y.z.Event"
statement, or a specific "declare event x.y.z.Event". This is pure
syntax to let the engine know what is an event and what is not, at
rulebase compilation time. If most users think a syntax like "I
want to declare that the x.y.z.Event instances are events" is more
appropriate, :) we could do it, but as it is today, I like the idea
of using a simple "event" keyword in import statements, the same
way we import static functions:
import a.b.c.Fact; // a simple fact import
import function java.lang.Math.max; // a static function import
import event x.y.z.Event; // an event import
If we were an engine working with templates or any other type
of fact that did not allows inheritance, that would completely
solve the problem. But we work with POJOs as facts, and POJOs
(being plain java) support inheritance. So:
* At runtime: even knowing, at compile time, that x.y.z.Event is an
event, at runtime a user may assert p.q.r.AnotherClass into working
memory. Now, is p.q.r.AnotherClass an event or not? We need to
determine that at the time the first instance of p.q.r.AnotherClass
is asserted into the working memory. At this time, in runtime, we
create an ObjectTypeNode for this fact class that previously was
not known by the engine. A few options on how to determine that
were discussed here:
1. Mandate all classes that are events implement an "Event"
interface. I don't like this solution, as mentioned in a previous e-
mail, because it breaks the Drools paradigm of working with user
defined domain models, without contaminating them with drools
specific code. Although, by your comments, seems that this would be
an acceptable solution.
2. Create a separate API (something like "session.insertEvent()")
to insert events into the working memory. This would also "solve"
the problem, but:
* "What happens if a user uses this API to insert a class that was
not declared as event at compile time?". From a technical
perspective, this will lead to unpredictable behavior and possibly
to inconsistencies in the reasoning algorithm, specially because
events do not need shadow facts (they are supposed to be immutable).
* "What happens if a user uses the regular 'session.insert()' API
for a class that was declared as an event at compile time?". Same
as above with the additional problem that the user may try to call
update() or retract() for that given fact, what is not allowed for
events. Again, unpredictable behavior.
My worry is that the only solution for the above 2 issues would
be to implement a verification routine that would validate if a
fact asserted as event is indeed an event according to what was
declared at compile time, and vice-versa. Note though, that this
validation procedure would be basically the same required for
solution number 3 bellow, but would have to be executed at every
insert()/insertEvent() call, making it more costly than the
completely automated decision.
3. Implementing an automated decision procedure, analyzing the
class hierarchy of the inserted fact, every time a fact of a
previously unknown class is inserted into working memory. Due to
the problems presented in the previous solutions, this is still my
preferred approach. Its main drawback is the class hierarchy
analysis that is not simple to do and at the same time is a bit
heavy, but would happen only when the first fact of a previously
unknown class is inserted into working memory.
So, we can probably implement solution (1) and (2) as options,
but at this time, I can't see how to avoid implementing support for
(3). But having (3), is it worth to have (1) and/or (2) too, or
would it only confuse users?
Thanks all for all the feedback so far.
[]s
Edson
2007/11/12, Anstis, Michael (M.) <manstis1(a)ford.com>:
Hi Felipe,
I recall Edson saying that "Event" classes need to be ascertained
at (RETE) compilation time - which, I think, rules out the API
addition. I was hoping Edson, time permitting, would explain how
declarative (fact-centric class) imports currently work to generate
an ObjectTypeNode and therefore to understand how his proposal to
create cached ObjectTypeConf instances for Event-centric classes
compares. My reasoning being that if the process is similar the new
event stuff should be no different; simply having two
ObjectTypeNodes - one for Events and another for Facts. See attached.
It's quite possible our exchanges have given Edson time to come to
his own conclusion and the solution is now being coded!
With kind regards,
Mike
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-
bounces(a)lists.jboss.org] On Behalf Of Felipe Piccolini
Sent: 12 November 2007 13:25
To: Rules Dev List
Subject: Re: [rules-dev] Determining if a class is an event or not
Well,
IMHO for the experience I have I suggest to implement both
solutions:
-an API insertEvet() so the user can implement the mechanism to manage
their rules knowing when a fact is an event or not.
-an Interface Event so when the user cant manage the flow asserting
facts, when
he cant know when a fact is or not an event, then maybe he can wrap
some facts on this
interface and the API insert() internaly can check if the fact is
an event or not and call insertEvent if
necesary.
:)
On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote:
> 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(a)lists.jboss.org
> [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias
> Sent: 08 November 2007 13:09
> To: rules-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
Felipe Piccolini M.
felipe.piccolini(a)bluesoft.cl
_______________________________________________
rules-dev mailing list
rules-dev(a)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
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev