Bug in org.hibernate.hql.ast.tree.DotNode#dereferenceEntity, need help assembling test case
by Christopher Smith
I have run into a bug in 3.6.10.Final that I can replicate and
describe, but I'm not sure how to generate a useful automated test
case (the application I'm working on is using Spring/JPA/Hibernate,
and I don't know how to set up the test sessions and such by hand).
I've traced the bug to DotNode#dereferenceEntity, and I may be able to
debug it further after I garbage-collect my head.
Our use case: We have a class of JPA entity that contains some basic
data. A handful of these entities have some extended data, and so we
have a separate class with a FK reference back to the basic class
(since most of the entities don't have extended data) and a mapped
Java field from the basic to the extended. The classes look like this
(plus Roo ITDs):
@Entity public class BasicData {
@Id private long id;
@Embedded private String basicInfo;
@OneToOne(mappedBy="basic") private ExtendedData extended;
}
@Entity public class ExtendedData {
@Id private long id;
@Embedded private String extendedInfo
@OneToOne private BasicData basic;
}
Standard JPA field navigation works fine; we can look up either class
by PK using EntityManager#find and can navigate back and forth. The
generated DDL is what we expect.
However, the JPQL query "SELECT b from BasicData WHERE b.extended IS
NULL" is compiled incorrectly: The correct SQL is something like
"SELECT * FROM BasicData LEFT JOIN Extended ON BasicData.ID =
Extended.BASIC WHERE Extended.BASIC IS NULL", but Hibernate generates
"SELECT * FROM BasicData WHERE BasicData.ID IS NULL", which of course
returns no records.
When I turn up AST logging, I get this line:
'15:32:26.242 DEBUG org.hibernate.hql.ast.tree.DotNode -
dereferenceShortcut() : property extended in BasicData does not
require a join.'
It appears that the AST is trying to optimize away the join and is
incorrectly believing that it's okay. I am happy to help create a
test case and to debug the AST analyzer on my end if that will help,
but I'm not sure where to start (since I'm using JPA and not direct
Hibernate).
--
Christopher Smith, CCNP, CCDP, MCP, LPIC-1
Sphere Systems
12 years, 9 months
Re: [hibernate-dev] [OGM] AssociationKey table property during the create tuple association
by Emmanuel Bernard
On 7 mars 2012, at 18:00, Guillaume SCHEIBEL wrote:
> OK, but to set the fk to B into A I need to retrieve (from the DB would be good I think) the current instance of B.
No, why?
In this case you will need to create a mongodb document that contains the navigational information to go from a to b. That's what Hibernate OGM expects conceptually at least.
And Hibernate OGM will ask and load the right association keys and then the entity keys to load the object graph.
> When you say " you should have two RowKeys " you mean, two calls to the createAssociationTuple method right ?
>
Ahhhh sorry, I did not mean rowKey but EntityKey. Sorry about this confusion.
>
> Guillaume
>
>
> 2012/3/7 Emmanuel Bernard <emmanuel(a)hibernate.org>
> No, you should have two RowKeys, one for Entity A and one for Entity B (speaking of instances here).
> AssociationKey represents the navigational info to go from A to B (B to A would be represented by a second AssociationKey object).
> And what would be stored is the list of navigational info (in your case one to one, the list is of size 0 or 1).
>
> The nav info is made of:
> - the fk from A
> - the fk to B
> - optionally the index or map key value
>
> The AssociationKey is made of:
>
> - the association table name (in your example EntityA)
> - the asso fk name and value, in your case entityb_id: "abc"
>
> On 7 mars 2012, at 17:08, Guillaume SCHEIBEL wrote:
>
> > Hello,
> >
> > I'm writting the OGM dialect for mongodb and I work on the @OneToOne
> > association.
> > When the createTupleAssociation method is called, there is an
> > AssociationKey parameter which should (I think) represents the object to
> > which we are associated.
> >
> > Let's take a very short example:
> >
> > class EntityA {
> >
> > @Id
> > String id;
> >
> > @OneToOne
> > EntityB entityb;
> >
> > //with getters, setters, etc.
> > }
> >
> > class EntityB {
> > @Id
> > String id;
> >
> > //with getters, setters, etc.
> > }
> >
> > Currently, the rowKey object refers to EntityA (with the table name and the
> > id) and AssociationKey refers to EntityB. But the table property of
> > AssociationKey is set to entityA and not entityB as it should be.
> >
> > Did I miss something or is it a real "bug" ?
> >
> > Thanks
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
12 years, 9 months
[OGM] AssociationKey table property during the create tuple association
by Guillaume SCHEIBEL
Hello,
I'm writting the OGM dialect for mongodb and I work on the @OneToOne
association.
When the createTupleAssociation method is called, there is an
AssociationKey parameter which should (I think) represents the object to
which we are associated.
Let's take a very short example:
class EntityA {
@Id
String id;
@OneToOne
EntityB entityb;
//with getters, setters, etc.
}
class EntityB {
@Id
String id;
//with getters, setters, etc.
}
Currently, the rowKey object refers to EntityA (with the table name and the
id) and AssociationKey refers to EntityB. But the table property of
AssociationKey is set to entityA and not entityB as it should be.
Did I miss something or is it a real "bug" ?
Thanks
Guillaume
12 years, 9 months
HSearch: Do includePaths also reduce queries because objects "dirty" less quickly?
by Marc Schipperheyn
With the new includePaths on IndexedEmbedded is it now possible to have a
more specific "dirty" check? Since you are indexing less paths, it stands
to reason that less objects will need to be reindexed because they are
(potentially) "dirty" during a save operation. I'm just curious if new
opportunities arise to reduce the number of queries executed here
Marc
12 years, 9 months
Re: [hibernate-dev] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Paul Ferraro
----- Original Message -----
> From: "Galder Zamarreño" <galder(a)redhat.com>
> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
> Cc: hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development" <jboss-as7-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 2:27:13 PM
> Subject: Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level
> cache
>
> So, to summarise all of this. What I suggest is this:
>
> - Short term:
> The "quick fix" I suggest in
> http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html
>
> - Medium term:
> Have a way to pass in marshalling configurations per cache manager
> and per-cache (or an abstraction of it), which allows the right
> class resolver to be passed in. (***)
> https://issues.jboss.org/browse/ISPN-1367
>
> - Long term:
> https://issues.jboss.org/browse/ISPN-1413
>
> (***) I still don't fully understand how web apps don't have the same
> issue as 2LC of not seeing Infinispan classes (Reminder: we're not
> talking about the contents of the cache, but about the Infinispan
> classes themselves).
To reiterate: in the case of web sessions, the cache instance for an application is associated with the classloader of the org.jboss.as.clustering.web.infinispan module. The AS clustering code shields Infinispan from direct interaction with application objects by storing sessions as MarshalledValues which are eagerly marshalled into byte[] and lazily unmarshalled using an application-specific MarshallingConfiguration.
This has been the case since AS5, if not earlier (albeit using JBoss Serialization + JBoss Cache + TCCL manipulation).
> On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
>
> >
> > On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
> >
> >> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
> >>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
> >>> </snip>
> >>>> To work around this, we typically store MarshalledValues in the
> >>>> cache - which are marshalled/unmarshalled using a marshalling
> >>>> configuration specific to the application (e.g. via a
> >>>> ModularClassResolver using the ModuleLoader of the deployment
> >>>> unit).
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> >>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> >>>
> >>> Isn't a class resolver and a class loader, functionality wise,
> >>> doing the same thing? I wonder if a custom classloader could not
> >>> be built that delegates to a ModularClassResolver...
> >>
> >> No, not really. A class loader loads a class, given a name. But
> >> a
> >> class resolver loads a class given a name *and* stream
> >> information. The
> >> modular class resolver reads the stream information to know which
> >> class
> >> loader houses the class in question. This is critically important
> >> because it's possible (common even) for more than one class to
> >> exist in
> >> an AS instance with the same name. And there is no single class
> >> loader
> >> which has visibility to all classes which could potentially be
> >> stored in
> >> a cache.
> >>
> >> Yes, accepting a class loader to use is a powerful feature.
> >> However it
> >> *should* just be a convenience abstraction over a more fundamental
> >> feature which allows a class resolver to be set.
> >
> > Thanks for the clarification, makes sense.
> >
> > So, if I understand this correctly, Infinispan should really be
> > enhanced to accept global and per-cache class resolvers, or more
> > globally, as paul suggested below, marshalling configuration
> > instances (or abstractions of them).
> >
> > I think https://issues.jboss.org/browse/ISPN-1367 should be
> > reporpoused to do this.
> >
> >>
> >>>> So, essentially Infinispan itself only ever has to
> >>>> marshal/unmarshal a byte[] wrapper - so the AS has full control
> >>>> over the marshalling process.
> >>>>
> >>>> I would recommend that the 2LC do something similar, and include
> >>>> a mechanism for providing a MarshallingConfiguration per
> >>>> persistence unit.
> >>>
> >>> Possibly…
> >>>
> >>> --
> >>> Galder Zamarreño
> >>> Sr. Software Engineer
> >>> Infinispan, JBoss Cache
> >>>
> >>
> >>
> >> --
> >> - DML
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > --
> > Galder Zamarreño
> > Sr. Software Engineer
> > Infinispan, JBoss Cache
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
12 years, 9 months
Queries executed with bidirectional @OneToOnes
by Guillaume Smet
Hi,
It's not something new as we checked that it was already the case with
Hibernate 3.6 but we just hit an annoying problem with @OneToOne
annotation if the relation is bidirectional.
Simplified example:
class A {
@OneToOne(cascade = CascadeType.ALL, orphanRemoval = true)
private B b;
}
class B {
@OneToOne(mappedBy = "b")
private A a;
}
If we insert 1 object in each table and we try to list the objects of
A, the following queries are executed:
1. select a0_.id as id55_, a0_.b_id as b2_55_ from A a0_
2. select b0_.id as id54_1_, a1_.id as id55_0_, a1_.b_id as b2_55_0_
from B b0_ left outer join A a1_ on b0_.id=a1_.b_id where b0_.id=1
3. select a0_.id as id55_1_, a0_.b_id as b2_55_1_, b1_.id as id54_0_
from A a0_ left outer join B b1_ on a0_.b_id=b1_.id where a0_.b_id=1
I don't understand the need for the third query. And this query
quickly becomes a problem as it's executed for each EAGER @OneToOne
relationship of A.
In our application, we have a lot of @OneToOne relationships on an
entity and a variant of the third query (which is big as the entity is
big and the third query tries to populate all the EAGER relations) is
executed for each @OneToOne of the base entity.
I can provide more information if needed. I don't know if it's a
limitation or a bug, that's why I haven't created a JIRA issue yet but
I find this behaviour really suboptimal.
As a temporary workaround, we made the @OneToOne relations
unidirectional which makes our application usable again.
Any pointers on where the problem could be or a confirmation that it's
something expected?
Thanks.
--
Guillaume
12 years, 9 months
Hibernate JPA modelgen issue with @Embedded and @OneToOne
by Guillaume Smet
Hi,
Yesterday, we tried the following mapping:
EntityA {
@Embedded
private EntityB entityB;
}
EntityB {
@OneToOne
private EntityC entityC;
}
In this configuration, and only with a @OneToOne, Hibernate JPA
Modelgen doesn't generate the attribute for entityC in EntityB_ (the
rest of our mapping is correctly generated, simple attributes,
@ManyToMany..., we only have this problem with all our @OneToOne
attributes in our @Embeddable entities).
I don't know if it's something obvious/not supported or if we should
find some time to work on a test case. Ping me if we should.
Thanks for the feedback and have a nice day.
--
Guillaume
12 years, 9 months
Re: [hibernate-dev] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by David M. Lloyd
On 03/06/2012 01:27 PM, Galder Zamarreño wrote:
> (***) I still don't fully understand how web apps don't have the same issue as 2LC of not seeing Infinispan classes (Reminder: we're not talking about the contents of the cache, but about the Infinispan classes themselves).
It's possible that someone saw the exception and said to themselves,
"oh... well I'll just add Infinispan to all web apps", and then the
patch slipped by the code review process. Other problems will continue
to lurk beneath the surface though.
--
- DML
12 years, 9 months
Re: [hibernate-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Paul Ferraro
----- Original Message -----
> From: "Galder Zamarreño" <galder(a)redhat.com>
> To: "Paul Ferraro" <paul.ferraro(a)redhat.com>
> Cc: "Jason T. Greene" <jason.greene(a)redhat.com>, "Bela Ban" <bban(a)redhat.com>, "infinispan -Dev List"
> <infinispan-dev(a)lists.jboss.org>, hibernate-dev(a)lists.jboss.org, "jboss-as7-dev(a)lists.jboss.org Development"
> <jboss-as7-dev(a)lists.jboss.org>, "David M. Lloyd" <david.lloyd(a)redhat.com>
> Sent: Tuesday, March 6, 2012 2:02:44 PM
> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
>
>
> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
>
> > ----- Original Message -----
> >> From: "Jason T. Greene" <jason.greene(a)redhat.com>
> >> To: "David M. Lloyd" <david.lloyd(a)redhat.com>
> >> Cc: "Galder Zamarreño" <galder(a)redhat.com>, "Paul Ferraro"
> >> <pferraro(a)redhat.com>, "Bela Ban" <bban(a)redhat.com>,
> >> "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>,
> >> hibernate-dev(a)lists.jboss.org,
> >> "jboss-as7-dev(a)lists.jboss.org Development"
> >> <jboss-as7-dev(a)lists.jboss.org>
> >> Sent: Tuesday, March 6, 2012 10:30:11 AM
> >> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan
> >> dependency for clustered JPA second level cache
> >>
> >> On 3/6/12 9:28 AM, David M. Lloyd wrote:
> >>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
> >>>> This reminds me that we had a discussion about this a few months
> >>>> back: http://goo.gl/DJLhB
> >>>>
> >>>> At the time, it wasn't clear whether you can use
> >>>> ModularClassResolver in a non-module env. Seems like it's not
> >>>> possible.
> >>>>
> >>>> So, one option is to have a class resolver lookup class, or
> >>>> similar so that AS7 can pass us the right ClassResolver.
> >>>>
> >>>> There might a quicker option here though:
> >>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and
> >>>> provide
> >>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
> >>>> (this requires JBossMarshaller to be made non-final)
> >>>> - Override JBossMarshaller.inject(), call super.inject() and
> >>>> then
> >>>> call baseCfg.setClassResolver(…)
> >>>> - This would require that the VersionAwareMarshaller extension
> >>>> be
> >>>> passed the ModuleLoader that ModularClassResolver requires.
> >>>> - Configure Infinispan with this new marshaller, via
> >>>> SerializationConfiguration. Thankfully you can now pass an
> >>>> instance of the marshaller to it, so no need to do any magic
> >>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
> >>>>
> >>>> Scott, other than the change in JBossMarshaller to be made
> >>>> non-final, the rest can built on AS7. Wanna have a go? Ping me
> >>>> on
> >>>> IRC if you need help.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> p.s. Silly question, how come this issue is not present in HTTP
> >>>> session replication use case or EJB3 SFSB?
> >>>
> >>> It actually is present anywhere we're using Infinispan (I think).
> >>> It
> >>> just hasn't blown up yet anywhere public (in this case it's a 90%
> >>> effective solution versus a 100% effective solution).
> >>
> >> Session replication does setup a custom marshaller, so it does in
> >> fact
> >> work. I think the issue is just that the hibernate-infinispan,
> >> which
> >> is
> >> part of the hibernate project set, and not AS code does not do
> >> this,
> >> and
> >> it doesn't expose a way to do it.
> >
> > Sort of...
> >
> > To summarize:
> > The fundamental issue is that Infinispan uses the same marshaller
> > instance for all caches within a cache manager - which doesn't map
> > cleanly to our use case, which uses a cache instance per
> > application - thus requires cache-grained marshalling
> > configuration.
>
> Well, this is not exactly correct since 5.0. Internally, we
> differentiate between a global marshaller and a per-cache
> marshaller. What's the difference? The classloader with which
> they're configured.
Yes - but there's a difference between supplying a classloader per cache and providing a custom marshaller per cache.
> Since 5.0, you can configure the classloader to use per cache. You
> can even configure the classloader per invocation with
> cache.with(cl)….
And we use both of these. The ClassLoader supplied to the CacheConfiguration is used to resolve configuration classes (e.g. cache stores). The AS7 2LC region factory implementations (which extend hibernate-infinispan) currently use the ClassLoader per invocation to resolve entity/PK objects - but this is too restrictive, since the Infinispan's marshaller needs to know about more classes than are available to the application class loader (hence this discussion), and even that is still not without issues (e.g. ISPN-1220).
> If that's not helping you, we were wasting our time when we did
> this...
I disagree. Allowing a user to supply a classloader to a cache/invocation is incredibly useful.
> > To work around this, we typically store MarshalledValues in the
> > cache - which are marshalled/unmarshalled using a marshalling
> > configuration specific to the application (e.g. via a
> > ModularClassResolver using the ModuleLoader of the deployment
> > unit).
> > https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> > https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
> > https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>
> Isn't a class resolver and a class loader, functionality wise, doing
> the same thing? I wonder if a custom classloader could not be built
> that delegates to a ModularClassResolver...
Functionally, yes, but technically, no. The ModularClassResolver resolves classes using the class name and the name of its module, whereas a ClassLoader resolves classes using just the class name.
> > So, essentially Infinispan itself only ever has to
> > marshal/unmarshal a byte[] wrapper - so the AS has full control
> > over the marshalling process.
> >
> > I would recommend that the 2LC do something similar, and include a
> > mechanism for providing a MarshallingConfiguration per persistence
> > unit.
>
> Possibly…
Apart from possibly adding MarshallingConfiguraion hooks to infinispan-core, what other solution do you have in mind?
Paul
12 years, 9 months
