Re: [hibernate-dev] [OGM] Issue with a test and the new operation grouping infrastructure

2016-09-20 Thread Yoann Rodiere 
(Don't know what's the status of this, since it's been discussed on IRC,
but jumping in just in case)

I tend to agree with Gunnar that storing the association on the owning side
of the association seems like a good idea. At least with an external point
of view, it seems like the right choice, but I may be missing some details.

As for the specifics of the implementation, I just stumbled upon
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper`.
`getInverseCollectionPersister(OgmCollectionPersister)` and
`getInverseAssociationKeyMetadata(OgmEntityPersister, int)` may help... ?
All these methods suffer from a limitation: the current implementation will
only work with non-inverse collection persisters. **But** I wonder if it's
a limitation of the current implementation (we can't do more) or an
arbitrary limitation added on purpose (we don't want to do more).
For instance, in `getInverseCollectionPersister(OgmCollectionPersister)`,
we might think that the element persister used to get the reverse side is
null for inverse association. But from what I see in
`org.hibernate.persister.collection.AbstractCollectionPersister.AbstractCollectionPersister(Collection,
CollectionRegionAccessStrategy, PersisterCreationContext)` (line 315), the
element persister is always non-null regardless of whether the collection
persister is on the owning or the inverse side, provided it's not an
`@ElementCollection`.
Anyway, what I'm trying to say is:
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper` might not
help as it is now, but it's probably a good starting point.


Yoann Rodière 
Hibernate NoORM Team

On 12 September 2016 at 17:31, Guillaume Smet 
wrote:

> Hi,
>
> This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767
> .
>
> So, in the PR, I commented the following test:
> ManyToOneGlobalTest>ManyToOneTest.testRemovalOfTransientEntityWi
> thAssociation
> (the "ManyToOneGlobalTest>" part is important)
>
> The test is a Redis one but the issue is a general one.
>
> When running under the ManyToOneGlobalTest umbrella, the associations
> are created as separate documents.
>
> The behavior of the test is the following:
>
> 
>
> === Creation phase
>
> Create a SalesForce with 2 SalesGuys associated.
>
> The association is managed by SalesGuy.
>
> It creates 4 documents:
> SalesForce1
> SalesGuy1
> SalesGuy2
> SalesForce1_SalesGuy navigational information
>
> === Let's delete the SalesForce1 entity
>
> It removes the SalesForce1 document (note that SalesGuy.salesForce has
> a @NotFound(action = NotFoundAction.IGNORE) annotation).
>
> So we end up with having:
> SalesGuy1
> SalesGuy2
> SalesForce1_SalesGuy navigational information [1]
>
> === Then we delete the 2 SalesGuy
>
> SalesGuys1 removed
> -> SalesForce_SalesGuy navigational information updated
> SalesGuy2 removed
> -> SalesForce1_SalesGuy navigational information removed as it is empty [2]
>
> 
>
> In [1], we still have the navigational information for SalesForce1 <->
> SalesGuys.
>
> With the new grouping infrastructure, I don't save every operation to
> the datastore as it's currently done. I have to store the Association
> object somewhere to keep track of the association state so I store it
> in OgmEntityEntryState in a Map, the key being
> the role of the association, just next to the Tuple which has the same
> purpose. It works perfectly well except that when we arrive at [2],
> the OgmEntityEntryState for SalesForce1 is gone as the entity has been
> removed in [1] so I can't access the OgmEntityEntryState of the entity
> and so the association document is not removed (and thus the test
> fails as it checks there isn't any entity/association left).
>
> Gunnar proposed the idea of storing the inverse Associations in the
> OgmEntityEntryState of the association owner. It's indeed one way to
> solve the issue.
>
> The issue with this approach is that we need to have the association
> owner when we create the AssociationPersister and, while it's not a
> problem for most of the cases, I don't see how I can do it in
> OgmLoader#getResultSet. I posted a WIP patch here:
> https://gist.github.com/gsmet/e18ccb7d3f3494bb334647e540d0d4d0.
>
> Opinions, thoughts?
>
> --
> Guillaume
> ___
> 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] HHH-9329

2016-09-20 Thread Christian Beikov 
Hey again,

I implemented the approach that I proposed in the issue and a test in 
https://github.com/hibernate/hibernate-orm/pull/1561

It detects left joins with join tables that use the target table alias. 
The join table is replaced with a subquery and the WITH clause is moved 
to the join of the subquery.

Any comments?

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

Re: [hibernate-dev] HHH-9329

2016-09-20 Thread Vlad Mihalcea 
Thanks,

I'm going to review it tomorrow.

Vlad

On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> Hey again,
>
> I implemented the approach that I proposed in the issue and a test in
> https://github.com/hibernate/hibernate-orm/pull/1561
>
> It detects left joins with join tables that use the target table alias.
> The join table is replaced with a subquery and the WITH clause is moved
> to the join of the subquery.
>
> Any comments?
>
> Regards,
> Christian
> ___
> 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-9329

2016-09-20 Thread Steve Ebersole 
I took a quick look.  I'd prefer to see better solution as we migrate to
SQM; but for 5.x, given how Hibernate generates SQL there, I am not sure
how else you would possibly do this


On Tue, Sep 20, 2016 at 12:54 PM Vlad Mihalcea 
wrote:

> Thanks,
>
> I'm going to review it tomorrow.
>
> Vlad
>
> On Tue, Sep 20, 2016 at 8:38 PM, Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> > Hey again,
> >
> > I implemented the approach that I proposed in the issue and a test in
> > https://github.com/hibernate/hibernate-orm/pull/1561
> >
> > It detects left joins with join tables that use the target table alias.
> > The join table is replaced with a subquery and the WITH clause is moved
> > to the join of the subquery.
> >
> > Any comments?
> >
> > Regards,
> > Christian
> > ___
> > 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

[hibernate-dev] NativeQuery and parameters

2016-09-20 Thread 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

Re: [hibernate-dev] NativeQuery and parameters

2016-09-20 Thread Brett Meyer 
+1 across the board.


On 09/20/2016 08:59 PM, Steve Ebersole wrote:
> 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] NativeQuery and parameters

2016-09-20 Thread 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] NativeQuery and parameters

2016-09-20 Thread Vlad Mihalcea 
+1

On Wed, Sep 21, 2016 at 3:59 AM, Steve Ebersole  wrote:

> 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] NativeQuery and parameters

2016-09-20 Thread Gunnar Morling 
+1 Sounds good.

2016-09-21 2:59 GMT+02: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