[hibernate-dev] Post-connect queries for 6.1?

[Jordan Gigov]

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 purpose would be so you can set certain parameters. For example
in setting the timezone in PostgreSQL:

SET SESSION TIME ZONE 'UTC';

Or in MySQL:

SET SESSION time_zone = 'Europe/Berlin';

This would of course require dialect handling, and access to some of the
configuration settings given to the SessionFactory.
There should also be a way for users to customize these with a
per-persistence-unit configuration of some sort. They might want to pass
other such runtime tweaks.
Someone may want to send something like this to their MySQL:

SET SESSION sql_mode = 'TRADITIONAL,ANSI';

I realize it's too late to think about this for 6.0, but it's something to
consider for later on.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Getting automatically removed from the list for "excessive bounces"?

[Jordan Gigov]

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.  You will receive 3 more reminders like
> this before your membership in the list is deleted.

Otherwise messages from the list come in normally in my inbox and not
marked as spam.

Does this only affect me, all GMail subscribers, or an even wider audience?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Starting 5.2.16 release

[Jordan Gigov]

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
# commit while in detached state
git add . && git commit
# add tag to current untracked HEAD
git tag 5.whatever
# push the tag
git push origin refs/tags/5.whatever


This way the release versions do not pollute the branches, but grow besides
them, and you don't need to issue "do not push" warnings.

On 22 March 2018 at 13:03, andrea boriero  wrote:

> *Please do not push anything to 5.2 branch.Thanks,Andrea*
> ___
> 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] Removing dom4j?

[Jordan Gigov]

Well, it took longer than expected as the source of the failures became
more obscure, but here it is, done on the master (5.3) branch.

https://github.com/coladict/hibernate-orm/tree/dom4j-removal
It's in the dom4j-removal branch.

The tests for entity-mode dom4j have been removed, but it might be a better
idea to write new ones that expect an error.
Also the hibernate-mapping-4.0.xsd schema hasn't been valid since dom4j
entity-mode was removed in 2011 (4a4f636caf9ecc62fe0d230f422ad3eab2517db0)
but I haven't touched it.

You could wait for 6.0, but there is time to review this for 5.3.

I have only passed a `clean build` using JDK8 and the default H2 database.
Maybe other databases could expose errors, but it's highly unlikely.
JDK9 is a bit more likely to expose an incompatibility.

On 19 February 2018 at 17:03, Chris Cranford <ch...@hibernate.org> wrote:

> See below
>
> On 02/18/2018 11:38 AM, Steve Ebersole wrote:
> > On Sun, Feb 18, 2018 at 4:52 AM Jordan Gigov <colad...@gmail.com> 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
> the
> >> users.
> >>
> > I'm not understanding... we've used jaxb since 4.0
> >
> > I am just talking about envers and how it integrates with hibernate-core.
> > At the moment it directly uses dom4j - we'd like to eventualy have it use
> > the jaxb model instead
>
> There is a JIRA [1] that specifically targets this work from an Envers
> perspective.
>
> I have a working implementation based on Hibernate 5.x but this is
> planned to be integrated in Hibernate 6.  I'd expect to see this get
> integrated once we get a bit more development finalized around Hibernate
> Core in 6.
>
> [1]: https://hibernate.atlassian.net/browse/HHH-11483
>
> Thanks,
> Chris
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Removing dom4j?

[Jordan Gigov]

I think transitioning to automatic bindings via JAXB will result in error
messages on wrong configurations becoming far too vague to be useful to the
users.
That's just an opinion, though.

I tried building from a clean master branch at home on Windows 10 before
moving the changes, but the multiline tests fail. Time to re-open HHH-8397.

On 17 February 2018 at 17:14, Steve Ebersole <st...@hibernate.org> wrote:

