I think most of those were answered above, but to be sure:
On Fri, May 5, 2017 at 1:29 AM, Steve Ebersole <steve_at_hibernate.org> wrote:
> Not to mention you'd have to expose other things like JDBC params to have
>> this doable.
>>
> True
> And what about multi-valued parameters? Would the SQL already be
>> expanded to account for them?
>>
>
Yes, with positional parameters for each value in the multi-valued
parameter.
> If so, now this #getSqlString becomes time-dependent in terms of when it
>> can be called.
>>
> True, it's a low level representation (transformation) of the JPA query
from which it is derived, including its parameters. It should by default
only be used in the context of that query and that set of parameters (since
those have been used to generate that SQL).
For the count example this is exactly what we need anyway.
As with all native queries, usage is subject to the limitation that the
persistence provider will not manage things for you. The SQL is given as
is. Intended for that JPA query/parameters and the current database target.
Should the user want to re-use the generated SQL it's solely the
responsibility of the user. JPA would not give any guarantees here.
Kind regards,
Arjan Tijms
> Etc... Just a lot of questions. Which is why I said I would not expose
>> it.
>>
>
>
>> On Thu, May 4, 2017, 5:58 PM arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>
>>> Hi,
>>>
>>> On Fri, May 5, 2017 at 12:53 AM, Steve Ebersole <steve_at_hibernate.org>
>>> wrote:
>>>
>>>> Can definitely see the usefulness of this.
>>>>
>>> Thanks
>>>
>>>
>>>> Whether it happens in this MR is a different question.
>>>>
>>>> I'd personally avoid exposing the SQL.
>>>>
>>> Sometimes it's a necessity for things that JPA just can't do. For
>>> instance, JPA can't universally do a count over any random query, but in
>>> SQL this is trivial (for most databases, that is).
>>>
>>> For a longer explanation see: http://arjan-tijms.omnifaces.org/2012/06/
>>> counting-rows-returned-from-jpa-query.html
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>> I'd also suggest adding a note that getting the JPQL from a Query and
>>>> especially from a criteria query is a potentially expensive operation, for
>>>> those considering using it in a toString e.g.
>>>>
>>>> On Thu, May 4, 2017, 5:27 PM arjan tijms <arjan.tijms_at_gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> See https://java.net/jira/browse/JPA_SPEC-25
>>>>>
>>>>> This would be an incredible useful feature to have and largely would
>>>>> "just" be exposing methods that all persistence providers already seem to
>>>>> have internally.
>>>>>
>>>>> Linda herself said:
>>>>>
>>>>> "*Being able to map back and forth between CriteriaQueries and JPQL
>>>>> queries would be useful to have. This is something that should be
>>>>> considered in a future release. See also
>>>>> http://java.net/jira/browse/JPA_SPEC-29
>>>>> <http://java.net/jira/browse/JPA_SPEC-29>*"
>>>>>
>>>>> Wonder if this could be considered for the MR.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>