jpa problems

[tom.baeyens]

in doc/persistence.txt, i added the list of issues that are probably not handled by JPA and that we probably want.

JPA problems
- no support for programmatic creation of configuration and entity manager
- no support to detect persistability and id extraction for variables
- no support for schema generation
- support for interceptors (logging and context injection) ?
- support for proxy-aware equals ?

please, update this list if you have more information or thoughts on the subject.

[mvaldes]

Ok, I will add those items to the next week discussions around JPA. FYI I have organized a "working session" on JPA next tuesday with our JPA specialist.

regards,
Miguel Valdes

[tom.baeyens]

let me know if you need more information about any of those points mentioned above.

that way we're sure that we can give the right input to the jpa specialist and that we get good information back.

[mvaldes]

The only one I diddn't get is "support for proxy-aware equals ?", could you provide me some insights on that ?

regards,
Miguel Valdes

[aguizar]

Hibernate uses the decorator pattern to provide lazy loading for associated individual objects. One consequence of this pattern is that the decorated object does not know about its decorator. When it passes itself as an argument to other methods, it loses its decoration.

The application could end up comparing the object against the decorator - and concluding the objects are different when, in fact, they are equal.

Actually, Hibernate does not support such comparisons. IMO this should not be included in the list of JPA issues.

[tom.baeyens]

'the decorator pattern' means that hibernate uses proxies for lazy loading. The real objects will only be created when they are actually used in the object model.

But... when you pass in a 'this' pointer as an argument for a method invocation, then the real object gets passed instead of the proxy.

So if you later happen to compare the real object with the proxy, then you get false, while you want true.

Hibernate doesn't give you support for this, but it does have a way on how to check if it is a proxy. Based on that, the equals can be implemented correctly.

[mvaldes]

Hi,

After our internal meeting on JPA, Charles has started a simple project in which he is migrating your hibernate sample to JPA-hibernate. This proto is almost finished (in fact it is currently working but is using annotations rather than XML files for entities mapping).

Charles will sent you this proto as soon as possible with a description of differences observed between the hibernate vs the JPA-hibernate implementation.

Hereafter a first set of comments on your questions:

- No support for programmatic creation of configuration and entity manager

Entity Manager object can be created by passing a Map of properties as a parameter. Those properties can be leveraged by each JPA implementation (i.e hibernate)
BTW, there is an xml file in JPA (called persistence.xml) in which we can add the vendor specific attributes for each implementation (i.e so we can copy-paste the hibernate attributes defined in the hibernate configuration file)

- no support to detect persistability and id extraction for variables

Not sure we got this one ??

- no support for schema generation

Possible by leveraging the vendor specific attributes in the persistence.xml file. This means that we must check that each JPA implementation we want to support provides this feature.

- support for interceptors (logging and context injection) ?

JPA provide support for callbacks (following the pre and post invoke approach) for each method of the API (i.e persist)

- support for proxy-aware equals ?

Seems like this feature is only available in some particular version of Hibernate so we should be check if we can do the same with other implementations !

regards,
Miguel Valdes

[csouillard]

Tom, Alejandro,

I am working on the persistence package you gave us to make it based on JPA/hibernate instead of directlt hibernate.
There is something I don't understand :
in my case, I do not have the last sql trace of the first commit :
Hibernate:
/* create one-to-many row org.pvm.Node.outgoingTransitions */ update
TRANSITION
set
SOURCE_=?,
OUTINDEX_=?
where
ID_=?

Can you explain me why this instruction is called (as there is already a link into the Transition created previously) ?
Maybe you can give me some idea to investigate and found the problem (if it is one...)

I have 2 other questions :
- the cache mechanism defined in xml files : is it a hibernate particular feature ?
- I am not sure to completely understand : the list definition in Node :



<list-index column="OUTINDEX_" />
<one-to-many class="org.pvm.Transition" />

As it is a hibernate schema, can you tell me if the concept is only a one-to-many relation ?
It means, in the concept point of view, all the list children are concerning the one-to-many relation to transition ? If yes, we could say we can represent it like the following :
<one-to-many>

<join-column name="OUTINDEX_"/>
<target-class="org.pvm.Transition"/>
<cache.../>
</one-to-many>

Thanks for your help

[aguizar]

Charles,

Hadn't seen your post before. Hibernate executes the update statement you reference because the mapping information does not indicate that the relationship between Node and Transition is bidirectional. This is why it has to maintain both sides of the relationship.

Section 6.3.3 of the Hibernate manual describes how to tell Hibernate that only one side of the relationship has to be maintained.

See the changes I made to the inheritance-mix module in CVS. The update is still executed because the relationship is maintained from the "many" side. With lists there is no option: the list is responsible of establishing the index. Had the collection been a set or a map, the update could have been eliminated.

The changes have effect in the insert statement. Before the change, we had:

/* insert org.pvm.Transition */ insert
 into
 TRANSITION
 (ID_, NAME_, SOURCE_, DESTINATION_, CLASS_)
 values
 (null, ?, ?, ?, 'T')

The SOURCE_ column was set twice: 1) when the transition was inserted and 2) when the list index was set. After the change, we have:

/* insert org.pvm.Transition */ insert
 into
 TRANSITION
 (ID_, NAME_, DESTINATION_, CLASS_)
 values
 (null, ?, ?, 'T')

SOURCE_ is set only once now.

[aguizar]

the cache mechanism defined in xml files : is it a hibernate particular feature ?

Yes. I reviewed the JPA spec and it does not cover a second level cache mechanism. It was left off as a provider-specific feature, although most providers offer it. See the blog entry Understanding the cache of TopLink Essentials(GlassFish JPA) for an example.

I am not sure to completely understand : the list definition in Node. As it is a hibernate schema, can you tell me if the concept is only a one-to-many relation ?
It means, in the concept point of view, all the list children are concerning the one-to-many relation to transition ?

Yes, the concept is a one-to-many association. In order to make the association traversable from the one side, you need a collection. In Hibernate the <one-to-many> element can only appear inside a collection mapping.

The corresponding JPA mapping is something like:

<one-to-many name="outgoingTransitions" mapped-by="source">
 <cascade>
 <cascade-all/>
 </cascade>
 </one-to-many>