Re: [eclipselink-users] Null @Id again after query execution

[Laird Nelson <ljnelson@xxxxxxxxx>]

Thanks; I actually have the very same scenario set up in an embedded GlassFish test case using embedded GlassFish 3.1.2.2 (my production environment) and cannot reproduce the issue.  I suppose I could keep adding to it until I've effectively rebuilt my system there :-) but I don't have the time to do so.

I went so far as to import the very same entities and source code into my test case.  Still no dice.

At the moment I'm up against a good-sized deadline and have to decide whether time spent on further test case tinkering is better than just hacking the living snot out of the surrounding code.  :-)

I had originally thought this was a @PreUpdate/@PostLoad issue, so I put together a test case that attempted to prove those weren't working.  I couldn't prove that.  So I removed them anyway to make sure.

The id and version attributes are still null; the EclipseLink-weaved _persistence_* fields are still set to what I would expect them to be set to.  It's like weaving has gone horribly wrong, or whatever is responsible for taking the SQL results and mapping them to the entity hierarchy is broken in some way, or perhaps confused by the fact that the SQL coming back contains two indistinguishable columns named "id".  I know that something in raw JDBC would likely break if I attempted that by hand, so I'm not sure how EclipseLink could cope with such a scenario.

All I know for certain is that this happens on the named query I cited earlier, and that I've isolated it down to the results of that named query.  At the time of the test, there have been no inserts, updates or removals.

Even more disturbing is that if I take that entity, root around inside it until I find enough raw materials to reconstitute the primary key (I can do this due to a happy side effect of the design), and then deliberately ask the entity manager (by way of my service layer) to find() by that primary key, then EclipseLink tells me that the object with that primary key has been removed from the database.  (!)  Of course it has not, and I have not interacted with the system in the meantime at all.

All of this worked fine in the EclipseLink version that shipped with GlassFish 3.1.

I truly wish that I could--and usually try to--reproduce this in an isolated test case (you can see others that I've done in my bug reports).  Until I can, I must chalk this up to my fault in some way, despite the fact that it occurs on the first execution of a named query and is the first entity loaded or touched by the system (i.e. the persistence context is empty, nothing has been cached, etc.).  Alas, I think this will probably be one of those issues that I just don't have time to track down.  :-(  It's bad enough at the moment that for this particular use case I'm going to have to rip out JPA entirely since I cannot predict what it's doing.

For anyone with some spare cycles, again, the weaved-at-deployment-time-in-the-standard-Java-EE-fashion EclipseLink entity coming back from the named query has its internal primary key stuff set up properly, but for whatever reason cannot set the id or version.  It is also marked as removed, apparently, as a result of the query's execution.

Best,

Laird

On Fri, Aug 31, 2012 at 7:15 PM, Bernard <bht237@xxxxxxxxx> wrote:

Hi Laird,

One way to narrow this down is to write a junit test case and submit
it as a bug. While playing with the test case, you may find a
workaround that gives you some breathing space before the bug (if it
is one) is fixed, or to find a correct solution. While mirating to the
latest Eclipse version, I found 3 issues with my current software, 2
of them were EL bugs and 1 was my own.

Feel free to examine the test cases in the following issues:

SQL Generation overrides NOT, AND Operator Precedence
https://bugs.eclipse.org/bugs/show_bug.cgi?id=387165
This is interesting because it generates incorrect SQL since 2.4

NamedQuery with null Parameter fails at Runtime with Postgresql
https://bugs.eclipse.org/bugs/show_bug.cgi?id=387545

Simple JPQL with guarded null Parameter fails with Postgresql
https://bugs.eclipse.org/bugs/show_bug.cgi?id=377586
This is now fixed but it has a Maven testcase. I haven't seen EL 2.4
in the maven repository yet.

Otherwise you might find that your issue is already recorded at:

https://bugs.eclipse.org/bugs/query.cgi

Kind Regards,

Bernard

On Fri, 31 Aug 2012 15:42:08 -0700, you wrote:

>I have a (weird) inheritance structure like this:
>
>@Entity(name = "Party")
>@DiscriminatorColumn(name = "kind", discriminatorType =
>DiscriminatorType.STRING, length = 30)
>@DiscriminatorValue("Party")
>@Inheritance(strategy = InheritanceType.JOINED)
>@Table(name = "Party")
>// other stuff
>public abstract class PartyEntity ...
>  @Id
>  @Column(name = "id", updatable = false)
>  Long id;
>
>@MappedSuperclass
>public abstract PersonMappedSuperclass extends PartyEntity...
>  // various basic mappings here; no further @Id annotations
>
>@Entity(name = "Person")
>@DiscriminatorValue("Person")
>@Table(name = "Person")
>public class PersonEntity extends PersonMappedSuperclass...
>  // more mappings; no @Id annotations
>  // one to many with names, etc.
>
>When I retrieve such an object via a particular named query, I can see in
>the debugger that his id property is null.  This never happened in the
>version of EclipseLink that shipped as part of GlassFish 3.1.
>
>This should not be the case, correct?  Have I misunderstood what is and is
>not permitted in an inheritance hierarchy?
>
>My named query in all its glory looks like this--it finds a Person based on
>values for certain names the person has:
>
>SELECT p FROM Person p JOIN p.names n WHERE (n.nameType.code =
>'legalFirstName' OR n.nameType.code = 'legalLastName') AND n.value LIKE
>:text
>
>The resulting SQL from this is (rather suspiciously; note in particular the
>double "id" column retrieval--i.e. "id" is not present only in the WHERE
>clause but in the SELECT clause as well, with no way to distinguish between
>them):
>
>SELECT
>t2.id,
>t2.kind,
>[snip]
>t2.version,
>t3.id,
>[snip; other t3 columns]
>FROM Person t3, Party t2, Name t1, NameType t0
>WHERE
>(
>   (
>      (((t0.code = 'legalFirstName') OR (t0.code = 'legalLastName')) AND
>t1.nameValue LIKE 'Lair%')
>      AND ((t3.id = t2.id) AND (t2.kind = 'Person'))
>   )
>   AND ((t1.owningPartyID = t2.id) AND (t0.id = t1.nameTypeID))
>)
>
>The resulting Person entity has a null id property.
>
>I'm really not sure where to go next with this.
>
>Best,
>Laird

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

--
http://about.me/lairdnelson