Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
Hi Steve,
the test project that I created still fails with the latest SNAPSHOT
release, although the foreign keys are not created. Can you please
investigate if that is related to the same issue. The test repository is
here:
https://github.com/paranoiabla/HHH-8805
2015-04-03 16:15 GMT+03:00 Emmanuel Bernard :
> Steve, I think there is something fishy.
> I have created a branch with a blatant usage of a JDK 8 API in
> hibernate-core
> There is one commit above today’s master:
>
> protected EmptyInterceptor() {
> + final java.time.ZoneId id =
> java.time.ZoneId.systemDefault();
> + System.out.println( id.getId() );
> }
>
> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer <
> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer>
>
> And when I run ./gradlew clean build
> things do pass, i.e. Animal Sniffer is either not executed or it does not
> make the build fail. I did not see any Animal Sniffer reference in the
> console while it was running.
>
> Does it do the same for you if you clone my branch?
>
> Emmanuel
>
> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of Mac
> on FindBug executions ;)
>
> > On 01 Apr 2015, at 18:09, Steve Ebersole wrote:
> >
> > I'm not going to argue with you man. AnimalSniffer *is* run. If you
> don't
> > believe that and don't want to verify it for yourself, oh well, nothing I
> > can do about that...
> >
> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling
> wrote:
> >
> >> Hum, you are not April-fooling me, right ;)
> >>
> >> There is something Java-8-specific in already: the usage of
> >> ConcurrentHashMap#keySet() (in
> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when compiled
> on
> >> Java 8 - adds a reference to the Java-8-only type KeySetView to the
> class
> >> file of SessionFactoryImpl. That's the issue pointed out by Petar
> >> originally.
> >>
> >> But when running "./gradlew build" on the current master, the build
> >> passes. I would expect it to fail though, as AnimalSniffer should detect
> >> that usage of Java 8's KeySetView class. So I don't see that AS is
> executed
> >> actually? Or are you saying it is run but it's findings don't cause the
> >> build to fail?
> >>
> >> If I go back to the original approach of using AS (via git checkout
> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due to
> that
> >> reference from SessionFactoryImpl#iterateEntityNameResolvers().
> >>
> >> Do you actually see the build on master fail due to that reference being
> >> discovered by AS?
> >>
> >>
> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole :
> >>
> >>> Gunnar, it is applied. Add something that is java 8 specific and
> see...
> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" wrote:
> >>>
> I saw the plug-in, Steve. But how/when is it executed?
>
> Running "./gradlew build" used to execute AnimalSniffer and would have
> revealed that accidental usage of KeySetView. That's not the case
> anymore.
> It would be nice if that new plug-in could be applied automatically
> after
> compileJava as it used to be the case with the Ant-based approach.
>
>
> 2015-04-01 13:48 GMT+02:00 Steve Ebersole :
>
> > Increase your Gradle-fu we must young apprentice :)
> >
> > AnimalSniffer is still run. I simply converted it to be a plugin.
> > Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in
> ORM's
> > /buildSrc project
> >
> > AnimalSniffer will apparently not detect this :)
> >
> > On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling >
> > wrote:
> >
> >>> Currently, AnimalSniffer is in place to prevent this very category
> >> of error and I'm wondering why it didn't detect the "usage" of
> KeySetView.
> >>
> >> Looked at this a bit closer. Turns out, AnimalSniffer *will* detect
> >> this issue if it actually is run. The problem is that AS apparently
> is
> >> not executed by default anymore, due to the recent change to how AS
> is used
> >> [1].
> >>
> >> Prior to that change, running AS was done automatically after the
> compileJava
> >> task and would have reported that usage of KeySetView:
> >>
> >>Undefined reference:
> >>
> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
> >> in
> >>
> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class
> >>
> >> Unfortunately my Gradle Foo is rather limited, so I'm not sure how
> to
> >> re-establish that behaviour with the new AS plug-in.
> >>
> >> --Gunnar
> >>
> >> [1]
> >>
> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb69d9595004ec4e462f
> >>
> >>
> >>
> >>
> >> 2015-04-01 9:39 GMT+02:00 Gunnar Morling :
> >>
> >>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
On Thu, Apr 2, 2015 at 6:54 PM, Petar Tahchiev wrote: > Hi Steve, > > I just pulled and did ./gradlew install. Unfortunately this didn't install > the jars in my local maven repo because the maven plugin declaration was > missing (you might want to consider adding it). > That's because the task is not called install. Install is Maven terminlology, our build used Gradle. The task you want is called publishToMavenLocal. And no, I'd prefer to not add that plugin. I moved away from Maven for a reason (well, ok, several) and prefer the Gradle terminology. The idea of "installing" my artifacts is such a logical misnomer. > Anyways, after I added it the jars were installed in my repo. I ran schema > export and the schema result was missing the foreign keys - great!!! > However when I ran my tests against HSQL (my tests are using > hibernate.ddl-auto=update to create the tables) I got an exception: > SchemaMigratorImpl.java:128 is trying to get your table metadata from the driver, but not finding any table information. I'd need a test (simplified this time please) that illustrates the problem. Or else you can debug into it. What table? What is special about that table versus other tables it finds before? Or does it not find any tables before? Etc... ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
I see you have a test repository reproducing the error. I will try to run
from there.
On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev
wrote:
> Hi Steve,
>
> the test project that I created still fails with the latest SNAPSHOT
> release, although the foreign keys are not created. Can you please
> investigate if that is related to the same issue. The test repository is
> here:
>
> https://github.com/paranoiabla/HHH-8805
>
>
> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard :
>
>> Steve, I think there is something fishy.
>> I have created a branch with a blatant usage of a JDK 8 API in
>> hibernate-core
>> There is one commit above today’s master:
>>
>> protected EmptyInterceptor() {
>> + final java.time.ZoneId id =
>> java.time.ZoneId.systemDefault();
>> + System.out.println( id.getId() );
>> }
>>
>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer <
>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer>
>>
>>
>> And when I run ./gradlew clean build
>> things do pass, i.e. Animal Sniffer is either not executed or it does not
>> make the build fail. I did not see any Animal Sniffer reference in the
>> console while it was running.
>>
>> Does it do the same for you if you clone my branch?
>>
>> Emmanuel
>>
>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of Mac
>> on FindBug executions ;)
>>
>> > On 01 Apr 2015, at 18:09, Steve Ebersole wrote:
>> >
>> > I'm not going to argue with you man. AnimalSniffer *is* run. If you
>> don't
>> > believe that and don't want to verify it for yourself, oh well, nothing
>> I
>> > can do about that...
>> >
>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling
>> wrote:
>> >
>> >> Hum, you are not April-fooling me, right ;)
>> >>
>> >> There is something Java-8-specific in already: the usage of
>> >> ConcurrentHashMap#keySet() (in
>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when compiled
>> on
>> >> Java 8 - adds a reference to the Java-8-only type KeySetView to the
>> class
>> >> file of SessionFactoryImpl. That's the issue pointed out by Petar
>> >> originally.
>> >>
>> >> But when running "./gradlew build" on the current master, the build
>> >> passes. I would expect it to fail though, as AnimalSniffer should
>> detect
>> >> that usage of Java 8's KeySetView class. So I don't see that AS is
>> executed
>> >> actually? Or are you saying it is run but it's findings don't cause the
>> >> build to fail?
>> >>
>> >> If I go back to the original approach of using AS (via git checkout
>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due to
>> that
>> >> reference from SessionFactoryImpl#iterateEntityNameResolvers().
>> >>
>> >> Do you actually see the build on master fail due to that reference
>> being
>> >> discovered by AS?
>> >>
>> >>
>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole :
>> >>
>> >>> Gunnar, it is applied. Add something that is java 8 specific and
>> see...
>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling"
>> wrote:
>> >>>
>> I saw the plug-in, Steve. But how/when is it executed?
>>
>> Running "./gradlew build" used to execute AnimalSniffer and would
>> have
>> revealed that accidental usage of KeySetView. That's not the case
>> anymore.
>> It would be nice if that new plug-in could be applied automatically
>> after
>> compileJava as it used to be the case with the Ant-based approach.
>>
>>
>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole :
>>
>> > Increase your Gradle-fu we must young apprentice :)
>> >
>> > AnimalSniffer is still run. I simply converted it to be a plugin.
>> > Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in
>> ORM's
>> > /buildSrc project
>> >
>> > AnimalSniffer will apparently not detect this :)
>> >
>> > On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling <
>> gun...@hibernate.org>
>> > wrote:
>> >
>> >>> Currently, AnimalSniffer is in place to prevent this very category
>> >> of error and I'm wondering why it didn't detect the "usage" of
>> KeySetView.
>> >>
>> >> Looked at this a bit closer. Turns out, AnimalSniffer *will* detect
>> >> this issue if it actually is run. The problem is that AS
>> apparently is
>> >> not executed by default anymore, due to the recent change to how
>> AS is used
>> >> [1].
>> >>
>> >> Prior to that change, running AS was done automatically after the
>> compileJava
>> >> task and would have reported that usage of KeySetView:
>> >>
>> >>Undefined reference:
>> >>
>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>> >> in
>> >>
>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class
>> >>
>> >> Unfortunately my Gradle Foo is rather limited, so I'm not sure how
>> to
>> >> re-establish that behaviour
Re: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara wrote: > Steve, > > I have pushed a proposal for HHH-9701 to: > https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701 > > There are a couple of areas that I would appreciate feedback; > > 1) Serialization/Deserialization - EntityEntries implementations can be > serialized and each implementation provide their own serialization method. > I have modified the serialization of EntityEntry in EntityEntryContext to > write the Implementation class to the OutputStream so the correct class can > be used to deserialize the object stream. Is the exception handling > sufficient here, or do we need more robust handling of deserialization > exceptions? : see > https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380 > I added some comments to that section. Also, overall I would extract the deserialization bit into a separate method (deserializeEntityEntry). 2) In our (perf team) use case, we want to be able to share the > ImmutableEntityEntry between sessions when they are referenced cached in > the 2lc. I have modified EntityEntryContext to not null > managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance > of ImmutableEntityEntry. Do we need to add an extra checks here, to ensure > that the entity is Reference Cached? I am not sure how we would test that > case? : see > https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281 > It really depends on what y'all consider the trigger for using ImmutableEntityEntry. When would the EntityPersister use the EntityEntryFactory producing ImmutableEntityEntry instances? a) when the entity is marked immutable? b) when the entity is marked immutable *and* we need to cache it by reference? c) some other condition? I agree that we should only not clear that reference when the entity is enabled for cache-by-reference. How that plays into this depends on the answer to the above question. If (a), then I think that yes it makes sense to add a check to only clear the ManagedEntity's EntityEntry reference if using cache-by-reference. If (b), then the EntiytPersister is only using the EntityEntryFactory producing ImmutableEntityEntry instances when both are true. So the fact that an entry is an instance of ImmutableEntityEntry indicates that we need to not clear it from the ManagedEntity. > 3) Lock Mode: Steve you mentioned about not doing locking for Immutable > entities. Where is the locking implemented? Would it be sufficient to > simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY when > setLockMode is called? > Locking is implemented in many places. What I had in mind, in terms of implementation for EntityEntry, is somewhat influenced by the choice between ignore versus exception in cases where something is not supported. Basically I had thought to throw an exception in ImmutableEntityEntry#setLockMode or to simply ignore the call altogether. This is not a great solution. It is hard for me to justify ignoring the lock request in all cases. What does everyone else think? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
Just a quick follow-up here: SchemaMigratorImpl:125 is calling
existingDatabase.getTableInformation where existingDatabase is of type
org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl
(I have no idea why is it using the legacy one), and If I step into it I
can see it's using a tableInformationMap which is empty - really weird as I
can see before that the hbm2ddl was reporting tables were not found so I
was expecting it to create them:
2015-04-06 09:29:40,608
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
[main] INFO : HHH000262: Table not found: warehouse
2015-04-06 09:29:40,610
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
[main] INFO : HHH000262: Table not found: widget_title_lv
2015-04-06 09:29:40,614
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
[main] INFO : HHH000262: Table not found: wishlist
2015-04-06 09:29:40,618
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
[main] INFO : HHH000262: Table not found: wishlist_entry
2015-04-06 09:29:40,622
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
[main] INFO : HHH000262: Table not found: working_day
I'll try to create a test that reproduces the problem
2015-04-06 5:20 GMT+03:00 Steve Ebersole :
> I see you have a test repository reproducing the error. I will try to run
> from there.
>
> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev
> wrote:
>
>> Hi Steve,
>>
>> the test project that I created still fails with the latest SNAPSHOT
>> release, although the foreign keys are not created. Can you please
>> investigate if that is related to the same issue. The test repository is
>> here:
>>
>> https://github.com/paranoiabla/HHH-8805
>>
>>
>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard :
>>
>>> Steve, I think there is something fishy.
>>> I have created a branch with a blatant usage of a JDK 8 API in
>>> hibernate-core
>>> There is one commit above today’s master:
>>>
>>> protected EmptyInterceptor() {
>>> + final java.time.ZoneId id =
>>> java.time.ZoneId.systemDefault();
>>> + System.out.println( id.getId() );
>>> }
>>>
>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer <
>>> https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer>
>>>
>>>
>>> And when I run ./gradlew clean build
>>> things do pass, i.e. Animal Sniffer is either not executed or it does
>>> not make the build fail. I did not see any Animal Sniffer reference in the
>>> console while it was running.
>>>
>>> Does it do the same for you if you clone my branch?
>>>
>>> Emmanuel
>>>
>>> PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of Mac
>>> on FindBug executions ;)
>>>
>>> > On 01 Apr 2015, at 18:09, Steve Ebersole wrote:
>>> >
>>> > I'm not going to argue with you man. AnimalSniffer *is* run. If you
>>> don't
>>> > believe that and don't want to verify it for yourself, oh well,
>>> nothing I
>>> > can do about that...
>>> >
>>> > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling
>>> wrote:
>>> >
>>> >> Hum, you are not April-fooling me, right ;)
>>> >>
>>> >> There is something Java-8-specific in already: the usage of
>>> >> ConcurrentHashMap#keySet() (in
>>> >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when
>>> compiled on
>>> >> Java 8 - adds a reference to the Java-8-only type KeySetView to the
>>> class
>>> >> file of SessionFactoryImpl. That's the issue pointed out by Petar
>>> >> originally.
>>> >>
>>> >> But when running "./gradlew build" on the current master, the build
>>> >> passes. I would expect it to fail though, as AnimalSniffer should
>>> detect
>>> >> that usage of Java 8's KeySetView class. So I don't see that AS is
>>> executed
>>> >> actually? Or are you saying it is run but it's findings don't cause
>>> the
>>> >> build to fail?
>>> >>
>>> >> If I go back to the original approach of using AS (via git checkout
>>> >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due to
>>> that
>>> >> reference from SessionFactoryImpl#iterateEntityNameResolvers().
>>> >>
>>> >> Do you actually see the build on master fail due to that reference
>>> being
>>> >> discovered by AS?
>>> >>
>>> >>
>>> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole :
>>> >>
>>> >>> Gunnar, it is applied. Add something that is java 8 specific and
>>> see...
>>> >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling"
>>> wrote:
>>> >>>
>>> I saw the plug-in, Steve. But how/when is it executed?
>>>
>>> Running "./gradlew build" used to execute AnimalSniffer and would
>>> have
>>> revealed that accidental usage of KeySetView. That's not the case
>>> anymore.
>>> It would be nice if that new plug-in could be applied automatically
>>> after
>>> compileJava as it used to be the case with the Ant-based approach.
>>>
>>>
>>> 2015-0
