[
https://issues.apache.org/jira/browse/OPENJPA-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655421#action_12655421
]
Fernando commented on OPENJPA-820:
----------------------------------
There, I got a run where it fails.
If you look at the log file and search for TEAMFANJERSEY, you will see the
first SQL query:
SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE
(t0.TEAMFAN_JDOID IS NULL)
then the second:
SELECT t0.JDOID, t0.JERSEYLEVEL, t0.TEAMFAN_JDOID FROM TEAMFANJERSEY t0 WHERE
(t0.TEAMFAN_JDOID = 8574250)
I can only assume that the first query was run against Slice1 (where
TeamFanJersey is actually located), and the second against Slice2 (which is
empty). Thus the query returns null.. which causes my code to create a
TeamFanJersey (which happens to go into Slice2), which causes all future
executions of the query above to return 2 TeamFanJersey objects.. a failure, so
you'll see a tonne of exceptions through the rest of the log:
...NonUniqueResultException: The query on candidate type "class
com.protrade.fandom.data.entities.TeamFanJersey" with filter "select this from
com.protrade.fandom.data.entities.TeamFanJersey this where this.teamFan = :p0"
was configured to have a unique result, but more than one instance matched the
query.
Let me know what else I can do to help us figure this out! :) :)
> 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
> Attachments: bad-log.txt
>
>
> 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.
