I thought it would be good to have an API that will call any registered
queries upon connecting to the database, and maybe ones before returning it
to the connection pool.
I'm thinking it should be called in the implementations of ConnectionProvider
and MultiTenantConnectionProvider.
The basic pur
I've started getting these every month from this list:
> Your membership in the mailing list hibernate-dev has been disabled
> due to excessive bounces The last bounce received from you was dated
> 24-Oct-2018. You will not get any more messages from this list until
> you re-enable your membership
I was thinking to propose this part of the release process gets changed a
bit, so that the commit of a "Final" version never goes into "master", but
remains on a tag.
Something like this:
# detach head
git checkout
# edit file and change hibernateVersion
editor gradle/base-information.gradle
# com
On 02/18/2018 11:38 AM, Steve Ebersole wrote:
> > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov wrote:
> >
> >> I think transitioning to automatic bindings via JAXB will result in
> error
> >> messages on wrong configurations becoming far too vague to be useful to
>
orward (we are transitioning to JAXB).
>
> All that said though, I am surprised you ran into so few problems. Envers
> e.g. makes extensive use of DOM4J.
>
> On Fri, Feb 16, 2018 at 4:29 PM Jordan Gigov wrote:
>
>> The woodstox dependency is incompatible with the rest of the XML
e it or find a good replacement.
>
> I'd suggest to work on the master branch though, we wouldn't want to
> apply this on the 5.2 branch which is now in maintenance mode.
>
> What do you mean with "shiv-libraries" ?
>
> Thanks,
> Sanne
>
>
> On 16 Fe
So, the library has not seen a bugfix in over 10 years, and it lists the
wrong version for it's xml-apis dependency.
There are some notes in comments about eventually removing it, and I
thought I'd give it a try on the 5.2 branch.
I had to remove two shiv-libraries you had added to work around prob
I don't know how applicable this is to the Hibernate project, but a
workflow I've seen is you do the fixes in the old maintenance-only branches
(say 5.1) and then merge or cherry-pick those changes into the
current-release branch. Of course if they've diverged too drastically in
very few commits, t
If they want Json support for JSR-353 types, one is already published.
https://mvnrepository.com/artifact/com.mopano/hibernate-json-contributor
If they want it for a non-standard API, they are free to use it's source as
a base. License permits it.
They will need 5.2.10 if they need to bind a JsonA
Would this allow for queries of multiple keys, like this?
SELECT * FROM tbl WHERE (key1, key2) IN ( (val1k1,val1k2), (val2k1,val2k2)... )
I started working on trying to fit something like this in 5.2 and see
what problems I would encounter, but haven't had time to finish it.
On 16 June 2017 at 1
If I remember correctly there are two other types that are missing a
set by name function in the standard API.
Also if the type contributor I proposed in PR #1499 is not going to
make it in, should I just close it and release it stand-alone?
I think there might be an optimization or two that I hav
the JDBC driver?
>
>
> Mit freundlichen Grüßen,
>
> *Christian Beikov*
> Am 14.03.2017 um 10:39 schrieb Jordan Gigov:
>> What java.sql.Date does is wrong for many reasons (mostly because it
>> ext
What java.sql.Date does is wrong for many reasons (mostly because it
extends java.util.Date which is a horrible API), but I think Vlad laid
it out pretty well why it's a JDBC driver configuration problem and
not a Hibernate problem. If you simply rely on the Java API to use
handle it's l own TZ con
ther projects to patch.
>
> Sanne
>
> On 23 February 2017 at 11:09, Jordan Gigov wrote:
>> On 23 February 2017 at 12:24, Sanne Grinovero wrote:
>>> I think the setup is not perfect yet, as I've reviewed some failure
>>> reports and they seem caused b
On 23 February 2017 at 12:24, Sanne Grinovero wrote:
> I think the setup is not perfect yet, as I've reviewed some failure
> reports and they seem caused by an already running WildFly instance on
> the same machine. So either we have a bad job configuration somewhere,
> or a WildFly instance which
One thing I think JPA is lacking is the ability to map read-only result classes,
without annotating them as @Entity and making the provider expect
table for them.
ConstructorResult is a pretty hacky way of getting there and loses some of the
benefits like lazy loading collections and in Hibernate's
2016-10-20 21:27 GMT+03:00 Steve Ebersole :
>
>> A type should be able to define classes Interfaces and Abstract
>> classes that it can handle in their Java types.
>> This will enable implementing handlers for things like javax.script.*
>> objects that can have different providers, thus different c
I've been reading the wiki and email archives, and I have some notes
for what needs to be decided before it needs to become retrofitted.
After all, all that retrofitting is what the reason the types need to
be redesigned.
LiteralType.objectToSQLString is only used to append the DiscriminatorValue.
The feature is now ready for review.
JIRA issue HHH-10999, Pull request #1499
It is not 5.1-compatible, because it requires the Session object to be
passed as the WrapperOptions.
One test fails due to bug in core: HHH-11171.
I'm guessing a lot of type descriptors would fail those tests as well.
tional
>> parameters in native queries.
>>
>> I simply mentioned leveraging the new "JPA strict compliance" stuff I am
>> adding to 6.0. The idea is to allow you to enable that and get feedback
>> when you use non-portable things.
>>
>>
>> On
se.
>
> If not, what do yo mean by "package buildscripts"?
>
>
>
> On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov wrote:
>
>> Well, the CI would generally have a local snapshot to use, instead of
>> downloading it.
>> The problem is that the package build
Well, the CI would generally have a local snapshot to use, instead of
downloading it.
The problem is that the package buildscripts depend on
'hibernate-gradle-plugin',but it depends on 'hibernate-core'.
I just cleared my ~/.gradle/caches and ~/.m2/repository/org/hibernate/,
switched to the '5.1' b
Actually JPA defines it as "Only positional parameter binding and
positional access to result items may be portably used for native queries".
I believe "portably" means the providers are only required to support
positional, but not forbidden from supporting other.
2016-09-21 3:59 GMT+03:00 Steve E
While this topic is hot and the type handlers will not be
backwards-compatible, I think they should have some access to the
connection-specific Dialect. I have started (but largely paused) an
implementation of Array datatypes, but it's highly dependent on instance
type-checking of WrapperOptions ug
24 matches
Mail list logo
