[
https://issues.apache.org/jira/browse/OPENJPA-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059191#comment-13059191
]
Milosz Tylenda commented on OPENJPA-487:
----------------------------------------
Switched expressions from JDO style (0-based index, end index provided to
substring)
to JPA style (1-based index, length provided to substring). Same change also
applied
to LOCATE function.
JPQL:
UPDATE CompUser e SET e.name = CONCAT('Ablahum', SUBSTRING(e.name, LOCATE('e',
e.name), 4)) WHERE e.name='Seetha'
Old SQL:
UPDATE CompUser SET name = (?||SUBSTRING(name, ((((POSITION(? IN name) - 1) +
?) - ?) + 1), (? + (((POSITION(? IN name) - 1) + ?) - ?)) - ((((POSITION(? IN
name) - 1) + ?) - ?)))) WHERE userid IN (SELECT DISTINCT t0.userid FROM
CompUser t0 WHERE (t0.name = ?)) [params=(String) Ablahum, (String) e, (int) 1,
(int) 1, (int) 4, (String) e, (int) 1, (int) 1, (String) e, (int) 1, (int) 1,
(String) Seetha]
New SQL:
UPDATE CompUser SET name = (?||SUBSTRING(name, (POSITION(? IN name)), ?)) WHERE
userid IN (SELECT DISTINCT t0.userid FROM CompUser t0 WHERE (t0.name = ?))
[params=(String) Ablahum, (String) e, (int) 4, (String) Seetha]
I also changed the following which I assumed were oversights:
- DB2Dictionary.indexOf: reverted condition for constant checking.
- JPQLExceptionBuilder: implicit type of locateFromIndex changed to Integer
from String.
There are still some problems with PostgreSQL - espressions like 1+1 as
SUBSTRING parameter fail. A possible solution would be to use CASTs heavily,
like we do with DB2.
> Generated SUBSTRING SQL is ugly and inefficient
> -----------------------------------------------
>
> Key: OPENJPA-487
> URL: https://issues.apache.org/jira/browse/OPENJPA-487
> Project: OpenJPA
> Issue Type: Improvement
> Components: sql
> Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0, 1.0.1, 1.0.2, 1.1.0
> Reporter: Patrick Linskey
> Assignee: Milosz Tylenda
> Priority: Minor
>
> When performing a JPQL query with a SUBSTRING clause, OpenJPA converts from
> one-based index + length parameters to zero-based index + end index for
> internal handling, and then re-converts back to one-based + length when
> generating SQL. This conversion is entirely performed in query values, so the
> generated SQL has a lot of math in it. This extra math is never necessary.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
