<¹>ÒyÄïÌW½
¬Î!#A;ÛQrZ6ïúËcþÄú㣠\á-äóë¡ï\
Ýu&&sV©ÙÓ\µàz®}ÐÛ`
¦ÈbX¡pTAkÒJÉñ:,yþè¦qq){°Ý3X%;]:d¾õ!tþlÈõvõC-pÚ§õJÅ!&XÛ;m;uË-_*>õñ
íiOr1Û0ȶh6¹UÖ¥TJØw)êÏ_1§[C2b
ùŵgÁ5s,ÇWy¬SR¶´{¬rl6ÀÌK½'C9AÒìºÀ¿rjP¤QË^Z;ãÚ¿ö¨ÇÂMƬïå´«¨H5¬Mì¨ÆàÔÔÏ
%, GiïQ
ÏÖÔ)HéÔ3zl1Àöå-öáq´3v£ö-¢
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 cr
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 function
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
t
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 jus
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 th