> Would we be interested?  Heck yeah.  We have just not put in the effort
> because it is used for such a small subset of features *and* we plan to not
> use DOM/SAX directly moving forward (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 <colad...@gmail.com> wrote:
>
>> The woodstox dependency is incompatible with the rest of the XML API due
>> to
>> a bug in the JDK that is otherwise hidden in all cases in the default
>> implementation.
>>
>> Specifically it's implementation of EndElement brings that bug to the
>> forefront, when
>> com.sun.org.apache.xalan.internal.xsltc.trax.
>> StAXEvent2SAX.handleElementEnd
>> tries to typecast a Namespace to String.
>>
>> In the default implementation, that Namespace iterator is always empty, so
>> it never reaches that line.
>>
>> Though that does make me wonder why the Document after being read is
>> scanned again as a DOMSource and then converted back to a Document object.
>> Might be a better way to pass it on altogether. Makes me wish I had
>> noticed
>> the deprecation note on org.hibernate.boot.MetadataSources.addDocument(
>> Document)
>>
>> On 16 February 2018 at 23:33, Sanne Grinovero <sa...@hibernate.org>
>> wrote:
>>
>> > Hi Jordan,
>> >
>> > I think it would be great to remove it. Especially recently we've
>> > started exploring what it would take to convert all jars into proper
>> > Jigsaw modules, and a requirement is that all dependencies need to be
>> > converted as well; this is obviously more problematic for such old
>> > libraries so it would be best to remove 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 February 2018 at 21:11, Jordan Gigov <colad...@gmail.com> wrote:
>> > > 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
>> problems
>> > > you probably encountered prior to JDK6.
>> > >
>> > > I've narrowed it down to 11 failing tests (5 distinct exceptions) when
>> > > using the default XML APIs provided with JDK8.
>> > >
>> > > Is there any interest in this?
>> > > ___
>> > > 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Removing dom4j?

[Jordan Gigov]

The woodstox dependency is incompatible with the rest of the XML API due to
a bug in the JDK that is otherwise hidden in all cases in the default
implementation.

Specifically it's implementation of EndElement brings that bug to the
forefront, when
com.sun.org.apache.xalan.internal.xsltc.trax.StAXEvent2SAX.handleElementEnd
tries to typecast a Namespace to String.

In the default implementation, that Namespace iterator is always empty, so
it never reaches that line.

Though that does make me wonder why the Document after being read is
scanned again as a DOMSource and then converted back to a Document object.
Might be a better way to pass it on altogether. Makes me wish I had noticed
the deprecation note on org.hibernate.boot.MetadataSources.addDocument(
Document)

On 16 February 2018 at 23:33, Sanne Grinovero <sa...@hibernate.org> wrote:

> Hi Jordan,
>
> I think it would be great to remove it. Especially recently we've
> started exploring what it would take to convert all jars into proper
> Jigsaw modules, and a requirement is that all dependencies need to be
> converted as well; this is obviously more problematic for such old
> libraries so it would be best to remove 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 February 2018 at 21:11, Jordan Gigov <colad...@gmail.com> wrote:
> > 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 problems
> > you probably encountered prior to JDK6.
> >
> > I've narrowed it down to 11 failing tests (5 distinct exceptions) when
> > using the default XML APIs provided with JDK8.
> >
> > Is there any interest in this?
> > ___
> > 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] Hibernate ORM 5.2 backports

[Jordan Gigov]

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, that's not an option.

On 25 January 2018 at 04:47, Brett Meyer  wrote:

> For what it's worth, +1 on this.  At least back in the day, we'd
> continue to backport bugfixes to the previous minor release, until a new
> final minor release was deployed.  That was the responsibility of
> whoever was committing to master.  Since the baselines were typically
> "close enough", commits generally cherry-picked fairly cleanly.
>
>
> On 1/24/18 6:12 PM, Gail Badner wrote:
> > People seem to be relying on me to backport to 5.2. From a product
> > standpoint, there is no need to backport to 5.2 anymore once 5.3.0 is
> > released. Maybe 5.3.0 and 5.2.13 should be released together, with 5.2.13
> > being the last 5.2 release.
> >
> > >From an earlier thread, it sounds like there is concern outside the ORM
> > team that we need to keep 5.2.x releases going for some time.
> >
> > What is the criteria for backporting?
> >
> > Steve, Andrea, and I had a brief discussion about backporting bugfixes
> from
> > master to 5.2 when the bugs apply to master. Is there more discussion to
> be
> > done about this?
> >
> > FWIW, backporting to active community branches is everyone's
> > responsibility, not mine alone.
> >
> > Regards,
> > Gail
> > ___
> > 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Extras module

[Jordan Gigov]

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 JsonArray as a native query
parameter.

I've tried making a module that uses PgObject, but that runs into very
nasty classloader problems in Apache Tomcat. A work-around should be
possible with reflection, but it isn't worth it for things where
[sg]etString works.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] SqlTypeDescriptor bind by name limitation

[Jordan Gigov]

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 haven't pushed to it.

On 7 June 2017 at 12:25, Vlad Mihalcea  wrote:
> Hi,
>
> While writing an example for a custom Hibernate Type which supports
> PostgreSQL arrays,
> I realized that the SqlTypeDescriptor only supports bind by name:
>
> @Override
> protected void doBind(CallableStatement st, X value, String name,
> WrapperOptions options)
> throws SQLException {
> }
>
> However, for the java.sql.Array, we only have a bind by index method in
> java.sql.Statement:
>
> void setArray (int parameterIndex, Array x) throws SQLException;
>
> I remember that 6.0 is going to bind by index, so maybe this issue is
> already taken care of in the new version.
> Should we provide some fix for 5.x as well?
>
> 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] HHH-11396 - Timezone handling

[Jordan Gigov]

The driver just has to use the available `getDate/getMonth/getYear`
functions of the java.sql.Date class, because they're what's intended
by the API. The problem is that the MySQL driver tries to do more than
that, when their database doesn't even support time zones.

On 14 March 2017 at 12:17, Christian Beikov <christian.bei...@gmail.com> wrote:
> So you are saying that it should be the JDBC drivers responsibility to
> add the JVMs local timezone offset to the java.sql.Date so the
> normalization can subtract the offset again? I would be ok with that,
> but is it really the responsibility of 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
>> 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 conversion without telling it any zones (which
>> that JDBC URL tells it), the problem should go away. The driver does
>> try to read the server's time-zone, though, so maybe using
>> `useTimezone=false` in the JDBC URL is the right solution, but it
>> certainly shouldn't be to try and appease every driver's individual
>> quirks.
>>
>> Even MySQL's own API works under the assumption that LocalDate should
>> be converted using the JVM's default time-zone.
>> https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50
>>
>> On 14 March 2017 at 09:38, Christian Beikov <christian.bei...@gmail.com> 
>> wrote:
>>> Hey everyone,
>>>
>>> I'd like to get your opinion on something. We had this issues regarding
>>> timezone handling which Vlad closed pretty quickly saying it isn't a
>>> Hibernate problem and I generally agree, but still would like to know
>>> what you think about it.
>>>
>>> So basically what we do in the LocalDateJavaDescriptor(and also in some
>>> other places) is to use the value returned by java.sql.Date in some way
>>> and pack that into the target type. In this case this happens behind the
>>> scenes when invoking java.sql.Date.toLocalDate() but internally it just
>>> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>>>
>>> Now IMO the problem really is in java.sql.Date because it does a
>>> timezone conversion. The user who created the issue HHH-11396
>>> <https://hibernate.atlassian.net/browse/HHH-11396> pointed out he was
>>> using a DATE column type because he wanted to have a simple date i.e.
>>> year, month and date. When using java.sql.Date and the consumer is in a
>>> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
>>> subtract that offset during /normalization/ and the millisecond value
>>> will change by that offset. This means that a date in the DBMS that is
>>> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>>>
>>> One possible fix is to simply configure UTC for the consumer, then there
>>> will be no timezone shift.
>>>
>>> I think what java.sql.Date does is wrong because a date has no time
>>> part, so there shouldn't be any time shifts. We should workaround that
>>> by shifting the millisecond value back when constructing a LocalDate.
>>>
>>> What do you think should we do? Does anyone maybe know why java.sql.Date
>>> behaves that way?
>>>
>>>
>>> --
>>>
>>> Mit freundlichen Grüßen,
>>> 
>>> *Christian Beikov*
>>> ___
>>> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-11396 - Timezone handling

[Jordan Gigov]

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 conversion without telling it any zones (which
that JDBC URL tells it), the problem should go away. The driver does
try to read the server's time-zone, though, so maybe using
`useTimezone=false` in the JDBC URL is the right solution, but it
certainly shouldn't be to try and appease every driver's individual
quirks.

Even MySQL's own API works under the assumption that LocalDate should
be converted using the JVM's default time-zone.
https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/JDBC42Helper.java#L50

On 14 March 2017 at 09:38, Christian Beikov  wrote:
> Hey everyone,
>
> I'd like to get your opinion on something. We had this issues regarding
> timezone handling which Vlad closed pretty quickly saying it isn't a
> Hibernate problem and I generally agree, but still would like to know
> what you think about it.
>
> So basically what we do in the LocalDateJavaDescriptor(and also in some
> other places) is to use the value returned by java.sql.Date in some way
> and pack that into the target type. In this case this happens behind the
> scenes when invoking java.sql.Date.toLocalDate() but internally it just
> calls LocalDate.of(getYear() + 1900, getMonth() + 1, getDate()).
>
> Now IMO the problem really is in java.sql.Date because it does a
> timezone conversion. The user who created the issue HHH-11396
>  pointed out he was
> using a DATE column type because he wanted to have a simple date i.e.
> year, month and date. When using java.sql.Date and the consumer is in a
> timezone after UTC i.e. UTC+1, the calculations of java.sql.Date will
> subtract that offset during /normalization/ and the millisecond value
> will change by that offset. This means that a date in the DBMS that is
> 2000-01-01 will become 1999-12-31 when the client is in UTC+1.
>
> One possible fix is to simply configure UTC for the consumer, then there
> will be no timezone shift.
>
> I think what java.sql.Date does is wrong because a date has no time
> part, so there shouldn't be any time shifts. We should workaround that
> by shifting the millisecond value back when constructing a LocalDate.
>
> What do you think should we do? Does anyone maybe know why java.sql.Date
> behaves that way?
>
>
> --
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> ___
> 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] Removing the BlueOcean plugin on CI

[Jordan Gigov]

First the comment needs to be outside the property, otherwise it's not
detected as a text-only node.

Secondly managementPort has to be set, because while arquillian passes
on jboss.socket.binding.port-offset but does not take it into account.
Because of port-offset the management port is moved from 9990 to
10127, but it's the runner framework doesn't know that. It gets stuck
waiting to confirm server start, but it's looking at port 9990 to
check it.

And it looks like I've made the patch with tabs, while the rest of the
file is spaces. Don't commit it mixed like that.


On 23 February 2017 at 13:21, Sanne Grinovero <sa...@hibernate.org> wrote:
> Thanks Jordan!
>
> Can you explain why we need to define the "managementPort" property?
> Do you have a link to the issue maybe?
> I'd like to understand that better, especially as we have several
> other projects to patch.
>
> Sanne
>
> On 23 February 2017 at 11:09, Jordan Gigov <colad...@gmail.com> wrote:
>> On 23 February 2017 at 12:24, Sanne Grinovero <sa...@hibernate.org> 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 didn't shut down correctly.
>>
>> There is a configuration problem with WildFly, partly due to an
>> arquillian bug, partly due to a bug in the wildfly-arquillian runner,
>> but both can be bypassed using this patch
>> http://pastebin.com/q2Nt0Ent
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Removing the BlueOcean plugin on CI

[Jordan Gigov]

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 didn't shut down correctly.

There is a configuration problem with WildFly, partly due to an
arquillian bug, partly due to a bug in the wildfly-arquillian runner,
but both can be bypassed using this patch
http://pastebin.com/q2Nt0Ent
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] AutoCloseable is great.. what about JPA?

[Jordan Gigov]

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

Re: [hibernate-dev] 6.0 - Type redesign

[Jordan Gigov]

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 class names
>> of the final object.
>> That would have to be a secondary check if no match is found by Java
>> class name, because it's slower and dangerous when binding
>> parameters to a query.
>
>
> I am not sure what you are talking about here.
>
>
>> If stored as Class object references, they would have to be held in
>> WeakReference objects tied to a ReferenceQueue, so as not to
>> prevent garbage collection when a context is unloaded in a multi-context
>> server.
>>
>> If stored as Strings, there would have to be a call to Class.forName
>> for each, which if successful would have to check isInstance on the
>> object or isAssignableFrom on it's class (when evaluating DB model).
>
>
> Again, not really sure what you are talking about here.  I guess you mean in
> some "cache" based on the Java type handled?
>

I am talking about type registration and resolution in both. Right now,
they're being registered in
org.hibernate.boot.model.process.spi.MetadataBuildingProcess#handleTypes
which creates a BasicTypeRegistry for resolving them.
In the current state, they can only be registered by full class name.
I'm proposing that they can optionally register interfaces.


> Statement also gives you access to the Connection (Statement#getConnection)
>
Which JavaTypeDescriptor wrap and unwrap have no access to under the old model.

> In general a lot of points are just out of date.  If you want to influence
> the development of this or be part of it you should consider joining the
> HipChat channel where we discuss this stuff.  I stopped trying to discuss
> here because no one generally answers.
>
By HipChat do you mean the IRC #hibernate channel on Freenode?
If not, the Community page has no mention of HipChat.
Time zone differences would likely make that a poor choice for me. I'm
in the EET zone.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 6.0 - Type redesign

[Jordan Gigov]

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.
Can't it just work with regular binding to the PreparedStatement so
the unsafe interface can be removed?


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 class names
of the final object.
That would have to be a secondary check if no match is found by Java
class name, because it's slower and dangerous when binding
parameters to a query.

If stored as Class object references, they would have to be held in
WeakReference objects tied to a ReferenceQueue, so as not to
prevent garbage collection when a context is unloaded in a multi-context server.

If stored as Strings, there would have to be a call to Class.forName
for each, which if successful would have to check isInstance on the
object or isAssignableFrom on it's class (when evaluating DB model).


There are currently no notes on how to handle binding the values to a
PreparedStatement/CallableStatement.
There is also no mention of how java.sql.SQLType that was added in
Java 8 comes into play, which will help with vendor-specific types.

When converting the new types to a bindable object they will need
access to the Dialect and these methods of the java.sql.Connection:
createArrayOf
createBlob
createClob
createNClob
createSQLXML
createStruct
getClientInfo
getMetaData which returns DatabaseMetaData which can give access to
the java.sql.Connection if we're trying to abstract away from it.

Maybe also to:
setClientInfo
getWarnings when reading results from the database
getTypeMap
setTypeMap


On Thu Jul 21 15:27:49 EDT 2016 Steve Ebersole  wrote:

> I know we could get around this by splitting (or keeping split) the notions
> of ORM Type and JPA Type, but I would like to avoid that : this unification
> is going to be important to the SQM Criteria support.

Reading the description of javax.persistence.metamodel.Type, I'm not
sure it serves the same purpose as Hibernate's Type and that it should
be a super-interface of it.
In fact, starting to read the Metamodel API chapter where these
interfaces are defined, I'm fairly certain it's supposed to reflect
the structure of the persistence unit.
In other words, I don't think javax.persistence.metamodel.Type fits
anywhere in this picture and it's a different concept altogether.


As for OGM (which I've never used, but here's an idea) the problem
with SqlTypeDescriptor (discussed in end of June, as I read the mail
archives)
maybe could be turned into an extension of a more generic
StorageTypeDescriptor, and SQL would be just one type of storage? I
don't know
how that would work, since I've never had to use NoSQL and don't even
know if that makes sense.
Maybe the persistence context should provide the binders/extractors to
each type upon use.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Array datatypes optional module

[Jordan Gigov]

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.
They've only been presumed to work so far.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NativeQuery and parameters

[Jordan Gigov]

That sounds reasonable. So long as there is a property to control it from
persistence.xml, more people will be happy with it.

It would be very important to quote whatever error people will get in the
docs, so they can find the solution easier.

2016-09-21 22:03 GMT+03:00 Steve Ebersole <st...@hibernate.org>:

> One additional thing we might consider is possibly unifying this 0- and 1-
> based mismatch wrt JDBC-style parameters.
>
> In Hibernate's APIs these JDBC-style parameters were 0-based.  I have
> already dropped support (it has been deprecated for a long time anyway) for
> using JDBC-style params in HQL.  So this is now only a concern for native
> queries.
>
> Interestingly JPA has the following to say (3.10.13 Positional Parameters):
> 
> Only positional parameter binding ... may be portably used for native
> queries... When binding the values of positional parameters, the numbering
> starts as “1”. It is assumed that for native queries the parameters
> themselves use the SQL syntax (i.e., “?”, rather than “?1”).
> 
>
> So for portable JPA, the native query would use JDBC/SQL syntax for the
> parameter marker, but use the JPA convention for parameter index (1-based)
> rather than the JDBC/SQL convention (0-based).
>
> As bassackwards as we may think JPA is here, it is a spec and we have to
> support it: we have to support 1-based binding of these JDBC-style params.
> The question is whether we should deviate from Hibernate's legacy decision
> to align with JDBC/SQL (0-based) for binding of these JDBC-style params.
> Perhaps a setting that controls how this should work - specifically limited
> to JDBC-style param markers in native queries.  By default we'd honor the
> 1-based approach whenever bootstrapping was done via JPA and 0-based when
> native bootstrapping is used.  I guess what I am wondering is whether we
> want to have a setting for the native bootstrapping piece that controls
> whether to use 0-based or 1-based?  I do not think we should allow the
> setting (if we add one) to force 0-based usage with JPA bootstrapping; this
> would only control how it works in native bootstrapping.
>
> Thoughts?
>
> On Wed, Sep 21, 2016 at 1:40 PM Steve Ebersole <st...@hibernate.org>
> wrote:
>
>> I never said anything about dropping support for named and positional
>> 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 Tue, Sep 20, 2016 at 11:45 PM Jordan Gigov <colad...@gmail.com> wrote:
>>
>>> 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 Ebersole <st...@hibernate.org>:
>>>
>>>> In the interest of questioning everything, just to make sure we are all
>>>> on
>>>> the same page, Hibernate's support for native SQL queries currently
>>>> recognizes named parameters, positional parameters as well as JDBC-style
>>>> parameters.
>>>>
>>>> JPA only defines support for "JDBC-style parameters" as valid for native
>>>> SQL queries:
>>>> {quote}
>>>> It is assumed that for native queries the parameters themselves use the
>>>> SQL
>>>> syntax (i.e., “?”, rather than “?1”).
>>>> {quote}
>>>>
>>>> Furthermore Hibernate does not support a native query using both
>>>> positional
>>>> parameters and JDBC-style parameters in the same query because it
>>>> causes a
>>>> non-determinism wrt the positions.
>>>>
>>>> I assume we want to continue to support that full complement of
>>>> parameter
>>>> types, with the positional/JDBC-style caveat.
>>>>
>>>> Further I assume we will hook up the use of any non-JDBC-style
>>>> parameters
>>>> in with the "strict JPA compliance" checking and throw an error when
>>>> indicated.
>>>>
>>>> Anyone have objections to any of that?
>>>>
>>> ___
>>>> 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] Build time downloads of ORM itself during an ORM clean build?

[Jordan Gigov]

I mean this dependency in "buildscript"
https://github.com/hibernate/hibernate-orm/blob/master/documentation/documentation.gradle#L22

2016-09-21 17:59 GMT+03:00 Steve Ebersole <st...@hibernate.org>:

> By "package buildscripts" do you mean the buildSrc module?  That should
> not be the case.
>
> If not, what do yo mean by "package buildscripts"?
>
>
>
> On Wed, Sep 21, 2016 at 9:47 AM Jordan Gigov <colad...@gmail.com> wrote:
>
>> 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' branch and it didn't download the core snapshot as
>> it
>> does in 'master'.
>>
>> As far as I can determine, this plugin enhances entity classes after
>> they're built, which I suppose is meant to speed-up the tests slightly.
>>
>> 2016-09-21 12:50 GMT+03:00 Sanne Grinovero <sa...@hibernate.org>:
>>
>> > Hi all,
>> >
>> > I just happened to build Hibernate ORM's latest "master" on a clean
>> > machine and this is how the build log looks like:
>> >
>> > No compatible daemons found:
>> >   - an idle daemon with different JVM constraints can't run this build
>> > Starting a new Gradle Daemon for this build: subsequent builds will be
>> > faster
>> > :buildSrc:clean UP-TO-DATE
>> > :buildSrc:compileJava UP-TO-DATE
>> > :buildSrc:compileGroovy
>> > :buildSrc:processResources UP-TO-DATE
>> > :buildSrc:classes
>> > :buildSrc:jar
>> > :buildSrc:assemble
>> > :buildSrc:compileTestJava UP-TO-DATE
>> > :buildSrc:compileTestGroovy UP-TO-DATE
>> > :buildSrc:processTestResources UP-TO-DATE
>> > :buildSrc:testClasses UP-TO-DATE
>> > :buildSrc:test UP-TO-DATE
>> > :buildSrc:check UP-TO-DATE
>> > :buildSrc:build
>> > Download http://repository.jboss.org/nexus/content/groups/public/
>> > org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-
>> > 5.2.3-20160920.201550-53.jar
>> > [...]
>> >
>> > I'm not having any specific failure, but it seems very suspicious that
>> > the build is needing to download hibernate-core at the very beginning
>> > of the build?
>> >
>> > I'm not familiar enough with ORM's build scripts to investigate myself
>> > but I suspect some dependency order needs to be cleaned up, or you
>> > might be including some side-effects from previous builds.
>> >
>> > Thanks,
>> > Sanne
>> > ___
>> > 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Build time downloads of ORM itself during an ORM clean build?

[Jordan Gigov]

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' branch and it didn't download the core snapshot as it
does in 'master'.

As far as I can determine, this plugin enhances entity classes after
they're built, which I suppose is meant to speed-up the tests slightly.

2016-09-21 12:50 GMT+03:00 Sanne Grinovero :

> Hi all,
>
> I just happened to build Hibernate ORM's latest "master" on a clean
> machine and this is how the build log looks like:
>
> No compatible daemons found:
>   - an idle daemon with different JVM constraints can't run this build
> Starting a new Gradle Daemon for this build: subsequent builds will be
> faster
> :buildSrc:clean UP-TO-DATE
> :buildSrc:compileJava UP-TO-DATE
> :buildSrc:compileGroovy
> :buildSrc:processResources UP-TO-DATE
> :buildSrc:classes
> :buildSrc:jar
> :buildSrc:assemble
> :buildSrc:compileTestJava UP-TO-DATE
> :buildSrc:compileTestGroovy UP-TO-DATE
> :buildSrc:processTestResources UP-TO-DATE
> :buildSrc:testClasses UP-TO-DATE
> :buildSrc:test UP-TO-DATE
> :buildSrc:check UP-TO-DATE
> :buildSrc:build
> Download http://repository.jboss.org/nexus/content/groups/public/
> org/hibernate/hibernate-core/5.2.3-SNAPSHOT/hibernate-core-
> 5.2.3-20160920.201550-53.jar
> [...]
>
> I'm not having any specific failure, but it seems very suspicious that
> the build is needing to download hibernate-core at the very beginning
> of the build?
>
> I'm not familiar enough with ORM's build scripts to investigate myself
> but I suspect some dependency order needs to be cleaned up, or you
> might be including some side-effects from previous builds.
>
> Thanks,
> Sanne
> ___
> 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] NativeQuery and parameters

[Jordan Gigov]

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 Ebersole :

> In the interest of questioning everything, just to make sure we are all on
> the same page, Hibernate's support for native SQL queries currently
> recognizes named parameters, positional parameters as well as JDBC-style
> parameters.
>
> JPA only defines support for "JDBC-style parameters" as valid for native
> SQL queries:
> {quote}
> It is assumed that for native queries the parameters themselves use the SQL
> syntax (i.e., “?”, rather than “?1”).
> {quote}
>
> Furthermore Hibernate does not support a native query using both positional
> parameters and JDBC-style parameters in the same query because it causes a
> non-determinism wrt the positions.
>
> I assume we want to continue to support that full complement of parameter
> types, with the positional/JDBC-style caveat.
>
> Further I assume we will hook up the use of any non-JDBC-style parameters
> in with the "strict JPA compliance" checking and throw an error when
> indicated.
>
> Anyone have objections to any of that?
> ___
> 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] 6.0 - Type redesign

[Jordan Gigov]

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 ugly hackyness. It also needs to call
`java.sql.Connection.createArrayOf` on that same connection. Those two
interfaces should somehow be exposed to the type handlers at some point.
Also I haven't figured out yet how to use them as arrays of entity keys.
Storing an array of entities by their Id keys would be a nice bonus.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev