Edson Tirelli schrieb:
2009/8/20 André Thieme <address.good.until.2009.dec.14(a)justmail.de
<mailto:address.good.until.2009.dec.14@justmail.de>>
Would there not be an addition to the syntax needed, for the default
rule language? For mvel it would not require a change I guess.
No, as I mentioned to you, the idea is for the DRL to remain the same,
so that the rules author does not have to worry about what the IT guys
are doing with the domain model. So, the rules author would write:
Customer( name == "bob" )
The IT guy would simply use a configuration to tell the engine: this
object type uses a map format, that one is a POJO, that other is an XML
entity, etc.
For instance, if he wants to do that in DRL (he could also use API, or
conf files), he could do:
declare Customer
@format( map )
end
declare Order
@format( pojo )
end
So, we have a clear distinction between the technical aspects and the
business aspects of the application.
Ah okay, that makes sense and sounds very good!
So, when Maps become first class not the rules will introduce a new
syntax, but intead we would add some declarations.
The only two challenges I see with that is:
1. to allow the keys to be any object and not just only strings.
2. differentiate between fields of the Maps and keys
Point 1.:
Your example Customer( name == "bob" ) currently is expressed as:
$m : Map(eval($m.get("type" == "Customer")) &&
eval($m.get("name") == "bob"))
right?
In the declaration for Customer above one would probably have to specify
that for a Map being a Customer depends on the key "type".
But what would Customer( name == "bob" ) look like if name was not a
String but some other Object?
This info should go into the declare part, yes?
Point 2.:
in your other reply you gave the example:
Map( this["type"] == "Point", $x : this["x"], size == 5 )
Projected on the Customer( name == "bob" ) example we would need to
differentiate, in Java terms, between:
map.get("size") == 5 and map.size() == 5
So Customer(name=="Bob" && size==5) needs to be clear.
Your clojure macro would generate always the same DRL code
"Customer(
name == "bob" )", but you said yourself that clojure is 100% java
compatible, so imagine the enterprise had a domain model implemented as
pojos already and as part of the new application some new entities are
modeled in clojure. The macro would generate always the same code, but
you would configure some entities in the domain as POJOs and other
entities as Maps.
Yes, it would be similar like that.
What I first do is to write a general macro named "rule" which should
be able to express everything that currently is possible in Drools.
On top of that macro I will define some more, for exmaple there could be
a macro "map-rule" which is specialized on maps.
This can get even more specialized, but in the end all those macros will
expand into the general one, and the general one will generate a
string S which contains all rules and then do a
ResourceFactory.newByteArrayResource(S.getBytes("utf-8")) to get the
rules into Drools, which will from then on continue.
And the way as you suggest it, to let the Drools syntax always be the
same, it may even be easier for me to write my lib. Good :)
Hmm, but the MVEL syntax can not magically eliminate the eval.
Under the
hood the map accesses will still be inside an eval. Marc confirmed that
a few days ago.
MVEL only hides this from the user. This is what I will also do.
But under the hood it will become
$a:Map()
$b:Map()
eval( $a.get("type") == "Customer" )
eval( $b.get("type") == "DailyOrders" )
Here I think we have other misunderstanding. I will try to explain, but
ideally you need to learn a bit about the Rete algorithm to see the
whole picture.
Yes, I will read soon (I hope) Chapter 12 of my Drools book,
by Michal Bali.
There are 2 types of eval(). Inline eval() and top level eval().
Ah, I see, I didn't know that.
What you wrote above is a top level eval, meaning it will become
a node in the rete network. So your example above generates an
"execution plan" (making an analogy with SQL) that will get all Maps in
the working memory, join them in tuples size 2, and then test each tuple
for the 2 evals. So, you see why this will generate C(n,2) partial
matches, while C(n,2) as we know is n!/(n-2)!, what is really bad for
growing "n".
Very good, now I understand what you mean. Thanks for the sql analogy.
Now, the same thing could be written using inline evals as:
$a:Map( eval( $a.get("type") == "Customer" ) )
$b:Map( eval( $b.get("type") == "DailyOrders" ) )
Excellent, this is very helpful. I just tried this out and was also
successful with it. Now I can have my code generating alpha constraints
without having to use MVEL.
In this case, the inline eval() will generate an alpha constraint
in
the network, i.e., it will be applied BEFORE the joins. So, instead of
doing all combinaions possible between all maps as above, it will first
find all Customer maps and all DailyOrders maps and only after that will
make a join between them. So you get Customers * DailyOrders partial
matches. The above evals are semantically equivalent as:
$a:Map( this[ "type" ] == "Customer" )
$b:Map( this[ "type" ] == "DailyOrders" )
> But currently I am forced to produce this cross product, as there is
no direct support for Maps yet.
I hope that by the above you see that the problem of the cross products
is not a problem with Maps support, but rather a question of how to
write better rules.
Yes, thanks to your good explanation this is now totally clear.
I just didn't know about inline evals. In my first tries I did something
like Map(this.get("type") == "Customer") but that didn't work.
I did not try Map(this["type] == "Customer") because I thought this is
not possible without setting the dialect to MVEL. Now I understand that
part.
For me only two issues remain
1. I can not set vars to values of Maps if they keys don't happen to be
strings. So, I now *can* do:
$a:Map( eval($a.get("type") == "Customer"), $id :
this["id"] )
and then refer to $id in other parts of the LHS or in the RHS.
But I get an error for
global Foo $x;
...
$a:Map( eval($a.get("type") == "Customer"), $id : this[$x] )
This results to a compilation error:
Unable to create Field Extractor for 'this[$x]' : [Rule name='Clojure
test 2']
org.drools.RuntimeDroolsException: Field/method '$x' not found for
class 'java.util.Map'Rule Compilation error : [Rule name='Clojure
test 2']
myNamespace/Rule_Clojure_test_2_0.java (14:722) :
$id cannot be resolved
So it seems that MVEL does not like global vars between the brackets
IF the expression is not followed by some operator. I updated my
mvel.jar as you suggested some days ago, and now I can use vars for
binary operators:
global Foo $key;
...
$a:Map( this[$key] == 45 )
2. This is a minor issue: I can't do it without MVEL. I tried
$a:Map( eval($a.get("type") == "Customer"), $id :
eval($a.get("id")))
and I tried
$a:Map( eval($a.get("type") == "Customer"), eval($id :
$a.get("id")))
but both didn't work.
Thanks Edson, and many greetings,
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/