Hi Michael, No, this is JPA provider implementation specific. However, OpenJPA requires the given entities must be managed to determine the primary keys for equality comparison, in contrast with Hibernate works with both attached/detached entities. My guess is it depends on how/what info the provider serialize the entities.
-Frank Michael Bouschen-2 wrote: > > Hi Frank, hi Patrick, > > the current version of the spec does support comparing enties directly. > Section 4.12 "Equality and Comparison Semantics" defines: "Two entities > of the same abstract schema type are equal if and only if they have the > same primary key value.". > > Maybe I'm wrong, but I could not find anything in the spec requiring > that an entity passed as a parameter must be managed. According to 4.12 > all you need for comparing entities is the primary key and this should > be available for detached instances. > > Regards Michael > >> Hi, >> >> Yes, they must be managed instances. When using a persistent type in a >> query, you are either doing object equality (in which case we must >> have a managed instance to understand how to handle object identity) >> or you are accessing persistent fields (in which case we must be >> hooked into the object in order to dig into it). >> >> IIRC, this behavior is not defined in the spec -- I think the spec >> does not permit queries that directly compare entities. >> >> -Patrick >> >> On 9/17/07, frankca <[EMAIL PROTECTED]> wrote: >> >>> > >>> > Hi, >>> > >>> > I have simple query with Foo and FooType are persistent classes and >>> name is >>> > string type: >>> > (1) @NamedQuery( >>> > (2) name = "Foo.findByTypeAndName", >>> > (3) query = "SELECT e " + >>> > (4) "FROM Foo e " + >>> > (5) "WHERE e.fooType = :fooType " + >>> > (6) "AND e.name = :name" >>> > (7) ) >>> > >>> > Case 1: if the given fooType is detached then if I create a named >>> query and >>> > invoke getSingleResult() returns null. >>> > Case 2: if I change the named query line (5) as following and the >>> given >>> > fooType is detached then it works: >>> > (5) "WHERE e.fooType.id = :fooTypeId " + >>> > Case 3: if I "attach" the fooType prior to pass it to the query then >>> it >>> > works. >>> > >>> > Q1: Can someone please confirm is it true that any persistent entities >>> pass >>> > as parameters to JPQL queries MUST be attached? >>> > >>> > Q2: What is the best way to "attach" a persistent entity without >>> knowing >>> > it's detached or not? (I invoke EntityManager.contains() and perform >>> > EntityManager.find() is this recommended?) >>> > >>> > TIA, >>> > Frank >>> > >>> > -- >>> > View this message in context: >>> > >>> http://www.nabble.com/Persistent-entities-pass-as-params-to-JPQL-queries-MUST-be-attached--Query.getSingleResult%28%29-bug-or-expected-behavior--tf4471259.html#a12748830 >>> > Sent from the OpenJPA Users mailing list archive at Nabble.com. >>> > >>> > >>> >> >> >> -- Patrick Linskey 202 669 5907 > > -- > [EMAIL PROTECTED] Engineering GmbH Tel.: +49/(0)30/235 520-33 > Buelowstr. 66 Fax.: +49/(0)30/217 520-12 > 10783 Berlin mailto:[EMAIL PROTECTED] > > Geschaeftsfuehrung: Anna-Kristin Proefrock > Sitz Berlin, Amtsgericht Charlottenburg, HRB 564 52 > > > -- View this message in context: http://www.nabble.com/Persistent-entities-pass-as-params-to-JPQL-queries-MUST-be-attached--Query.getSingleResult%28%29-bug-or-expected-behavior--tf4471259.html#a12786401 Sent from the OpenJPA Users mailing list archive at Nabble.com.
