David Sinclair wrote:
I actually have something similar. All of our classes are JPA entities. So I get a hold of the JAR that contains all the class definitions and generate traversal rules to spider out the object model. I look for @Entity, @MapperSuperclass, @Emeddeable, etc. This handles 1-1, 1-many, many-1, and many-many.

To asset 1 object and see it follow all the relationships is pretty wild! The only problem is, you sometimes don't want to have all the relationships followed, or else you could end up with half the DB in memory.
The rule verification has code to tell you what classes and what fields are used in rules. This can be used to help you determine when relationships actually need to be added.
To solve this, I have TraversalPolicy facts that define when a relationship should be followed. There are default policies that go to a depth of 3 in every direction. Then you can define rules in Guvnor to allow for more fine grained traversal under certain circumstances.
This sounds like some interesting code, if we could add it with the above idea to minimise what is actually inserted. Fancy on working on this for an optional module for drools for better JPA integration?

Mark

dave

On Fri, Dec 5, 2008 at 11:09 PM, Mark Proctor <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    I thought of a simple, yet powerful idea, anyone want to give this
    ago? It will be the start of making ontologies more sanily usable
    for java developers.

    Person
     @relation(name="OwnerPetRelation", verb="IsOwnerOf")
      Set<Pet> pets;

    Pet
     @relation(name="OwnerPetRelation", verb="IsOwnedByf")
      Person owner;


    IsOwnerOf and IsOwnedBy do not live on the classpath. The engine
    detects those annotations and generates them as internal classes.
    Or actually it can be one class, where it's able to use the two
    keywords to reference that class in either direction. When you
    insert your Persons and Pets, the relations are automatically
    inserted too (assuming there are rules that use them). This allows
    people to more naturally explore the relational aspect of their
    data, without having to create and insert the relations
    themselves. Once a Relation is being maintained by the engine, any
    updates to the underlying collection will result in relations
    being added and removed.

    If we build in relation inferrence, to avoid the extra binding, it
    would mean that by simply annotating their classes people can do
    the following (Assuming Cat is a type of Pet):

    When
      Person( location == London ) IsOwnerOf() Cat( color == "Tabby")
      ....

    The above will get all my london people and their tabby cats. The
    simply placement of the IsOwnerOf() pattern, would be nice if ()
    was optioal, would constrain the Cat to those related to the
    Owner. i.e. the short hand equivalent of:
    $p : Person( location == London ) IsOwnerOf( owner == $p, $c : Cat
    ) Cat( this == $c, color == "Tabby")

    I think that's powerful and provides for a hyrbid OO and
    Relational modelling approaches,  asthey can still use graph notation:
    person.pets[0].color == "tabby"

    This also solves the question that people always ask, how do I
    insert my collection. With that in place there would still be
    plenty more to do, like constraints, but it would be a start to
    improving Drools' relationahip programming "out of the box"
    capabilities. So who's game?

    Mark



    _______________________________________________
    rules-dev mailing list
    rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    https://lists.jboss.org/mailman/listinfo/rules-dev


------------------------------------------------------------------------

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Reply via email to