Hi Kris,

The JPAPersisterManager is currently creating a new EntityManagerFactory.

It should probably also take an EntityManagerFactory as an input. This is necessary if you already have an EntityManagerFactory in your application you want to reuse it. Two EntityManagerFactories mean two transactional resources that have to be managed by a distributed transaction and that is unnecessary.

If you want I should be able to provide the patch. It should be a simple constructor change :).

I hope I am not starting to bother you with my issues, I might have a few more :)

Thank you.
Best Regards,
Michal

----- Original Message -----

From: Michal Bali

To: Rules Dev List

Sent: Wednesday, December 03, 2008 10:48 PM

Subject: [rules-dev] drools-process-enterprise - JPAPersisterManager shouldtake EntityManagerFactory as an input parameter

Hi Kris,

The JPAPersisterManager is currently creating a new EntityManagerFactory.

It should probably also take an EntityManagerFactory as an input. This is necessary if you already have an EntityManagerFactory in your application you want to reuse it. Two EntityManagerFactories mean two transactional resources that have to be managed by a distributed transaction and that is unnecessary.

If you want I should be able to provide the patch. It should be a simple constructor change :).

I hope I am not starting to bother you with my issues, I might have a few more :)

Thank you.
Best Regards,
Michal

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

Thank you Kris,
I've submitted the patch:
https://jira.jboss.org/jira/browse/JBRULES-1887
No need to hurry with this.
I haven't tested it. For some reason I can't run my application with locally build drools jars.
Keep up the good work!
Michal

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 <at> Entity, <at> MapperSuperclass, <at> 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. 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.

dave

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 <at> Entity, <at> MapperSuperclass, <at> 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.

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.

dave

On Fri, Dec 5, 2008 at 11:09 PM, Mark Proctor <mproctor <at> codehaus.org> 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
  <at> relation(name="OwnerPetRelation", verb="IsOwnerOf")
  Set<Pet> pets;

Pet
  <at> 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 <at> lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

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