When I - approximately ;-) - calculate how many possible subsets there
are with a field set of about 350 fields my head begins to swim. When
I think of all the tests you'll need to check that you do get the
fields you need for a certain rule set (assuming you can indeed
determine which ones are required) my head begins to reel...
I don't know how expensive the extraction of those 300-odd fields is,
in your application domain. But in scenarios like this, it frequently
turns out that doing O(100) isn't much costlier than O(10) or even
O(1), because the overhead for doing a transfer with minimum data
drowns out the cost of a transfer with a lot of additional payload.
(Depending on the way data is represented on the line between your app
and Drools, chances are, you won't save much there.)
-W
On 07/01/2014, milen igrachev <igrachev(a)abv.bg> wrote:
Well the problem with the fields of the fact objects is just the same
as the
one with the fact types.
Let me try to explain.
The business objects representing the business abstractions in my project
are overlaping with the Fact model.
I believe that this is the standard case :). Actually we can ignore the
technical particularity that we have a Java fact model and another business
application model, because the two model will be mirrored. We can think that
for each business class there is a fact class for Drools to use :). The
business classes are complex and consist of many fields. For example the
biggest contains ovet 450 fields. The most common ones to be used as facts
consists of 373 and 314 fields. If I identify just the Fact Types then I
will need to extract all the information that is available for that fact
before pass it to Drools, then Instantiate a Java instance to represent the
Fact and initialize the instance with the information. What I am trying to
avoid here is the transfer of that many useless information once again. In
the most common case I will need 1 to 10 fields per Fact Type. So passing
the 300 seems redundant.
Best Regards, Milen
-------- Original Letter --------
From: Wolfgang Laun wolfgang.laun(a)gmail.com
About: Re: [rules-users] Is rule introspection available from the Drools
API?
To: Rules Users List
Sent at: Tuesday, 2014, January7 15:04:21 EET
As you describe it, the fields of the fact objects shouldn't matter.
On 07/01/2014, milen igrachev igrachev(a)abv.bg > wrote:
> Hello, initially i didn't give more details to keep my question short
> and
> save time to the ppl that read it. I actually believed that such
> functionality might be covered and available and details would have just
> prolong my question.
> Here is some additional information on why I am looking for such
> functionality. In my project I want to use Drools as external rule
> engine.
> My project is not written in Java and the effort to transfer it is
> inconsiderable.
I guess you mean "considerable".
> What I want to start using Drools for is a simple blackbox
> of getting answers from a Stateless Drools Session, most likely without
> any
> need of reinference. Simply ask and get answered. During the runtime of
> my
> project there is a vast amount of information that can be considered as a
> fact . However in most of the cases what I need is to invoke a simple
> ruleset that actually need like 1% of the facts that I currently know
> at
> any particular moment. So what I want to do is ask Drools "Hey I want to
> invoke ruleset, can you please tell me what are the facts that it is
> using so I can pass all of them, that I currently have?". Then after
> receiving the answer I will filter the 1% from the big picture and will
> finally ask Drools to answer my question.
If these "rule sets" are unrelated with each other, you might put them into
separater DRL files. Then the import list will tell you which facts this
rule set needs, and so all you need is simple text processing...
-W
> What I want to avoid is passing hundreds of instance/facts with
> hundreds
> of fields that are actually never user. Of course I realise that the
> rule
> introspection that I am asking for is not my only option, I can create
> the
> .drl metadata during the ruleset definition. Some more ideas poped into
> my
> head, so far, but the best solution for me seems to be if we can just
> call
> Drools about that information and it return it as a straight answer.
>
> That is why I am trying to identify if it is possible to recive the rule
> metadata from Drools. At first I thought it could be available in a snap
> of
> a finger with some method calls, however now I am interested to see what
> is
> the effort to make it happen.
> Hope it helps. Thanks for the support.
> Best Regards, Milen
>
>
>
>
>
>
> -------- Original Letter --------
>
> From: Stephen Masters stephen.masters(a)me.com
>
> About: Re: [rules-users] Is rule introspection available from the
> Drools API?
>
> To: Drools List
>
> Sent at: Tuesday, 2014, January 7 12:08:39 EET
>
>
>
>
>
>
> It may also be worth explaining exactly what you aim to achieve
> through
> this and why. From what I have seen, most people who ask about
> introspecting
> the LHS of rules via the API, don’t actually need to do that.
>
>
>
>
>
>
> Steve
>
>
>
>
>
>
>
>
>
> On 7 Jan 2014, at 08:56, Wolfgang Laun <
> wolfgang.laun(a)gmail.com > wrote:
>
>
>
>
> Hi,
>
>
>
> while you continue this line of research you might consider possible
>
> ramifications and snags, and be prepared for them.
>
>
>
> The syntax for writing LHS conditions is quite complex - it's more
>
> complex than Java expressions, because the CE eval() alone will give
>
> you (almost) all of that. Rule authors may also use DRL functions,
>
> which could hide field access.
>
>
>
> If *you* author the rules, you may be able to avoid the worst, but it
>
> won't be a piece of cake.
>
>
>
> Cheers
>
> -W
>
>
>
>
>
>
>
> On 07/01/2014, milen igrachev <
> igrachev(a)abv.bg > wrote:
>
>
>
> Hello thanks for the quick and precise answer!
>
>
> I believe that the time difference will be a bit of a problem for the IRC
>
> chat , but i will be online (channel: #drools user: igrachev) today and
> will
>
> try to check it often.
> However big thanks for the support and the
>
> willingness to help!
>
>
> You are saying that the code is there, but is not public and documented.
>
> Well being not public seems to be a problem, but do you
> think it is
>
> possible to give me an example with the official Drools "first rule" -
>
> Sample.drl. The one that comes with the first Drools project.
> So do you
>
> believe it will be possible to paste me some code on how to retrieve the
>
> information that this ruleset is using one fact of type Message
> and two of
>
> it's attributes -
> status
> and
> message.
> So just some code in a public
>
> static void main (String [] args) will be great :), or any kind of
>
> explanation :).
>
>
> Once again thank you.
>
>
> Have a nice day,
>
> Milen
>
>
>
>
>
>
>
> ----Original Letter----
>
> From: Mark Proctor
> mproctor(a)codehaus.org
>
>
>
> About: Re: [rules-users] Is rule introspection available from the Drools
>
>
> API?
>
>
>
> To: Rules Users List
>
>
>
> Sent at: Monday, 2014, January 6 16:05:33 EET
>
>
>
>
>
> The code is there, but it’s not public and not documented, and the code
> can
>
> be a little hard to understand - as it’s grown organically over the
> years.
>
>
>
>
>
>
>
> You’ll need to cast and unwrap and look at member vars. Start on the Rule
>
> and the lhs variable. You can always pop onto irc, with live
> questions,and
>
> we’ll try and respond quickly.
>
>
>
>
>
http://www.jboss.org/drools/irc
>
>
>
>
>
>
>
> Mark
>
>
>
>
>
>
>
> On 6 Jan 2014, at 09:51, milen igrachev
>
> igrachev(a)abv.bg
>
> > wrote:
>
>
>
>
>
>
>
>
>
> Hello,
>
>
>
>
>
>
> is there a way to introspect a Drools file from within java code?
>
>
>
>
>
>
> What I need is to be able to identify the facts and the fact
> attributes
>
> that are used in a given DRL file.
>
>
>
>
>
>
>
>
>
>
>
>
> For example if I have a rule stored in a customer.drl DRL file
> within
> my
>
> project, containing the following definition:
>
>
>
>
>
>
> package myRulePackage
>
>
>
>
>
>
>
>
>
>
>
>
> import org.rules.model.Customer
>
>
>
>
>
>
> import org.rules.model.Mambership
>
>
>
>
>
>
>
>
>
>
>
>
> rule "is eligible customer"
>
>
>
>
>
>
> when
>
>
>
>
>
>
>
> $c:Customer(status == "active")
>
>
>
>
>
>
>
> Membership(customer == $c, type == "premium")
>
>
>
>
>
>
> then
>
>
>
>
>
>
>
> $c.setEligibilityStatus(true);
>
>
>
>
>
>
> end
>
>
>
>
>
>
>
>
>
>
>
>
> What i need is a way to understand that this ruleset customer.drl
> is
> using
>
> two fact types - Customer and Membership and three of their attributes -
>
> Customer.status, Membership.customer and Membership.type.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I found some information on the internet that such functionality
> is
> not
>
> supported, however the information was a bit too old, so I decided to ask
>
> again.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Big thanks for the support!
>
>
>
>
>
>
> Milen
>
>
>
>
>
>
> _______________________________________________
>
>
>
>
>
>
> rules-users mailing list
>
>
>
>
>
>
> rules-users(a)lists.jboss.org
>
>
>
>
>
>
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
>
> rules-users mailing list
>
>
>
>
> rules-users(a)lists.jboss.org
>
>
>
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>
>
>
> _______________________________________________
>
> rules-users mailing list
>
>
> rules-users(a)lists.jboss.org
>
>
https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
>
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users