11:25 a.m.
The functions could be contributed via a CDI/Spring bean which might not
be such a bad idea I think. In a test environment there could be a
different contributor active than in production. Of course, this could
also be handled by passing in different configuration property values,
but that's why I was saying I'm not sure about it. Maybe someone else
has an idea if using ManagedBeanRegistry might make sense?
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea:
Hi,
Looking at the SessionFactoryImpl class, the only way to provide an
SqlFunction is either via the Dialect or via the SessionFactoryOptions:
this.sqlFunctionRegistry =new SQLFunctionRegistry(
jdbcServices.getJdbcEnvironment().getDialect(), options.getCustomSqlFunctionMap() );
I'm not sure if the ManagedBeanRegistry would have helped in this case
without requiring more code changes.
Vlad
On Thu, May 17, 2018 at 5:22 PM, Christian Beikov
<christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote:
It looks ok to me although I'm not sure if it wouldn't be more
appropriate to instantiate the contributor via ManagedBeanRegistry.
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea:
> In the end, I thought of a more generic approach to for JPA
bootstrapping
> which, not only allows us to register SqlFunctions, but we can
apply other
> changes on the MetadataBuilder object used during bootstrap.
>
> This is the Pull Request:
>
> https://github.com/hibernate/hibernate-orm/pull/2288
<https://github.com/hibernate/hibernate-orm/pull/2288>
>
> Let me know what you think.
>
> Vlad
>
> On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>
>> 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 <mailto:mihalcea.vlad@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-
<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 <mailto:steve@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 <mailto:mihalcea.vlad@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
<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
<mailto:hibernate-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
<https://lists.jboss.org/mailman/listinfo/hibernate-dev>