5:28 p.m.
This is a follow up to my reply to
http://article.gmane.org/gmane.comp.java.drools.user/12319 :)
What I would like are some changes to PackageBuilder (line numbers at
r21562):
Remove/change lines 632-641 as they call
pkgRegistry.getPackage().getFactTemplate, where fact templates are
compiled into the package after 393, which is after 381->551->570->634.
Ok, so perhaps it is possible, if you define your templates in another
package...
Change TypeDeclaration.Format to a class, instead of an enum. We want
our own type. At line 632, insert something like the following:
final String format =
ObjectUtils.defaultIfNull(typeDescr.getMetaAttribute(
TypeDeclaration.ATTR_FORMAT).toLowerCase(), "pojo");
//ATTR_FORMAT="format"
TypeFactory factory = packageDesc.getTypeFactory(format); //where
packages have a typeFactory declaration of a class that implements
TypeFactory (which has a getFormat() for registration purposes)
TypeDeclaration type = factory.create(typeDescr);
lines 643-674 get moved into PojoTypeFactory.create();
Something needs to be done to TypeDeclaration to allow non-class based
implementations. After all, it makes no sense (to me) to call a method
that then just refers to a map of name-values.
However, drools uses java object types/classes heavily for rules
optimisations - and type references. Is this unavoidable? Was this the
fundamental problem with templates - that one could not be composed
inside another because the type could not be referenced (by a class)?
Also, I'm looking for a way to do partial compilation... I want to
create a description with fundamental declarations and imports for our
product to simplify the text ones, but I can't figure out how to merge -
is it just a case of declaring my core package, and then "adding" the
same one from the file?
Cheers
Stephen
6:14 p.m.
Hi Stephen,
I am kind of lost by the line numbers and changes you mentioned. Maybe
you can submit a code patch? This way we can see exactly what is being
changed, discuss the impact if it is the case, and apply it to the codebase.
Was this the fundamental problem with templates
There are a few issues on how templates were implemented. The main one,
and probably the main reason we did not extended the functionality to
support any underlying fact format, is the syntax support on semantic code
blocks. I.e. dialect support, specially on consequences. For instance,
imagine that you want to read the attribute "age" from the "Person"
fact in
the consequence of a rule. Ideally, you want to do something like bellow,
does not matter what the underlying format of Person is. After all, Person
is a fact:
rule ...
when
$p : Person(...)...
then
int age = $p.age;
end
Above will work for java and MVEL, if the format is POJO. Now with
templates, you must do something like:
int age = ((Integer) $p.getAttribute( "age" )).intValue();
Now, imagine that your fact is an XML element, or a database record? In
the end, your rules will be tied to the underlying format and format
pluggability will lose much of its value.
So, the big issue, IMO, is that we must implement format transparency on
the semantic code blocks. Implementing format support for non-semantic
blocks is pretty straight-forward and the proof-of-concept is that we do it
already (although not extensively tested) with templates.
But don't give up. :) It is possible to do it, we just lack manpower to
do all we want, and if it is something you will use, we can work together
using an incremental approach. First we make sure everything is correctly
wired and working for multiple underlying formats, and then we deal with the
dialect support.
Regarding merge of packages, it is quite simple. You can merge packages
either at compilation time, by using the package builder and adding your
prereq artifacts first, or directly at rulebase building time by adding
multiple packages. Also, Mark did an extensive work on binary references
rewiring a couple of weeks ago to ensure we have a clean binary in-memory
structure, without classloader leaks.
Cheers,
Edson
2008/8/27 Stephen Kestle <stephen.kestle(a)orionhealth.com>
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
4:32 p.m.
Edson Tirelli wrote:
Yes, I thought $person.getFieldValue("age") was a bit
annoying...
But the more I look into the code and interfaces around FactTemplate,
the more I like it's approach and it's fit for ontological (dynamic
model/schema) data models.
1. MVEL etc needs to reflect on methods to give the dialect support
to POJOs
2. To make an dynamic model fit to OO, TypeDeclarations would need to
be able to generate interfaces, an a proxy mechanism would be
needed for the map-backed model - this just seems too retarded
3. Surely TypeDeclaration should be an interface with methods to gain
method information and types etc. PojoTypeDeclaration would
implement this using the reflective model as current.
TemplateTypeDeclaration would use the FactTemplate to do it (if it
was being continued). This way maximum pluggability is maintained.
4. Isn't this what FactTemplate does? I see the problem is that
FactTemplate was an add-on, instead of a super set / *the* way of
accessing fact type information.
5. Is this idea awesome? Calling TypeDeclaration.execute("getAge")
does not seem any different to how it is now - how "compiled" are
these rules? If they are byte-compiled, then that optimisation
could be done for PojoTypeDeclaration.
How correct am I on these points?
Cheers
Stephen
5:55 p.m.
Hi Stephen,
Nice job inspecting our code base.
The complete type abstraction layer in Drools is composed by several
interfaces and its corresponding implementations.
* TypeDeclaration is just that: a stateless type representation for
describing Facts. It is not supposed to know how to actually read fact
value, attributes, etc. It is used at compilation and runtime to read
metainformation about a fact and is not tied to any particular fact
instance.
* To handle a Type, i.e., evaluate if a type matches a pattern and
manipulate the type at compile and runtime, we have an ObjectType interface.
That interface, today, has 2 implementations: ClassObjectType (for POJO) and
FactTemplateObjectType (for templates).
* To read the internals of a type we have the ReadAccessor and WriteAccessor
interfaces. These interface implementations are lazyly bytecode generated
for extremely fast access and fact manipulation at runtime. So, in your
example, there would be an AgeReadAccessor to do this:
TypeDeclaration.execute("getAge"). TypeDeclaration should only interact with
the compiler, not the actual facts.
Regarding refactoring TypeDeclaration into an interface with multiple
implementations, I think it may be a good idea. We do it all the time: make
work, generalize and refactor. :) We just need to make sure the whole
picture is addressed since the type declaration itself is just the tip of
the iceberg.
Regarding your question on compilation, all semantic code blocks are
compiled: for java dialect, we generate java code and compile at compile
time, for mvel dialect, it boots up in interpreted mode and JIT code as it
is needed (like java hotspot).
The comments above represent the current design. We can changed as we see
fit. My intention is just to get you up to speed on the current design. :)
Cheers,
Edson
2008/8/28 Stephen Kestle <stephen.kestle(a)orionhealth.com>
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
6:39 p.m.
Edson Tirelli wrote:
Except that it is tied in particular to FactTemplate and classes. It
should expose the required metadata completely.
Ok - so there's sneaky
compilation going on everywhere. So reflection
is not used at all (at least at runtime).
Also, There is not FactTemplateWriteAccessor, so we cannot set fields,
except by using Fact.setFieldValue(). If there was a write accessor
(and a FactField implementation and plugging for FactTemplate) then it
would be complete?
I'm starting to get my head around the classes and structure, but I'm
still struggling to see what's wrong with FactTemplate. It seems
relatively valid. Why couldn't it be finished?
Also, is there any way of actually using TypeDeclarations outside of a
package script or javabean? e.g. there's no simple way of getting
existing objects into a template without writing a bit of reflection...
Thanks
co-operation.
7:47 p.m.
I'm starting to get my head around the classes and structure, but
I'm
still struggling to see what's wrong with FactTemplate. It seems
relatively
valid. Why couldn't it be finished?
Maybe I was not clear on that. FactTemplate is not bad. It is just not
finished. We have it because we both wanted something equivalent to what
clips/jess have and as a proof that the system can be extended to support
multiple format types. Since we could not mantain it, we never promoted it
to a official feature. There are limitations of course, but nothing that
could not be worked out given resources and time.
Finally, please note that at the same time that we proved it is possible to
have multiple underlying formats, it is not completely plug&play. Since the
implementation is not finished, there is quite a lot of stuff to do yet in
the internals. We will of course suport anyone that decides to undertake the
task. :)
[]s
Edson
2008/8/28 Stephen Kestle <stephen.kestle(a)orionhealth.com>
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
6049
days inactive
6051
days old
5 comments
2 participants
participants (2)
-
Edson Tirelli -
Stephen Kestle