Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JPQL optional identification variable #452

Closed
gavinking opened this issue Aug 11, 2023 · 2 comments · Fixed by #588
Closed

JPQL optional identification variable #452

gavinking opened this issue Aug 11, 2023 · 2 comments · Fixed by #588

Comments

@gavinking
Copy link
Contributor

gavinking commented Aug 11, 2023

I propose that we bless queries like this one:

select title from Book where publicationDate > :date order by title, publicationDate

This is something that SQL lets you do, of course.

Hibernate has tolerated stuff like this for quite a long time, and now supports it robustly. I would be surprised if other providers don't also allow it. (But I don't know if EclipseLink supports it.)

Of course, we would probably want to impose some restrictions on this. It's most useful when there's only one entity in the query, and therefore no risk of field name collision, so the "minimal" functionality would be to allow it only in that case.

This isn't a super-high priority, but it would be a good way to improve portability of queries between providers.

@gavinking
Copy link
Contributor Author

As a result of activity in Jakarta Data, this is now a much higher priority than I previously rated it.

@lukasj let's chat about this one soon.

gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
this is a minimal change to support the subset in Jakarta Data
i.e. it is only allowed when there is just one thing in the
FROM clause

see jakartaee#452
gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
this is a minimal change to support the subset in Jakarta Data
i.e. it is only allowed when there is just one thing in the
FROM clause

see jakartaee#452
gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
this is a minimal change to support the subset in Jakarta Data
i.e. it is only allowed when there is just one thing in the
FROM clause

see jakartaee#452
gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
gavinking added a commit to gavinking/jpa-api that referenced this issue Mar 11, 2024
@gavinking
Copy link
Contributor Author

gavinking commented Mar 11, 2024

Summary of current proposal:

  1. When there is a FROM element and no JOINs, the identification variable is optional and defaults to this.
  2. The SELECT clause becomes optional, and defaults to SELECT this.
  3. If the first element of a path expression is not an identification variable, it is interpreted as if it began with this..

Thus, the query:

from Book where title like :title

Is equivalent to:

select this from Book as this where this.title like :title

This significantly streamlines the syntax of simple queries, without doing violence to the semantics of JPQL.

lukasj added a commit that referenced this issue Mar 15, 2024
#588)

* make identification variables (and the SELECT) clause optional in JPQL
* introduce 'this', the implicit identification variable

see #452

Co-authored-by: Lukas Jungmann <[email protected]>
rfelcman added a commit to eclipse-ee4j/eclipselink that referenced this issue Apr 11, 2024
…alias in simple SELECT queries (#2102)

This improvement ensure, that JPQL SELECT queries like `SELECT this FROM Entity` where entity alias is not specified in the `FROM` part will be automatically added. Default `this` alias is used as it specified by:
jakartaee/persistence#452
There is automatic `SELECT this` generation for queries like `FROM Entity this` too.
This happens only for EclipseLink 5.0.0 and higher or for persistence property `eclipselink.jpql.validation` with value `None` or `JPA 3.2`.

It allows accept following queries like:

- `SELECT this FROM Entity` -> `SELECT this FROM Entity this`
- `SELECT COUNT(this) FROM Entity` -> `SELECT COUNT(this) FROM Entity this`
- `SELECT this FROM Entity this WHERE id = :id` -> `SELECT this FROM Entity this WHERE this.id = :id`
- `SELECT this FROM Entity WHERE id = :id AND UPPER(name) = 'NAME 1` -> `SELECT this FROM Entity this WHERE this.id = :id AND UPPER(this.name) = 'NAME 1'`
- `FROM Entity this` -> `SELECT this FROM Entity this`

Some test modifications in the `org.eclipse.persistence.jpa.testapps` module:

- `org.eclipse.persistence.testing.tests.jpa.jpql.advanced.JUnitJPQLComplexTest#testNoSelect`
- `org.eclipse.persistence.testing.tests.jpa.jpql.advanced.JUnitJPQLValidationTest#noAliasWithWHEREAndParameterExceptionTest`
- org.eclipse.persistence.testing.tests.jpql.JPQLExceptionTest#noAliasWithWHEREAndParameterExceptionTest (CORE)

Signed-off-by: Radek Felcman <[email protected]>
@lukasj lukasj removed the candidate-for-4 Good candidate for JPA 4 label Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants