[
https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655405#action_12655405
]
Fernando commented on OPENJPA-820:
----------------------------------
I'll try posting the "relevant portion of the failing use case", but I just
did. There is a simple query, and it's failing, I already told you the query
above, and pointed out the generated SQL that openjpa is executing against the
slices.. and I have no clue how that would come about..
but here are more details.
I have two slices. One is the full database that I have been using for
non-slice work. The second is a fully empty database with just the same
schema, that I use for slices testing. So TeamFan and TeamFanJersey objects
all exist in the same database.
In my code I am trying to do something like:
attainTeamFanJersey( TeamFan fan );
which then calls the query listed below, to see if there is a TeamFanJersey for
that TeamFan. If null, then it creates one.
select this from com.protrade.fandom.data.entities.TeamFanJersey this where
this.teamFan = :p0
What I expect is that it will always return a value since I KNOW that a TeamFan
and TeamFanJersey both exist in Slice1.
For some reason OpenJPA returns null randomly, thus for some reason OpenJPA
can't find a valid TeamFanJersey, even though I know it exists. When I was
looking at the logs, that's when I saw the weird case that it seemed to be
checking for NULL instead of the propery TeamFan id for one of the two slices..
weird.
When this happens, then my code assume that there is no TeamFanJersey, then it
creates one. But now there are 2 TeamFanJersey objects related to that TeamFan.
Now the kicker. When the code creates a second TeamFanJersey, it properly
creates that object. And at times it creates that on Slice2. But then when I
execute the query again, at a later time ( same request, or another request ).
select this from com.protrade.fandom.data.entities.TeamFanJersey this where
this.teamFan = :p0
It then finds BOTH TeamFanJersey objects.. which my code complains since it's
expecting only 1 TeamFanJersey, not 2.. (getSingleResult).
So, here we are:
The query works most of the time, but seems to fail randomly.
The failure seems to be related to the low level SQL that it generates and runs
against each Slice, in that it doesn't generate the same SQL.. weird.
> slices: a simple query is failing (unique, but totally sending wrong
> parameters to SQL)
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-820
> URL: https://issues.apache.org/jira/browse/OPENJPA-820
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0
> Reporter: Fernando
> Priority: Critical
>
> Thank you for fixing that PCPath issue! Now I can move on to find the next
> bug to fix. :) And I didn't have to wait long:
> I am trying to run the simple query below, against 2 slices.
> select this from com.protrade.fandom.data.entities.TeamFanJersey this where
> this.teamFan = :p0
> These are the two queries run on the low level databases:
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE
> (t0.TEAMFAN_JDOID IS NULL)
> SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE
> (t0.TEAMFAN_JDOID = 8574250)
> As you can see, the query run against Slice1 thinks the parameter is Null,
> while the query run against Slice2, knows the proper value of the parameter.
> This SQL is the lowlevel sql sent through the Mysql Driver (mysql driver
> logging).
> I guess it's another bug in the DistributedPreparedStatement not properly
> setting parameters to all sub statements.. just a guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
