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

JPA 2.1 capabilities #658

Closed
ldez opened this issue Feb 9, 2014 · 11 comments · Fixed by #2530
Closed

JPA 2.1 capabilities #658

ldez opened this issue Feb 9, 2014 · 11 comments · Fixed by #2530
Milestone

Comments

@ldez
Copy link

ldez commented Feb 9, 2014

Add support for Hibernate 4.3.x.
Add also support of new JPA 2.1 capabilities, ex : treat for .as(Class) when entities are joined.

@timowest
Copy link
Member

Which specific Hibernate 4.3 and JPA 2.1 features would you like to see supported?

@ldez
Copy link
Author

ldez commented Feb 10, 2014

Thank you for your interest.
I speak of Hibernate 4.3.x support but actually it's only JPA 2.1 support that interest me.
Allow me a few days to define more precisely the elements.

At first, support TREAT in the case of inheritance between two entities associated with JOINED.
ex : root.book.as(QManga.class).drawer.eq("foobar")

@timowest
Copy link
Member

@ldez What is the (full) list of JPA 2.1 features that could/should be supported?

@timowest
Copy link
Member

timowest commented Apr 8, 2014

@timowest
Copy link
Member

timowest commented Apr 9, 2014

@ldez I made TREAT support now available in this pull request #705

Could you take a look and maybe review?

@timowest timowest added this to the 3.3.4 milestone Apr 30, 2014
@timowest timowest added the fixed label May 4, 2014
@timowest timowest modified the milestone: 3.3.4 May 10, 2014
@timowest timowest changed the title Hibernate 4.3.x and JPA 2.1 capabilities JPA 2.1 capabilities May 10, 2014
@timowest
Copy link
Member

I updated the title to better reflect what has been done for it.

@timowest
Copy link
Member

Released in 3.3.4

@ldez
Copy link
Author

ldez commented May 22, 2014

Good work, sorry for not replying sooner but I had a lot of work.

@virgo47
Copy link

virgo47 commented Feb 24, 2016

Sorry for asking in the closed issue, but Google search for "Querydsl JPA 2.1 FUNCTION" lead me here. I see that TREAT is in Querydsl, but I don't understand what the status of FUNCTION is, and if it is in, how it should be used (search through Reference did not help).

@virgo47
Copy link

virgo47 commented Feb 24, 2016

Seems I needed to ask (after a long search, mind you :-)), after the question I got it in a minute, as it is not strictly tied to JPA 2.1, but more to Querydsl templates:
http://stackoverflow.com/questions/22984343/how-to-call-mysql-function-using-querydsl

So we should just use Expressions.xxxTemplate depending on the type and write function(real_function) template ourselves.

@Shredder121
Copy link
Member

Yes, that would be right.
Don't forget to also make your functions known to the JPA provider.

jwgmeligmeyling added a commit that referenced this issue Jul 28, 2020
JPA 2.1 introduced the TREAT operator for explicit casting. Initial support for TREAT in the FROM clause was added in PR #705. However, the specification also describes the notion of `treated_subpath` expressions (chapter 4.4.4.1) that are allowed in the WHERE clause of a query.

The syntax is as follows:

> ```
> treated_subpath ::= TREAT(general_subpath AS subtype)
>
> single_valued_path_expression ::= qualified_identification_variable | TREAT(qualified_identification_variable AS subtype) | state_field_path_expression | single_valued_object_path_expression
> ```

And can be used as such:

```SQL
SELECT e FROM Employee e JOIN e.projects p WHERE TREAT(p AS LargeProject).budget > 1000
```

(Example from chapter 4.4.9).

This pull request adds the support for treated subpaths in QueryDSL. It does so by introducing a new `PathType` and convenience method `JPAExpressions.treat`.
jwgmeligmeyling added a commit that referenced this issue Jul 28, 2020
JPA 2.1 introduced the TREAT operator for explicit casting. Initial support for TREAT in the FROM clause was added in PR #705. However, the specification also describes the notion of `treated_subpath` expressions (chapter 4.4.4.1) that are allowed in the WHERE clause of a query.

The syntax is as follows:

> ```
> treated_subpath ::= TREAT(general_subpath AS subtype)
>
> single_valued_path_expression ::= qualified_identification_variable | TREAT(qualified_identification_variable AS subtype) | state_field_path_expression | single_valued_object_path_expression
> ```

And can be used as such:

```SQL
SELECT e FROM Employee e JOIN e.projects p WHERE TREAT(p AS LargeProject).budget > 1000
```

(Example from chapter 4.4.9).

This pull request adds the support for treated subpaths in QueryDSL. It does so by introducing a new `PathType` and convenience method `JPAExpressions.treat`.
jwgmeligmeyling added a commit that referenced this issue Dec 31, 2020
JPA 2.1 introduced the TREAT operator for explicit casting. Initial support for TREAT in the FROM clause was added in PR #705. However, the specification also describes the notion of `treated_subpath` expressions (chapter 4.4.4.1) that are allowed in the WHERE clause of a query.

The syntax is as follows:

> ```
> treated_subpath ::= TREAT(general_subpath AS subtype)
>
> single_valued_path_expression ::= qualified_identification_variable | TREAT(qualified_identification_variable AS subtype) | state_field_path_expression | single_valued_object_path_expression
> ```

And can be used as such:

```SQL
SELECT e FROM Employee e JOIN e.projects p WHERE TREAT(p AS LargeProject).budget > 1000
```

(Example from chapter 4.4.9).

This pull request adds the support for treated subpaths in QueryDSL. It does so by introducing a new `PathType` and convenience method `JPAExpressions.treat`.
jwgmeligmeyling added a commit that referenced this issue Dec 31, 2020
[#658] Support JPQL Treated paths for WHERE clause
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants