Re: [hibernate-dev] Joins over type variable defined assocations NPE problems

[Steve Ebersole]

I think it is ok to disallow implicit downcasting in cases where the
downcast is non-deterministic.  From you example domain, I think it is ok
to disallow the implicit downcast in : `from BaseEntity e where
e.relation.id = ...' with either a specific error ("cannot implicitly
downcast BaseEntity to (EntityA, EntityB) due to named attributes being
unrelated") or a general "un-resolved attribute" error.  On option to
address that would be to change your registering a null, to instead
recognizing that the passed property fits this description in its
PropertyMapping impls and throw such an exception.

And I think as long as you remove it from that entity's/component's various
attribute-info arrays it should handle the SQL generation too.

If you like that approach better...

On Mon, Mar 12, 2018 at 12:02 PM andrea boriero 
wrote:

> Hi Christian,
> I have looked at your PR and at the moment I cannot find another easy clean
> solution for this issue not requiring as you said quite a lot of work.
>
>
>
> On 9 March 2018 at 20:20, Christian Beikov 
> wrote:
>
> > Hey,
> >
> > so the problems related to the type variable handling I did aren't fully
> > solved. There is one other case that was reported today:
> > https://hibernate.atlassian.net/browse/HHH-12375
> >
> > I'm not sure how to handle this. Let me explain you the model and the
> > problem.
> >
> > @Entity class BaseEntity { @Id Integer id; }
> > @Entity class EntityA extends BaseEntity { @ManyToOne EntityC relation; }
> > @Entity class EntityB extends BaseEntity { @ManyToOne EntityD relation; }
> > @Entity class EntityC {...}
> > @Entity class EntityD {...}
> >
> > The essence is, that EntityA and EntityB define properties with the same
> > names but have unrelated types. It's actually the same problem for
> > collections.
> >
> > Since EntityA and EntityB extend BaseEntity and because BaseEntity is an
> > @Entity, the Hibernate code tries to add "EntityA.relation" and
> > "EntityB.relation" to the PropertyMapping of BaseEntity. Before my fix,
> > the property which is added first won and subsequent adds are ignored.
> > This is presumably done to support implicit downcasting. My fix was
> > about making use of a common super type if possible and disallowing
> > ambiguous access.
> >
> > The problem the user now reported is, when using FetchType.EAGER there
> > is an exception which states that property "relation" could not be found
> > on type "BaseEntity". This is because I register "null" as type to
> > signal that it's not really possible to use that property with that
> > persister(BaseEntity in this case). During booting, the load plan for
> > BaseEntity is built, for which the SQL is pre-generated. At this point,
> > the exception happens, because "null" is registered as type for the
> > property "relation". This will cause the property to be considered as
> > non-existant wrt getPropertyType. The code before my fix was essentially
> > broken, because it doesn't handle eager fetching properly due to the
> > "first property wins" strategy. A property might only be loaded through
> > a secondary query due to lazy loading rather than by the defined fetch
> > style. An implicit downcasted join using the property might lead to
> > non-deterministic results.
> >
> > One of the reasons for doing the fix, was to prevent the possibility of
> > being hit by the non-determinism. I had a mapping that was using the
> > type variable approach and I had to find out the non-determinism the
> > hard way. I'd like to prevent access to such conflicting attributes from
> > the top level type through implicit downcasting, so IMO the only real
> > solution is to exclude the conflicting attributes in the load plan.
> >
> > The "best" solution would be to introduce a synthetic type that
> > represents the union of the unrelated property types, but to me this
> > seems to be quite a lot of work.
> >
> > I have implemented the proposed solution here:
> > https://github.com/hibernate/hibernate-orm/pull/2190
> >
> > We need to release this fix soon as the current state is broken for the
> > EAGER configuration. What do you think about the solution or the matter
> > in general?
> >
> > --
> >
> > 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] Hibernate support for JDBC drivers targeting multiple JVM versions

[Bregler, Jonathan]

I don’t have a specific link for the sharding feature. I just took a quick look 
at the JDBC 4.3 spec. The overview of changes lists the following changes 
regarding sharding:


  *   Added support for Sharding.
Sharding is a scaling technique in which data is horizontally partitioned 
across independent databases.


  *   Addition of the java.sql.ShardigKey interface
This interface is used to indicate that this object represents a Sharding Key. 
A ShardingKey instance is only guaranteed to be compatible with the data source 
instance that it was derived from.


  *   Addition of the java.sql.ShardingKeyBuilder interface

A builder created from a DataSource or XADataSource object, used to create a 
ShardingKey with sub-keys of supported data types.

Just for completeness, there are other new interfaces that cause similar 
problems:

  *   Addition of the java.sql.ConnectionBuilder interface

A builder created from a DataSource object, used to establish a connection to 
the database that the data source object represents.


  *   Addition of the javax.sql.XAConnectionBuilder interface

A builder created from a XADataSource object, used to establish a connection to 
the database that the data source object represents.


  *   Addition of the javax.sql.PooledConnectionBuilder interface

A builder created from a PooledConnectionDataSource object, used to establish a 
connection to the database that the data source object represents.

It looks like the HANA JDBC driver team will most likely go with multi-release 
JARs. If everything goes as planned we’ll also publish the driver on Maven 
Central soon.

- Jonathan

From: Steve Ebersole [mailto:st...@hibernate.org]
Sent: Tuesday, March 13, 2018 4:21 PM
To: Bregler, Jonathan 
Cc: Sanne Grinovero ; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting 
multiple JVM versions

Out of curiosity, do you have a link to this new java.sql.ShardingKey feature?

Other than that, I agree with Sanne - multiple jars (with proper classifier 
once y'all publish your drivers) is the best option

On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan 
> wrote:
Hi Sanne,

Multi-release JARs sound promising. I'll forward your suggestion to the HANA 
JDBC driver team.

Thanks,
Jonathan

-Original Message-
From: sanne.grinov...@gmail.com 
[mailto:sanne.grinov...@gmail.com] On Behalf 
Of Sanne Grinovero
Sent: Monday, March 12, 2018 4:45 PM
To: Bregler, Jonathan 
>
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting 
multiple JVM versions

Hi Jonathan,

personally this looks like an issue with the driver as class
initialization could be triggered by a number of things, it's going to
be hard to dodge them all, not least all containers and servers have
their own peculiarities in how they load and wrap drivers and
datasources; could you suggest the HANA JDBC team to release
multi-release jars?  That would be safer, and also avoid issues with
other tools beyond Hibernate ORM.
 - http://openjdk.java.net/jeps/238

Thanks,
Sanne

On 12 March 2018 at 15:27, Bregler, Jonathan 
> wrote:
> Hi,
>
> in a recent version of the HANA JDBC driver the new JDBC 4.3 features that 
> came with Java 9 have been implemented. The driver itself is still compiled 
> for Java 7 (javac -target 1.7). So the driver should also be usable with a 
> JVM 7 or 8. This works as expected until Java reflection is used to 
> determine, for example, the existence of a method on the connection class. 
> Hibernate uses this approach in 
> org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
>  to determine if the connection class implements the #getSchema method. In 
> this case the JVM tries to load the entire connection class including the 
> non-existing new interface java.sql.ShardingKey. The result is a 
> java.lang.NoClassDefFoundError being thrown which isn't caught anywhere 
> causing the Hibernate bootstrapping process to fail. I've attached a sample 
> stack trace to this mail.
>
> Situations like this can also occur in other places, for example, when 
> getting a connection from a Hikari connection pool.
>
> My question is now how you think Hibernate should handle situations like 
> this. Do you see it as a JDBC driver issue? Should Hibernate ignore the error 
> and continue with a conservative guess if possible (e.g. assume that the 
> connection class doesn't implement #getSchema)?
>
> Thanks,
> Jonathan
>
> ___
> hibernate-dev mailing list
> 

[hibernate-dev] NoORM IRC meeting minutes

[Guillaume Smet]

Hi everyone,

Here are the minutes of our biweekly NoORM IRC meeting:

17:02 < jbott> Meeting ended Tue Mar 13 16:02:18 2018 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:02 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-03-13-15.01.html
17:02 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-03-13-15.01.txt
17:02 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-03-13-15.01.log.html

Cheers,

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

Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions

[Steve Ebersole]

Out of curiosity, do you have a link to this new java.sql.ShardingKey
feature?

Other than that, I agree with Sanne - multiple jars (with proper classifier
once y'all publish your drivers) is the best option

On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan 
wrote:

> Hi Sanne,
>
> Multi-release JARs sound promising. I'll forward your suggestion to the
> HANA JDBC driver team.
>
> Thanks,
> Jonathan
>
> -Original Message-
> From: sanne.grinov...@gmail.com [mailto:sanne.grinov...@gmail.com] On
> Behalf Of Sanne Grinovero
> Sent: Monday, March 12, 2018 4:45 PM
> To: Bregler, Jonathan 
> Cc: hibernate-dev@lists.jboss.org
> Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting
> multiple JVM versions
>
> Hi Jonathan,
>
> personally this looks like an issue with the driver as class
> initialization could be triggered by a number of things, it's going to
> be hard to dodge them all, not least all containers and servers have
> their own peculiarities in how they load and wrap drivers and
> datasources; could you suggest the HANA JDBC team to release
> multi-release jars?  That would be safer, and also avoid issues with
> other tools beyond Hibernate ORM.
>  - http://openjdk.java.net/jeps/238
>
> Thanks,
> Sanne
>
> On 12 March 2018 at 15:27, Bregler, Jonathan 
> wrote:
> > Hi,
> >
> > in a recent version of the HANA JDBC driver the new JDBC 4.3 features
> that came with Java 9 have been implemented. The driver itself is still
> compiled for Java 7 (javac -target 1.7). So the driver should also be
> usable with a JVM 7 or 8. This works as expected until Java reflection is
> used to determine, for example, the existence of a method on the connection
> class. Hibernate uses this approach in
> org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
> to determine if the connection class implements the #getSchema method. In
> this case the JVM tries to load the entire connection class including the
> non-existing new interface java.sql.ShardingKey. The result is a
> java.lang.NoClassDefFoundError being thrown which isn't caught anywhere
> causing the Hibernate bootstrapping process to fail. I've attached a sample
> stack trace to this mail.
> >
> > Situations like this can also occur in other places, for example, when
> getting a connection from a Hikari connection pool.
> >
> > My question is now how you think Hibernate should handle situations like
> this. Do you see it as a JDBC driver issue? Should Hibernate ignore the
> error and continue with a conservative guess if possible (e.g. assume that
> the connection class doesn't implement #getSchema)?
> >
> > Thanks,
> > Jonathan
> >
> > ___
> > 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-announce] Hibernate Search 5.9.1.Final released

[Sanne Grinovero]

Great, thanks for being such a champion of users!

On 13 March 2018 at 14:46, Guillaume Smet  wrote:
> Hi,
>
> We just released version 5.9.1.Final of Hibernate Search containing a
> usability improvement for our Elasticsearch integration.
>
> More information here:
> http://in.relation.to/2018/03/13/hibernate-search-5-9-1-Final/
>
> Have a nice day.
>
> --
> Guillaume
> ___
> hibernate-announce mailing list
> hibernate-annou...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-announce
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.9.1.Final released

[Guillaume Smet]

Hi,

We just released version 5.9.1.Final of Hibernate Search containing a
usability improvement for our Elasticsearch integration.

More information here:
http://in.relation.to/2018/03/13/hibernate-search-5-9-1-Final/

Have a nice day.

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

Re: [hibernate-dev] Proxying the Session: a requirement ?

[Sanne Grinovero]

On 9 March 2018 at 13:42, Guillaume Smet  wrote:
> On Fri, Mar 9, 2018 at 2:14 PM, Sanne Grinovero  wrote:
>>
>> Thanks Steve; anybody knows about Spring et al possibly using AOP on
>> the native Session ?
>>
>> Yes I'm working on the "thread-based current-session stuff" but that's
>> massive, might be days of just coding; hoping it won't be a pointless
>> exercise.
>
>
> No idea but we should really check that with at least the Spring folks
> before investing so much time in it.
>
> Gaining compatibility by breaking an implicit contract we had before might
> not be our best move.

Sorry, forgot to send my reply.. but yes I absolutely agree, I'm
concerned about this change. I'm trying to reach out / test at least
with Spring and Grails as a starting point.

In the meantime I've been working on some improvements within ORM with
our proxies, those improvements won't hurt anyway.

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