The main issue here is whether you need to "hot-swap" the class definition or
not.
In the best scenario, you have two independent sub-applications: one is
managing the
fact type, the other is using it, and the two never run together.
In this case, you could just declare your datatype in a separate DRL file,
created programmatically.
The syntax is trivial enough:
package myPackage;
declare YourClass
field1 : type1
...
fieldN : typeN
end
Then, you can upload/update the resource in Guvnor: the next time your
package is compiled,
you will see the latest version of the fact type.
(sorry, but I dont' remember DroolsGuvnor 5.0 APIs, so this is all I can
tell you)
-----------
IF, instead, you have to modify the class AS YOU ARE using it, e.g.:
when Person( name == "x" ) then /* add field gender to Person */ end
then let me know, but the drawbacks might be more than the benefits.
Instances of the "old" version
will not be compatible with instances of the "new" one... Rules will likely
be updated as well, so they
would no longer work with the "old" facts. You'd have to manage the
migration manually.
You might as well opt for a completely dynamic data model? Uglier and you
lose strict typing, I know...
declare Person
attributes : Map
end
you'd have to change the way you write your rules, and I'm not sure that 5.0
already supported this:
Person( name == "x" ) ----> Person( attributes["name"] ==
"x" )
Consider also that 5.0 is a quite old version, many features related to this
functionality have been corrected and added in later versions
----
Btw, what's exactly the point in adding a field? Are you also adding rules
using that additional field?
Could you please provide more details on your app and requirements?
Thanks
D
--
View this message in context:
http://drools.46999.n3.nabble.com/Dynamic-Fact-field-Generation-in-Declar...
Sent from the Drools: User forum mailing list archive at
Nabble.com.