8:08 a.m.
In the documents this is dicussed briefly:
"). Object models can often have complex relationships and hierarchies
in them - for rules you will want to simplify and flatten the model
where possible, and let the rule engine infer relationships (as it
provides future flexibility."
What does it mean that the rule engine can infer relationships?
Are there performance reasons for having a flat model?
Cheers,
Blair
8:59 a.m.
Christie, Blair wrote:
In the documents this is dicussed briefly:
"). Object models can often have complex relationships and hierarchies
in them - for rules you will want to simplify and flatten the model
where possible, and let the rule engine infer relationships (as it
provides future flexibility."
What does it mean that the rule engine can infer relationships?
Are there performance reasons for having a flat model?
We can exploit cartesian products and indexing for == constraints. If
its a nested model we have to iterate over all possible instances. The
other problem is if the nested model changes the engine has no idea this
has happened, which if you are not careful can lead to data integrity
issues.
Cheers,
Blair
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:56 a.m.
Mark Proctor wrote:
We can exploit cartesian products and indexing for == constraints. If
its a nested model we have to iterate over all possible instances. The
other problem is if the nested model changes the engine has no idea this
has happened, which if you are not careful can lead to data integrity
issues.
I think that plain flat model is too limited for real life. In fact in most
situations you just cannot avoid nesting.
For example when I try to search for cars with 4 cylinder engine the best
approach I found is:
rule "get 4 cylinder cars"
when
Car ( $e: engine != null ) // car without engine? where are we? :)
Engine ( cylinderCount == 4 ) from $e
then
System.out.println("Found 4 cylinder car.");
end
This should be quite effective. I doubt that the following solution with
cartesian product has the same complexity:
rule "get 4 cylinder cars"
when
$e: Engine ( cylinderCount == 4 )
Car ( engine == $e )
then
System.out.println("Found 4 cylinder car.");
end
Using approach Car ( engine.cylinderCount == 4 ) tends to raise
NullPointerException and I had problems with assigning the cylinderCount to
variable so this was not a way to go for me.
But this is not much a problem for me as I am a programmer and I can
understand the rule language and data structures. But when business users
are to edit rules (using Guvnor as the tool of choice) we come to troubles.
I think that guided editor for rules does not allow "from". More importantly
- can you create such a structure for a test scenario? I failed. :(
--
View this message in context:
http://www.nabble.com/Why-is-a-flat--object-recommended--tp15567690p24954...
Sent from the drools - user mailing list archive at Nabble.com.
11:09 a.m.
Java pojo's nested fields is just a weak way to represent relations
between objects. If you want to exploit those properly in a rule engine,
best to use real relations.
Mark
Libor Nenadál wrote:
Mark Proctor wrote:
> We can exploit cartesian products and indexing for == constraints. If
> its a nested model we have to iterate over all possible instances. The
> other problem is if the nested model changes the engine has no idea this
> has happened, which if you are not careful can lead to data integrity
> issues.
>
>
I think that plain flat model is too limited for real life. In fact in most
situations you just cannot avoid nesting.
For example when I try to search for cars with 4 cylinder engine the best
approach I found is:
rule "get 4 cylinder cars"
when
Car ( $e: engine != null ) // car without engine? where are we? :)
Engine ( cylinderCount == 4 ) from $e
then
System.out.println("Found 4 cylinder car.");
end
This should be quite effective. I doubt that the following solution with
cartesian product has the same complexity:
rule "get 4 cylinder cars"
when
$e: Engine ( cylinderCount == 4 )
Car ( engine == $e )
then
System.out.println("Found 4 cylinder car.");
end
Using approach Car ( engine.cylinderCount == 4 ) tends to raise
NullPointerException and I had problems with assigning the cylinderCount to
variable so this was not a way to go for me.
But this is not much a problem for me as I am a programmer and I can
understand the rule language and data structures. But when business users
are to edit rules (using Guvnor as the tool of choice) we come to troubles.
I think that guided editor for rules does not allow "from". More importantly
- can you create such a structure for a test scenario? I failed. :(
2:02 a.m.
Mark thank you for your reply! What you are saying is that the example Car (
engine.cylinderCount == 4 ) is wrong and correct is:
$e: Engine ( cylinderCount == 4 )
Car ( engine == $e )
which is representation of real relations? I thought about the example I
wrote here overnight and I realized that the solution without 'from' in fact
can be optimal as it can easily eliminate non-matching facts without going
through the object structure.
Cheers,
Libor
Mark Proctor wrote:
Java pojo's nested fields is just a weak way to represent relations
between objects. If you want to exploit those properly in a rule engine,
best to use real relations.
Mark
Libor Nenadál wrote:
> Mark Proctor wrote:
>
>> We can exploit cartesian products and indexing for == constraints. If
>> its a nested model we have to iterate over all possible instances. The
>> other problem is if the nested model changes the engine has no idea this
>> has happened, which if you are not careful can lead to data integrity
>> issues.
>>
>>
> I think that plain flat model is too limited for real life. In fact in
> most
> situations you just cannot avoid nesting.
> For example when I try to search for cars with 4 cylinder engine the best
> approach I found is:
>
> rule "get 4 cylinder cars"
> when
> Car ( $e: engine != null ) // car without engine? where are we? :)
> Engine ( cylinderCount == 4 ) from $e
> then
> System.out.println("Found 4 cylinder car.");
> end
>
> This should be quite effective. I doubt that the following solution with
> cartesian product has the same complexity:
>
> rule "get 4 cylinder cars"
> when
> $e: Engine ( cylinderCount == 4 )
> Car ( engine == $e )
> then
> System.out.println("Found 4 cylinder car.");
> end
>
> Using approach Car ( engine.cylinderCount == 4 ) tends to raise
> NullPointerException and I had problems with assigning the cylinderCount
> to
> variable so this was not a way to go for me.
>
> But this is not much a problem for me as I am a programmer and I can
> understand the rule language and data structures. But when business users
> are to edit rules (using Guvnor as the tool of choice) we come to
> troubles.
> I think that guided editor for rules does not allow "from". More
> importantly
> - can you create such a structure for a test scenario? I failed. :(
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://www.nabble.com/Why-is-a-flat--object-recommended--tp15567690p24967...
Sent from the drools - user mailing list archive at Nabble.com.
5565
days inactive
6107
days old
4 comments
3 participants
participants (3)
-
Christie, Blair -
Libor Nenadál -
Mark Proctor