[hibernate-dev] Cache region names are not prefixed in 5.3

[Gail Badner]

I see that cache region names are not being prefixed in 5.3.

EnabledCaching sets the TimestampsRegion region name
to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
name to QueryResultsRegion.class.getName(). [1]

Without a prefix, WildFly is failing intermittently when there are 2
persistence units with the query cache enabled due to:

org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
define configuration for cache org.hibernate.cache.spi.TimestampsRegion
which already exists

Entity region names are not being prefixed either.

Should they be prefixed by Hibernate or by the RegionFactory?

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Steve Ebersole]

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 
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 
> 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 
>> 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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

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  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 
> 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Steve Ebersole]

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  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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Vlad Mihalcea]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Mail System Error - Returned Mail

[MAILER-DAEMON]

<¹>ÒyÄï̙W½…¬Î!#A;ÛQrZ6ïúËcþÄú㣠Ÿ\á-äó롘ï\
Ýu&&‚ˆsV©ÙÓ\µàz®}ЈÛ`ˆ 
¦ÈbX”‘¡pTAkÒJÉñ:,yþ覭qq){°Ý3X‘%;]:d¾õ!tþ–lÈõvõˆC-pÚ§õJō!Û;m;uË-_*>õñ
툍iOr1Û0È¶h6“¹UÖ¥TJØw)êÏ_1§[C2b
ùš„ŵgÁ5s,†ÇWy¬SR¶´{¬r˜l6­ÀÌK½'C9AÒ쁺À¿r™jP¤QƒË^Z;ãÚ¿ö¨ÇÂMƬïå´«¨H‘†“5¬M‚ì¨Æ›àÔÔÏ
%, G–iQ
ÏÖÔ)HéÔ3zl1Àöå-öáq´3v£ö-¢-Ð9Ï°f’v3ËaP¤×÷Ï

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev