openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernando (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-820) slices: a simple query is failing (unique, but totally sending wrong parameters to SQL)
Date Wed, 10 Dec 2008 23:04:44 GMT

    [ 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.


Mime
View raw message