Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing
Guillaume, thanks for the suggestion. I'll give it a try...
On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet
wrote:
> I would try changing the start of EnhancerImpl#enhance() to:
> ===
> public byte[] enhance(String className, byte[] originalBytes) throws
> EnhancementException {
> //Classpool#describe does not accept '/' in the description name as
> it expects a class name. See HHH-12545
> final String safeClassName = className.replace( '/', '.' );
> try {
> final Resolution typeResolution = typePool.describe(
> safeClassName );
> if ( !typeResolution.isResolved() ) {
> return null;
> }
>
> final TypeDescription typeDescription =
> typeResolution.resolve();
> ===
>
> i.e. testing the resolution of the type.
>
> That might fix it.
>
> --
> Guillaume
>
> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow wrote:
>
> > Thinking more about this, I don't think that ByteBuddy should be able to
> > do a classloader.getResource() on the class that is being defined
> > (SLSBPersistenceContexts$$$view5.class). It might be correct for the
> > getResource call to return null, until after the class is completely
> > defined.
> >
> > Would it make sense for the above condition (cl.getResource() returning
> > null) be detected differently in the callstack [1] and just fall through
> > + return to the caller?
> >
> > Scott
> >
> > [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
> >
> > On 3/26/19 9:53 AM, Scott Marlow wrote:
> > > Hi Tomek,
> > >
> > > I think the pending question now is why ByteBuddy is getting a null
> > > result from the
> > >
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
> >
> > > call.
> > >
> > > We have also seen failures for
> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which
> is
> > > also generated by the EJB container (see exception call stack in
> > > https://issues.jboss.org/browse/WFLY-11891).
> > >
> > > I wonder if this could be an ordering bug where classes generated via
> > > JBoss ClassFileWriter are added to the classloader list of classes,
> > > before the actual bytecode is added.
> > >
> > > Scott
> > >
> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote:
> > >> Hi Scott,
> > >>
> > >> Added to my TODO. WIll try to look at it this week.
> > >>
> > >> Regards,
> > >> Tomek
> > >>
> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > >> > wrote:
> > >>
> > >> Adding Tomek + Cheng, as they have been working on the WildFly EJB
> > >> layer
> > >> recently, which seems to use
> > >> https://github.com/jbossas/jboss-classfilewriter for generating
> > >> the EJB
> > >> stub classes like
> > >>
> > >>
> >
> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
> >
> > >>
> > >>
> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
> > >> ByteBuddy should change to handle dynamically generated classes
> > >> differently.
> > >>
> > >> In other words, should ByteBuddy respond differently to
> > >>
> > >>
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
> >
> > >>
> > >>
> > >> returning null or should the jboss-classfilewriter project somehow
> > >> avoid
> > >> this bug.
> > >>
> > >> Scott
> > >>
> > >> On 3/22/19 2:54 AM, Gail Badner wrote:
> > >> > Scott added bytecode enhancement to some WildFly tests for
> > >> WFLY-11891 [1],
> > >> > which are failing.
> > >> >
> > >> > Here is Scott's PR with the updated tests: [2]
> > >> >
> > >> > When I stepped into
> > >> >
> > >>
> > >>
> >
> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
> >
> > >>
> > >> > I can see that they are failing in ByteBuddy code.
> > >> >
> > >> > I see that:
> > >> >
> > >> > - enhancement of
> > >> >
> > >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
> > >> > skipped several times in a row;
> > >> > - enhancement of some other classes get skipped;
> > >> > - before trying to enhance
> > >> >
> > >>
> > org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5,
> > >> an
> > >> > exception is thrown.
> > >> >
> > >> > Unfortunately, I'm having trouble getting a good stacktrace to
> > >> show what
> > >> > happens in ByteBuddy code.
> > >> >
> > >> > Here is what I'm seeing:
> > >> >
> > >> >
> > >>
> > >>
> >
> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
> >
> > >>
> > >> > /* class name differs from run to run */
> > >> >
> > >> >
> > >> > calls
> > >>
Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing
I would try changing the start of EnhancerImpl#enhance() to:
===
public byte[] enhance(String className, byte[] originalBytes) throws
EnhancementException {
//Classpool#describe does not accept '/' in the description name as
it expects a class name. See HHH-12545
final String safeClassName = className.replace( '/', '.' );
try {
final Resolution typeResolution = typePool.describe(
safeClassName );
if ( !typeResolution.isResolved() ) {
return null;
}
final TypeDescription typeDescription =
typeResolution.resolve();
===
i.e. testing the resolution of the type.
That might fix it.
--
Guillaume
On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow wrote:
> Thinking more about this, I don't think that ByteBuddy should be able to
> do a classloader.getResource() on the class that is being defined
> (SLSBPersistenceContexts$$$view5.class). It might be correct for the
> getResource call to return null, until after the class is completely
> defined.
>
> Would it make sense for the above condition (cl.getResource() returning
> null) be detected differently in the callstack [1] and just fall through
> + return to the caller?
>
> Scott
>
> [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
>
> On 3/26/19 9:53 AM, Scott Marlow wrote:
> > Hi Tomek,
> >
> > I think the pending question now is why ByteBuddy is getting a null
> > result from the
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> > call.
> >
> > We have also seen failures for
> > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is
> > also generated by the EJB container (see exception call stack in
> > https://issues.jboss.org/browse/WFLY-11891).
> >
> > I wonder if this could be an ordering bug where classes generated via
> > JBoss ClassFileWriter are added to the classloader list of classes,
> > before the actual bytecode is added.
> >
> > Scott
> >
> > On 3/26/19 9:17 AM, Tomasz Adamski wrote:
> >> Hi Scott,
> >>
> >> Added to my TODO. WIll try to look at it this week.
> >>
> >> Regards,
> >> Tomek
> >>
> >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow >> > wrote:
> >>
> >> Adding Tomek + Cheng, as they have been working on the WildFly EJB
> >> layer
> >> recently, which seems to use
> >> https://github.com/jbossas/jboss-classfilewriter for generating
> >> the EJB
> >> stub classes like
> >>
> >>
> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
>
> >>
> >>
> >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
> >> ByteBuddy should change to handle dynamically generated classes
> >> differently.
> >>
> >> In other words, should ByteBuddy respond differently to
> >>
> >>
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> >>
> >>
> >> returning null or should the jboss-classfilewriter project somehow
> >> avoid
> >> this bug.
> >>
> >> Scott
> >>
> >> On 3/22/19 2:54 AM, Gail Badner wrote:
> >> > Scott added bytecode enhancement to some WildFly tests for
> >> WFLY-11891 [1],
> >> > which are failing.
> >> >
> >> > Here is Scott's PR with the updated tests: [2]
> >> >
> >> > When I stepped into
> >> >
> >>
> >>
> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
>
> >>
> >> > I can see that they are failing in ByteBuddy code.
> >> >
> >> > I see that:
> >> >
> >> > - enhancement of
> >> >
> >> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
> >> > skipped several times in a row;
> >> > - enhancement of some other classes get skipped;
> >> > - before trying to enhance
> >> >
> >>
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5,
> >> an
> >> > exception is thrown.
> >> >
> >> > Unfortunately, I'm having trouble getting a good stacktrace to
> >> show what
> >> > happens in ByteBuddy code.
> >> >
> >> > Here is what I'm seeing:
> >> >
> >> >
> >>
> >>
> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
>
> >>
> >> > /* class name differs from run to run */
> >> >
> >> >
> >> > calls
> >> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( "
> >> >
> >>
> >>
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
> >> >
> >> > calls
> >> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate(
> >> > classLoader,
> >>
> >>
> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5"
> >> > )
> >> >
> >> > calls
> >> >
> >>
> >>
>
Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing
Thinking more about this, I don't think that ByteBuddy should be able to
do a classloader.getResource() on the class that is being defined
(SLSBPersistenceContexts$$$view5.class). It might be correct for the
getResource call to return null, until after the class is completely
defined.
Would it make sense for the above condition (cl.getResource() returning
null) be detected differently in the callstack [1] and just fall through
+ return to the caller?
Scott
[1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
On 3/26/19 9:53 AM, Scott Marlow wrote:
> Hi Tomek,
>
> I think the pending question now is why ByteBuddy is getting a null
> result from the
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> call.
>
> We have also seen failures for
> org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is
> also generated by the EJB container (see exception call stack in
> https://issues.jboss.org/browse/WFLY-11891).
>
> I wonder if this could be an ordering bug where classes generated via
> JBoss ClassFileWriter are added to the classloader list of classes,
> before the actual bytecode is added.
>
> Scott
>
> On 3/26/19 9:17 AM, Tomasz Adamski wrote:
>> Hi Scott,
>>
>> Added to my TODO. WIll try to look at it this week.
>>
>> Regards,
>> Tomek
>>
>> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > > wrote:
>>
>> Adding Tomek + Cheng, as they have been working on the WildFly EJB
>> layer
>> recently, which seems to use
>> https://github.com/jbossas/jboss-classfilewriter for generating
>> the EJB
>> stub classes like
>>
>> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
>>
>>
>>
>> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
>> ByteBuddy should change to handle dynamically generated classes
>> differently.
>>
>> In other words, should ByteBuddy respond differently to
>>
>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>>
>>
>>
>> returning null or should the jboss-classfilewriter project somehow
>> avoid
>> this bug.
>>
>> Scott
>>
>> On 3/22/19 2:54 AM, Gail Badner wrote:
>> > Scott added bytecode enhancement to some WildFly tests for
>> WFLY-11891 [1],
>> > which are failing.
>> >
>> > Here is Scott's PR with the updated tests: [2]
>> >
>> > When I stepped into
>> >
>>
>> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
>>
>>
>> > I can see that they are failing in ByteBuddy code.
>> >
>> > I see that:
>> >
>> > - enhancement of
>> >
>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
>> > skipped several times in a row;
>> > - enhancement of some other classes get skipped;
>> > - before trying to enhance
>> >
>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5,
>> an
>> > exception is thrown.
>> >
>> > Unfortunately, I'm having trouble getting a good stacktrace to
>> show what
>> > happens in ByteBuddy code.
>> >
>> > Here is what I'm seeing:
>> >
>> >
>>
>> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
>>
>>
>> > /* class name differs from run to run */
>> >
>> >
>> > calls
>> net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( "
>> >
>>
>> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
>> >
>> > calls
>> net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate(
>> > classLoader,
>>
>> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5"
>> > )
>> >
>> > calls
>> >
>>
>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"),
>>
>>
>> > which returns null;
>> >
>> > (I don't actually see a class file with this name)
>> >
>> >
>> > returns new TypePool.Resolution.Illegal(
>> >
>> >
>>
>> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"
>>
>>
>> >
>> > )
>> >
>> > returns TypePool.Resolution.Illegal
>> >
>> >
>> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws
>> > IllegalStateException, because the type description cannot be
>> resolved.
>> >
>> > I'm not sure if the problem is in WildFly, Hibernate, or
>> ByteBuddy.
>> >
>> > To build WildFly:
>> > ./build.sh clean install -DskipTests=true
>> >
>> > To run the test:
>> > cd testsuite/integration/basic
>> > mvn install
Re: [hibernate-dev] 6.0 - multi-table mutations
On Tue, Mar 26, 2019 at 10:17 AM Sanne Grinovero wrote: > > Why should we not? > There is a very compelling reason for that. I'll have to leave it at that. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - multi-table mutations
On Tue, 26 Mar 2019 at 15:08, Steve Ebersole wrote: > > On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote: >> >> One question: could we benefit from "cascade delete" rules defined in >> the table structure? >> >> >> If Hibernate ORM was able parse the cascading rules from existing >> schemas, and possibly generate them for new schemas, you could have an >> entire crop of additional such optimisations. I'm not sure if I'm >> talking about material for ORM 7+ but if you could make sure that such >> future optimisations aren't ruled out that would be awesome :) > > > Good point. > > We actually do already have some limited support for cascading FKs in ORM - > `org.hibernate.annotations.OnDelete`. And it is exported to the database if > defined. We do not (nor should we) parse this information from the existing > schema. Why should we not? > > What you are asking about specifically would require us to round out that > support (secondary tables at least are not yet supported) and of course to > leverage that in the HQL bulk deletion handlers. Not impossible or even > particularly difficult - but enough work that I'd rather that be handled > somewhere post-6.0 +1 fair enough ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - multi-table mutations
On Tue, Mar 26, 2019 at 9:57 AM Sanne Grinovero wrote: > One question: could we benefit from "cascade delete" rules defined in > the table structure? > If Hibernate ORM was able parse the cascading rules from existing > schemas, and possibly generate them for new schemas, you could have an > entire crop of additional such optimisations. I'm not sure if I'm > talking about material for ORM 7+ but if you could make sure that such > future optimisations aren't ruled out that would be awesome :) > Good point. We actually do already have some limited support for cascading FKs in ORM - `org.hibernate.annotations.OnDelete`. And it is exported to the database if defined. We do not (nor should we) parse this information from the existing schema. What you are asking about specifically would require us to round out that support (secondary tables at least are not yet supported) and of course to leverage that in the HQL bulk deletion handlers. Not impossible or even particularly difficult - but enough work that I'd rather that be handled somewhere post-6.0 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - multi-table mutations
Hi Steve, this does sound amazing, I think it's certainly worth trying to have the most efficient strategy chosen on a per-entity base. One question: could we benefit from "cascade delete" rules defined in the table structure? If Hibernate ORM was able parse the cascading rules from existing schemas, and possibly generate them for new schemas, you could have an entire crop of additional such optimisations. I'm not sure if I'm talking about material for ORM 7+ but if you could make sure that such future optimisations aren't ruled out that would be awesome :) Thanks, Sanne On Tue, 26 Mar 2019 at 13:25, Steve Ebersole wrote: > > While working on 6 I discovered that we maybe do not do the best job in > regards to "bulk update/delete" queries against multi-table entities > (secondary tables, joined inheritance, etc). This short-coming exists in > previous versions. Essentially, when a strategy is not explicitly > specified we fallback to using an "id table" and performing the SQL updates > or deletes using the id table as a sub-query. The problem is that for some > databases this breaks when the ids are composite due to the database not > having complete support for tuples. For example, H2 does not allow the > sub-query for an in-predicate to return more than one column: so a query > like `... where (id1, id2) in (select val1, val2 from ...)` will not work. > This tuple concern is something I had not considered when I first wrote > this feature. > > Obviously with 6 we have a chance to improve this. So I have been thinking > about some ways this might be improved. The guiding principle here was to > make this as implicit as possible... > > Because certain strategies will not work when the ids are composite, I > think the first consideration is whether we want to allow the strategy to > be definable per-entity. The idea would be to allow for the most efficient > strategy to be used generally (whatever that might be for the given > app/database) but to pick an alternative strategy in cases where that > "fallback" one will not work. The Dialect should certainly play a part in > this strategy selection. > > And lastly, we should consider whether it is beneficial to leverage these > strategies when performing normal mutations (merge, persist, etc). I think > really this comes down to whether we think there is a benefit to handling > these via CTE if the database supports that as opposed to sending > individual updates or deletes against each table. > > Thoughts? > ___ > 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] NoORM IRC meeting minutes
Hi, Here are the minutes of our NoORM IRC meeting: 15:36 < jbott> Meeting ended Tue Mar 26 14:36:05 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:36 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-26-14.01.html 15:36 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-26-14.01.txt 15:36 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2019/hibernate-dev.2019-03-26-14.01.log.html 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] 6.0 - multi-table mutations
https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/6.2E0.20-.20multi-table.20mutation On Tue, Mar 26, 2019 at 8:25 AM Steve Ebersole wrote: > While working on 6 I discovered that we maybe do not do the best job in > regards to "bulk update/delete" queries against multi-table entities > (secondary tables, joined inheritance, etc). This short-coming exists in > previous versions. Essentially, when a strategy is not explicitly > specified we fallback to using an "id table" and performing the SQL updates > or deletes using the id table as a sub-query. The problem is that for some > databases this breaks when the ids are composite due to the database not > having complete support for tuples. For example, H2 does not allow the > sub-query for an in-predicate to return more than one column: so a query > like `... where (id1, id2) in (select val1, val2 from ...)` will not work. > This tuple concern is something I had not considered when I first wrote > this feature. > > Obviously with 6 we have a chance to improve this. So I have been > thinking about some ways this might be improved. The guiding principle > here was to make this as implicit as possible... > > Because certain strategies will not work when the ids are composite, I > think the first consideration is whether we want to allow the strategy to > be definable per-entity. The idea would be to allow for the most efficient > strategy to be used generally (whatever that might be for the given > app/database) but to pick an alternative strategy in cases where that > "fallback" one will not work. The Dialect should certainly play a part in > this strategy selection. > > And lastly, we should consider whether it is beneficial to leverage these > strategies when performing normal mutations (merge, persist, etc). I think > really this comes down to whether we think there is a benefit to handling > these via CTE if the database supports that as opposed to sending > individual updates or deletes against each table. > > Thoughts? > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing
Hi Tomek,
I think the pending question now is why ByteBuddy is getting a null
result from the
classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
call.
We have also seen failures for
org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is
also generated by the EJB container (see exception call stack in
https://issues.jboss.org/browse/WFLY-11891).
I wonder if this could be an ordering bug where classes generated via
JBoss ClassFileWriter are added to the classloader list of classes,
before the actual bytecode is added.
Scott
On 3/26/19 9:17 AM, Tomasz Adamski wrote:
> Hi Scott,
>
> Added to my TODO. WIll try to look at it this week.
>
> Regards,
> Tomek
>
> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > wrote:
>
> Adding Tomek + Cheng, as they have been working on the WildFly EJB
> layer
> recently, which seems to use
> https://github.com/jbossas/jboss-classfilewriter for generating the EJB
> stub classes like
>
> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
>
> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
> ByteBuddy should change to handle dynamically generated classes
> differently.
>
> In other words, should ByteBuddy respond differently to
>
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> returning null or should the jboss-classfilewriter project somehow
> avoid
> this bug.
>
> Scott
>
> On 3/22/19 2:54 AM, Gail Badner wrote:
> > Scott added bytecode enhancement to some WildFly tests for
> WFLY-11891 [1],
> > which are failing.
> >
> > Here is Scott's PR with the updated tests: [2]
> >
> > When I stepped into
> >
>
> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
> > I can see that they are failing in ByteBuddy code.
> >
> > I see that:
> >
> > - enhancement of
> >
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
> > skipped several times in a row;
> > - enhancement of some other classes get skipped;
> > - before trying to enhance
> >
>
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an
> > exception is thrown.
> >
> > Unfortunately, I'm having trouble getting a good stacktrace to
> show what
> > happens in ByteBuddy code.
> >
> > Here is what I'm seeing:
> >
> >
>
> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
> > /* class name differs from run to run */
> >
> >
> > calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( "
> >
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
> >
> > calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate(
> > classLoader,
> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5"
> > )
> >
> > calls
> >
>
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"),
> > which returns null;
> >
> > (I don't actually see a class file with this name)
> >
> >
> > returns new TypePool.Resolution.Illegal(
> >
> >
>
> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"
> >
> > )
> >
> > returns TypePool.Resolution.Illegal
> >
> >
> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws
> > IllegalStateException, because the type description cannot be
> resolved.
> >
> > I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy.
> >
> > To build WildFly:
> > ./build.sh clean install -DskipTests=true
> >
> > To run the test:
> > cd testsuite/integration/basic
> > mvn install
> >
>
> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase
> >
> > Help would be very much appreciated.
> >
> > Thanks,
> > Gail
> >
> > [1] https://issues.jboss.org/browse/WFLY-11891
> > [2] https://github.com/wildfly/wildfly/pull/12180
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
>
> --
> Regards,
> Tomek
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] 6.0 - multi-table mutations
While working on 6 I discovered that we maybe do not do the best job in regards to "bulk update/delete" queries against multi-table entities (secondary tables, joined inheritance, etc). This short-coming exists in previous versions. Essentially, when a strategy is not explicitly specified we fallback to using an "id table" and performing the SQL updates or deletes using the id table as a sub-query. The problem is that for some databases this breaks when the ids are composite due to the database not having complete support for tuples. For example, H2 does not allow the sub-query for an in-predicate to return more than one column: so a query like `... where (id1, id2) in (select val1, val2 from ...)` will not work. This tuple concern is something I had not considered when I first wrote this feature. Obviously with 6 we have a chance to improve this. So I have been thinking about some ways this might be improved. The guiding principle here was to make this as implicit as possible... Because certain strategies will not work when the ids are composite, I think the first consideration is whether we want to allow the strategy to be definable per-entity. The idea would be to allow for the most efficient strategy to be used generally (whatever that might be for the given app/database) but to pick an alternative strategy in cases where that "fallback" one will not work. The Dialect should certainly play a part in this strategy selection. And lastly, we should consider whether it is beneficial to leverage these strategies when performing normal mutations (merge, persist, etc). I think really this comes down to whether we think there is a benefit to handling these via CTE if the database supports that as opposed to sending individual updates or deletes against each table. Thoughts? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
