Its not so much hindering 6.0 that I am concerned with. The problem is
updatability for the user. The more things they use that change = the more
work to upgrade.
On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
I suppose this will be refactored considerably in 6.x.
However, it's just a small change and I don't think it will hinder any 6.x
changes.
I'm thinking of defining an SqlFunctionContributor interface
(@FunctionalInterface)
which can be provided via the properties Map that's supplied when using
the Persistence#createEntityManagerFactory method.
In EntityManagerFactoryBuilder, I can just inspect that and pass it
further to MetamodelBuilder.
So, it does not take any effort to implement it and users can benefit from
it. I recently answered a question on the forum on this topic:
https://discourse.hibernate.org/t/i-cant-use-group-concat-in-queries/752/14
And, realized that I was wrong about suggesting doing it via the
Integrator mechanism (since the Metamodel is already frozen by the time we
execute the Integrator).
Vlad
On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole <steve(a)hibernate.org>
wrote:
> This should maybe wait for 6.0. We are ditching SQLFunction in favor of
> a more AST-friendly contract.
>
> Beyond that, go for it.
>
>
> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
> wrote:
>
>> Hi,
>>
>> I realized that only the native Hibernate bootstrapping mechanism allows
>> for passing custom SQL functions.
>>
>> For JPA, we can extend the Dialect to register, but that's not always
>> desirable as it requires a code change
>> every time the user switches to a new Dialect version.
>>
>> For this reason, I created this Jira issue:
>>
>>
https://hibernate.atlassian.net/browse/HHH-12589
>>
>> Let me know if anyone has anything against implementing this feature.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>