From paranoiabla at gmail.com Thu Mar 1 03:41:50 2018 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Thu, 1 Mar 2018 10:41:50 +0200 Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14 In-Reply-To: References: Message-ID: Hi Christian, My model has more than 250 entities big. Here's the code that throws the NLP: Class c1 = clazz1.getMappedClass(); Class c2 = commonPersistentClass.getMappedClass(); MappedSuperclass commonMappedSuperclass = null; // First we traverse up the clazz2/commonPersistentClass super types until we find a common type while ( !c2.isAssignableFrom( c1 ) ) { if ( commonPersistentClass == null) { if ( commonMappedSuperclass.getSuperPersistentClass() == null ) { // <------------------------ NLPEX happens here!!!!!! commonMappedSuperclass = commonMappedSuperclass.getSuperMappedSuperclass(); commonPersistentClass = null; } else { commonPersistentClass = commonMappedSuperclass.getSuperPersistentClass(); commonMappedSuperclass = null; } } else { if ( commonPersistentClass.getSuperclass() == null ) { commonMappedSuperclass = commonPersistentClass.getSuperMappedSuperclass(); commonPersistentClass = null; } else { commonPersistentClass = commonPersistentClass.getSuperclass(); commonMappedSuperclass = null; } } } As you can see the commonMappedSuperclass is not initialized and stays null! At this moment c1 is CustomerEntity and c2 is UserGroupEntity. The hierarchy looks like this: Principal / \ Usergroup User | Customer HTH 2018-02-28 21:52 GMT+02:00 Christian Beikov : > Hey, I saw the comment on the issue. Thanks for reporting. Could you > maybe post the model that causes this? I'd need to create a reproducer > to be able to analyze this further. > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 28.02.2018 um 20:11 schrieb Petar Tahchiev: > > Hi guys, > > I have this exception with latest 5.2.14 (my project runs fine with > 5.2.13): > > > > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: > > default] Unable to build Hibernate SessionFactory > > at > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp > l.persistenceException(EntityManagerFactoryBuilderImpl.java:970) > > at > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build( > EntityManagerFactoryBuilderImpl.java:895) > > at > > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceP > rovider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceP > rovider.java:57) > > at > > org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean. > createNativeEntityManagerFactory(LocalContainerEntityManagerFac > toryBean.java:365) > > at > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean. > buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBean.java:387) > > at > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBe > an.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376) > > at > > org.springframework.orm.jpa.LocalContainerEntityManagerFac > toryBean.afterPropertiesSet(LocalContainerEntityManagerFac > toryBean.java:341) > > at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac > tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769) > > at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac > tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706) > > ... 32 more > > Caused by: org.hibernate.MappingException: Could not instantiate > persister > > org.hibernate.persister.entity.SingleTableEntityPersister > > at > > org.hibernate.persister.internal.PersisterFactoryImpl. > createEntityPersister(PersisterFactoryImpl.java:112) > > at > > org.hibernate.persister.internal.PersisterFactoryImpl. > createEntityPersister(PersisterFactoryImpl.java:77) > > at > > org.hibernate.metamodel.internal.MetamodelImpl. > initialize(MetamodelImpl.java:128) > > at > > org.hibernate.internal.SessionFactoryImpl.( > SessionFactoryImpl.java:300) > > at > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build( > SessionFactoryBuilderImpl.java:460) > > at > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build( > EntityManagerFactoryBuilderImpl.java:892) > > ... 39 more > > Caused by: java.lang.NullPointerException > > at > > org.hibernate.persister.entity.AbstractPropertyMapping. > getSuperCollection(AbstractPropertyMapping.java:285) > > at > > org.hibernate.persister.entity.AbstractPropertyMapping.addPropertyPath( > AbstractPropertyMapping.java:198) > > at > > org.hibernate.persister.entity.AbstractPropertyMapping. > initPropertyPaths(AbstractPropertyMapping.java:395) > > at > > org.hibernate.persister.entity.AbstractEntityPersister. > initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300) > > at > > org.hibernate.persister.entity.AbstractEntityPersister. > initPropertyPaths(AbstractEntityPersister.java:2347) > > at > > org.hibernate.persister.entity.AbstractEntityPersister.postConstruct( > AbstractEntityPersister.java:3906) > > at > > org.hibernate.persister.entity.SingleTableEntityPersister.( > SingleTableEntityPersister.java:437) > > at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown > > Source) > > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance( > DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > > at > > org.hibernate.persister.internal.PersisterFactoryImpl. > createEntityPersister(PersisterFactoryImpl.java:96) > > ... 44 more > > > > > > > > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From mihalcea.vlad at gmail.com Thu Mar 1 03:49:39 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 1 Mar 2018 10:49:39 +0200 Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14 In-Reply-To: References: Message-ID: Hi Petar, You can use this template: http://in.relation.to/2016/01/14/hibernate-jpa-test-case-template/ to create a test case that replicates the issue. You don't need to provide all entities, just the 4 entities that build that hierarchy you have mentioned in your email. If you can replicate it, please open a Jira issue and attach the test case so that it's easier to investigate the cause and provide a fix. Thanks, Vlad On Thu, Mar 1, 2018 at 10:41 AM, Petar Tahchiev wrote: > Hi Christian, > > My model has more than 250 entities big. Here's the code that throws the > NLP: > > Class c1 = clazz1.getMappedClass(); > Class c2 = commonPersistentClass.getMappedClass(); > MappedSuperclass commonMappedSuperclass = null; > > // First we traverse up the clazz2/commonPersistentClass super types > until we find a common type > while ( !c2.isAssignableFrom( c1 ) ) { > if ( commonPersistentClass == null) { > if ( commonMappedSuperclass.getSuperPersistentClass() == null ) > { // <------------------------ NLPEX happens here!!!!!! > commonMappedSuperclass = > commonMappedSuperclass.getSuperMappedSuperclass(); > commonPersistentClass = null; > } > else { > commonPersistentClass = > commonMappedSuperclass.getSuperPersistentClass(); > commonMappedSuperclass = null; > } > } > else { > if ( commonPersistentClass.getSuperclass() == null ) { > commonMappedSuperclass = > commonPersistentClass.getSuperMappedSuperclass(); > commonPersistentClass = null; > } > else { > commonPersistentClass = commonPersistentClass.getSuperclass(); > commonMappedSuperclass = null; > } > } > } > > As you can see the commonMappedSuperclass is not initialized and stays > null! > At this moment c1 is CustomerEntity and c2 is UserGroupEntity. The > hierarchy looks like this: > > Principal > / \ > Usergroup User > | > Customer > > HTH > > > > 2018-02-28 21:52 GMT+02:00 Christian Beikov : > > > Hey, I saw the comment on the issue. Thanks for reporting. Could you > > maybe post the model that causes this? I'd need to create a reproducer > > to be able to analyze this further. > > > > > > Mit freundlichen Gr??en, > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 28.02.2018 um 20:11 schrieb Petar Tahchiev: > > > Hi guys, > > > I have this exception with latest 5.2.14 (my project runs fine with > > 5.2.13): > > > > > > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: > > > default] Unable to build Hibernate SessionFactory > > > at > > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp > > l.persistenceException(EntityManagerFactoryBuilderImpl.java:970) > > > at > > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build( > > EntityManagerFactoryBuilderImpl.java:895) > > > at > > > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceP > > rovider.createContainerEntityManagerFactory( > SpringHibernateJpaPersistenceP > > rovider.java:57) > > > at > > > org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean. > > createNativeEntityManagerFactory(LocalContainerEntityManagerFac > > toryBean.java:365) > > > at > > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean. > > buildNativeEntityManagerFactory(AbstractEntityManagerFactoryBe > an.java:387) > > > at > > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBe > > an.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376) > > > at > > > org.springframework.orm.jpa.LocalContainerEntityManagerFac > > toryBean.afterPropertiesSet(LocalContainerEntityManagerFac > > toryBean.java:341) > > > at > > > org.springframework.beans.factory.support. > AbstractAutowireCapableBeanFac > > tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769) > > > at > > > org.springframework.beans.factory.support. > AbstractAutowireCapableBeanFac > > tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706) > > > ... 32 more > > > Caused by: org.hibernate.MappingException: Could not instantiate > > persister > > > org.hibernate.persister.entity.SingleTableEntityPersister > > > at > > > org.hibernate.persister.internal.PersisterFactoryImpl. > > createEntityPersister(PersisterFactoryImpl.java:112) > > > at > > > org.hibernate.persister.internal.PersisterFactoryImpl. > > createEntityPersister(PersisterFactoryImpl.java:77) > > > at > > > org.hibernate.metamodel.internal.MetamodelImpl. > > initialize(MetamodelImpl.java:128) > > > at > > > org.hibernate.internal.SessionFactoryImpl.( > > SessionFactoryImpl.java:300) > > > at > > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build( > > SessionFactoryBuilderImpl.java:460) > > > at > > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build( > > EntityManagerFactoryBuilderImpl.java:892) > > > ... 39 more > > > Caused by: java.lang.NullPointerException > > > at > > > org.hibernate.persister.entity.AbstractPropertyMapping. > > getSuperCollection(AbstractPropertyMapping.java:285) > > > at > > > org.hibernate.persister.entity.AbstractPropertyMapping. > addPropertyPath( > > AbstractPropertyMapping.java:198) > > > at > > > org.hibernate.persister.entity.AbstractPropertyMapping. > > initPropertyPaths(AbstractPropertyMapping.java:395) > > > at > > > org.hibernate.persister.entity.AbstractEntityPersister. > > initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300) > > > at > > > org.hibernate.persister.entity.AbstractEntityPersister. > > initPropertyPaths(AbstractEntityPersister.java:2347) > > > at > > > org.hibernate.persister.entity.AbstractEntityPersister.postConstruct( > > AbstractEntityPersister.java:3906) > > > at > > > org.hibernate.persister.entity.SingleTableEntityPersister.( > > SingleTableEntityPersister.java:437) > > > at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unknown > > > Source) > > > at > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance( > > DelegatingConstructorAccessorImpl.java:45) > > > at java.lang.reflect.Constructor.newInstance(Constructor.java: > 423) > > > at > > > org.hibernate.persister.internal.PersisterFactoryImpl. > > createEntityPersister(PersisterFactoryImpl.java:96) > > > ... 44 more > > > > > > > > > > > > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Mar 1 14:37:15 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 01 Mar 2018 19:37:15 +0000 Subject: [hibernate-dev] 5.3 finalization plan Message-ID: In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified discussion about the remaining currently unresolved discussions and what exactly we are going to do for 5.3 mainly in regards to compatibility with an eye to 6.0 Cache region-name as exposed in API/SPI This one is a "sneaky" compatibility concern. When discussing this, it seems like we had a consensus that the way this should work is for the name passed in to be un-prefixed. Unfortunately the current behavior is to accept the qualified region name. IMO we should change this. However, there is a big danger in that : it would introduce a run-time behavior incompatibility, as opposed to a compile one, which in a way is worse. See the new test I just added to master for examples of what I mean - org.hibernate.test.cache.RegionNameTest One option for compatibility is to introduce a new compatibility flag for this. Something like "hibernate.cache.region_name_api_prefixed" (true/false). Or a better way might be to accept either, and to avoid the extra perf hit of add a new setting to disallow calls with the prefixed name. Also Sanne brought up the idea of ORM simply no longer dealing with prefix (this is at odds with the current API/SPI calls as tested). Other thoughts/ideas? Caching It was decided to include HHH-11356[1] (cache SPI redesign) in 5.3. See the Jira for details. Statistics (caching) HHH-11356 redefines how regions and access strategies are structured, related and accessed. I won't get too in to the details here (read the Jira if interested) but that required changes to other code that uses the SPI. Most of those are internal and were easy to adjust. However Statistics, as a consumer of these regions and access strategies, also required some changes. HHH-12323[2] is the Jira for these changes. Again the see the Jira for details. Type System The other major change for 6.0 is the metamodel, type system change. This one is pervasive. All of the strategies to bridge Type and read-by-name / read-by-position, imo, are not feasible. The changes in the run-time metamodel are too much to bridge, which is a complicating factor. Right down to PersisterFactory. P.S. where there is already a Jira it would be best if we can keep the discussions on the Jira itself. [1] https://hibernate.atlassian.net/browse/HHH-11356 [2] https://hibernate.atlassian.net/browse/HHH-11356 From gbadner at redhat.com Thu Mar 1 15:24:09 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 1 Mar 2018 12:24:09 -0800 Subject: [hibernate-dev] Introduce OperationContext in 5.3? Message-ID: Hi, HHH-10478 is currently scheduled for 6.0.0.alpha1. What do you think about introducing it into 5.3.0 instead? Using an OperationContext would be a less hacky way to fix HHH-3799 (PersistentSet does not honor hashcode/equals contract when loaded eagerly). It would be nice to remove operation-specific fields from StatefulPersistenceContext: private int cascading; private int loadCounter; private int removeOrphanBeforeUpdatesCounter; private boolean flushing; private boolean defaultReadOnly; private boolean hasNonReadOnlyEntities; private LoadContexts loadContexts; Without using an Operation context, the fix for HHH-3799would add something like: private boolean isEntityLoading; Regards, Gail From steve at hibernate.org Thu Mar 1 16:38:13 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 01 Mar 2018 21:38:13 +0000 Subject: [hibernate-dev] Introduce OperationContext in 5.3? In-Reply-To: References: Message-ID: I'm ok with it, but only if it's going to be ready in 2 weeks On Thu, Mar 1, 2018, 2:32 PM Gail Badner wrote: > Hi, > > HHH-10478 is currently scheduled for 6.0.0.alpha1. What do you think about > introducing it into 5.3.0 instead? > > Using an OperationContext would be a less hacky way to fix HHH-3799 > (PersistentSet does not honor hashcode/equals contract when loaded > eagerly). > > It would be nice to remove operation-specific fields from > StatefulPersistenceContext: > > private int cascading; > private int loadCounter; > private int removeOrphanBeforeUpdatesCounter; > private boolean flushing; > private boolean defaultReadOnly; > private boolean hasNonReadOnlyEntities; > > private LoadContexts loadContexts; > > Without using an Operation context, the fix for HHH-3799would add something > like: > > private boolean isEntityLoading; > > Regards, > Gail > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Mar 1 16:39:19 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 1 Mar 2018 21:39:19 +0000 Subject: [hibernate-dev] Byte-buddy: default enhancer in 5.3 ? [HHH-11253] In-Reply-To: References: Message-ID: An update on this; I've found multiple issues, yet when digging none seem to be a strong reason to withold switching to Byte Buddy as default. The main problem seems to be that running the testsuite will somehow load 2.867 different Class instances all having the same name "org.hibernate.test.bytecode.enhancement.access.MixedAccessTest", and a matching amount of "org.hibernate.test.bytecode.enhancement.access.MixedAccessTest$NoDirtyCheckingContext" classes. I'm not really understanding how this happens yet, the ClassLoader chain is huge and complex: there's a "root" classloader by Gradle which applies some custom filtering, while on our test side this is followed by two levels of enhancers implemented by two different copies of byte-buddy: Mockito is including a shaded copy of byte-buddy and has its own additional map with weak keys to cache more classes and classloaders. So we're using Byte Buddy both for entity enhancement, and to enhance our tests which I guess could include re-enhancing the test entities in some situations. We're also spending about half a gigabyte in empty HashMap instances, and silly things such as 40MB in repeated copies of the same String or same Integer instances. I could fix some little waste caused by Hibernate ORM so the good news is that we'll be consuming a bit less at runtime. Most of the duplication though is caused by overhead by the huge amount of independent ClassLoaders: even class names are repeated, package filtering and so on are repeated over and over into the various loading caches of each classloader, repeated with similar layers of Vector and LinkedHashMaps composing the repeated metadata structures. Now the good news: the test "MixedAccessTest" is marked with @Ignored. If I delete it, everything works fine. I don't like deleting things but I'm not fully understanding what this test is meant to accomplish.. what shall I do? I propose we delete it, anyone who's willing to get back to it can restore it from history. I see three options: 1) delete MixedAccessTest 2) ignore it for now and raise the memory setting of the testsuite from 2G to 8G 3) keep working on this and see if I can fix the tests, hopefully with some help Thanks, Sanne On 28 February 2018 at 14:13, Steve Ebersole wrote: > I see a few (like in 3 or 4) Jiras mentioning people using Byte Buddy for > enhancement, without Byte Buddy being the reason for the issue. I cannot > speak to how widely used it is. > > On Wed, Feb 28, 2018 at 7:10 AM Sanne Grinovero wrote: >> >> I found a couple more issues related to Byte Buddy which probably >> should be fixed before we can make it the default. >> >> I've solved the trivial ones, but there's one more problem which I >> couldn't nail down yet: the testsuite is using a significant amount of >> additional memory when all tests default to the Byte Buddy based >> enhancer: the requirements are rocketing from about 150MB to 4GB. >> >> A further complication is that for some reason Flight Recorder crashes >> when connecting to the ORM testsuite; I've tried both versions coming >> with JDK8 and JDK9 they both fail. I finally manged to get some >> recordings from CLI tools so I hope to know more soon. >> >> I also noticed that the support for >> hibernate.bytecode.provider=bytebuddy was not documented; that might >> explain some lack of feedback on such issues. Makes me think that >> maybe this wasn't tested much yet? >> >> Thanks, >> Sanne >> >> >> On 27 February 2018 at 11:13, Sanne Grinovero wrote: >> > On 23 February 2018 at 20:29, Steve Ebersole >> > wrote: >> >> You mean change to 5.3? +1 >> > >> > Right that's what I meant. Thanks, will do! >> > >> >> >> >> On Fri, Feb 23, 2018 at 2:09 PM Sanne Grinovero >> >> wrote: >> >>> >> >>> HHH-11253 is about making ByteBuddy the default implementation, but >> >>> it's flagged for 6. >> >>> >> >>> I think that in Paris there was consensus to make it the default in >> >>> 5.3 alredy, to possibly drop Javassist entirely in 6.0. >> >>> >> >>> May I change this to 6 ? If that's ok, I can assign it to myself. >> >>> >> >>> Thanks, >> >>> Sanne >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Fri Mar 2 00:55:48 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 1 Mar 2018 21:55:48 -0800 Subject: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement Message-ID: Hi, Currently, when a lazy group is loaded that has associations, there are 2 SQL statements executed. For example, suppose the DEFAULT lazy group contains the following: * Order#customer is a lazy many-to-one association; * Order#text is a lazy LOB. When one of these properties is referenced, Hibernate loads both of them. Currently, it takes 2 SQL statements to get the association loaded. 1) Loads #text and the FK value for #customer (select o.text, o.customer_id from orders o where o.id = ?) 2) Loads the state for #customer (select ... from customers c where c.id = ?) In other words, FetchMode.SELECT is used to load associations in a lazy group. HHH-11223 involves combining the 2 SQL statements into a single statement using a join (i.e., using FetchMode.JOIN), but only when at least one of the following is true: * caching is disabled for the SessionFactory (e.g., hibernate.cache.use_sec ond_level_cache=false; * caching is not enabled for "get" operations (i.e., session.getCacheMode().isGetEnabled() == false); * the associated entity type (and subclasses?) is not cached HHH-11223 only mentions to-one associations, but I think collections in a lazy group could also be loaded using a join as well. I think I'm pretty close, but I need to do a lot more testing to ensure it covers things like: * lazy association in composite ID * lazy association in an embeddable * lazy association in a secondary table * lazy association in a subclass * too many bags This is what I have implemented so far: https://github.com/hibernate/hibernate-orm/pull/2170 At the moment, I'm not looking for a comprehensive review. I'm just looking for a review of the overall design. I don't want to get into the nitty-gritty here, but, basically, I've created a new type of AbstractLoadPlanBasedEntityLoader, LazyGroupLoader, which loads the lazy group properties into the existing entity. If caching is disabled for the SessionFactory, then one loader is constructed per lazy group, and associations will be loaded using FetchMode.JOIN. If caching is enabled for the SessionFactory, then 2 loaders are constructed per lazy group. One loader is used when caching is enabled for "get" operations (using Fetch.SELECT for cached associated entities/collections; Fetch.JOIN for other associations). The other loader is used when caching is disabled for "get" operations. Here are some of the changes to the default behavior (described above) that could be useful: 1) Change all associations in lazy groups to be loaded using FetchMode.SELECT (as is currently done without the fix), or using FetchMode.JOIN (regardless of caching). A new configuration property could be added: hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | join ) 2) Allow the FetchMode to be configured for a particular lazy association. According to the documentation [1], @Fetch can't be used for this because, "... FetchMode.JOIN acts as a FetchType.EAGER strategy. Even if we mark the association as FetchType.LAZY, the FetchMode.JOIN will load the association eagerly." A new annotation could be introduced: @LazyFetch. Comments or suggestions? Thanks, Gail [1] http://docs.jboss.org/hibernate/orm/5.2/userguide/ html_single/Hibernate_User_Guide.html#fetching-fetchmode-join From gbadner at redhat.com Fri Mar 2 00:58:49 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 1 Mar 2018 21:58:49 -0800 Subject: [hibernate-dev] Introduce OperationContext in 5.3? In-Reply-To: References: Message-ID: Hi Steve, I was going to make an improvement to my POC to use lambda expressions. I remember you had a couple of comments about the POC; I'll have to look them up. If it wasn't anything that had a big impact on the design, then I think I may be able to get it fixed in 2 weeks. I'll look into this more tomorrow. Thanks, Gail On Thu, Mar 1, 2018 at 1:38 PM, Steve Ebersole wrote: > I'm ok with it, but only if it's going to be ready in 2 weeks > > > On Thu, Mar 1, 2018, 2:32 PM Gail Badner wrote: > >> Hi, >> >> HHH-10478 is currently scheduled for 6.0.0.alpha1. What do you think about >> introducing it into 5.3.0 instead? >> >> Using an OperationContext would be a less hacky way to fix HHH-3799 >> (PersistentSet does not honor hashcode/equals contract when loaded >> eagerly). >> >> It would be nice to remove operation-specific fields from >> StatefulPersistenceContext: >> >> private int cascading; >> private int loadCounter; >> private int removeOrphanBeforeUpdatesCounter; >> private boolean flushing; >> private boolean defaultReadOnly; >> private boolean hasNonReadOnlyEntities; >> >> private LoadContexts loadContexts; >> >> Without using an Operation context, the fix for HHH-3799would add >> something >> like: >> >> private boolean isEntityLoading; >> >> Regards, >> Gail >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gbadner at redhat.com Fri Mar 2 01:11:58 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 1 Mar 2018 22:11:58 -0800 Subject: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement In-Reply-To: References: Message-ID: This is not necessarily needed for 5.3.0, but I would like to get it into the 5.3 branch. So far, there is one change to an SPI, Queryable#lazyGroupSelectFragment is added: public String lazyGroupSelectFragment( String tableAlias, String suffix, String fetchGroupName); The method gets implemented in AbstractEntityPersister. I don't think it's possible to create a default method in Queryable because the method needs access to private/protect methods in AbstractEntityPersister. If I don't get HHH-11223 in for 5.3.0, should I at least push the SPI change for 5.3.0? On Thu, Mar 1, 2018 at 9:55 PM, Gail Badner wrote: > Hi, > > Currently, when a lazy group is loaded that has associations, there are 2 > SQL statements executed. > > For example, suppose the DEFAULT lazy group contains the following: > > * Order#customer is a lazy many-to-one association; > > * Order#text is a lazy LOB. > > > When one of these properties is referenced, Hibernate loads both of them. > > > Currently, it takes 2 SQL statements to get the association loaded. > > > 1) Loads #text and the FK value for #customer (select o.text, > o.customer_id from orders o where o.id = ?) > > 2) Loads the state for #customer (select ... from customers c where c.id = > ?) > > > In other words, FetchMode.SELECT is used to load associations in a lazy > group. > > > HHH-11223 involves combining the 2 SQL statements into a single statement > using a join (i.e., using FetchMode.JOIN), but only when at least one of > the following is true: > > > * caching is disabled for the SessionFactory (e.g., > hibernate.cache.use_second_level_cache=false; > > * caching is not enabled for "get" operations (i.e., > session.getCacheMode().isGetEnabled() == false); > > * the associated entity type (and subclasses?) is not cached > > HHH-11223 only mentions to-one associations, but I think collections in a > lazy group could also be loaded using a join as well. > > I think I'm pretty close, but I need to do a lot more testing to ensure it > covers things like: > > * lazy association in composite ID > * lazy association in an embeddable > * lazy association in a secondary table > * lazy association in a subclass > * too many bags > > This is what I have implemented so far: https://github.com/ > hibernate/hibernate-orm/pull/2170 > > At the moment, I'm not looking for a comprehensive review. I'm just > looking for a review of the overall design. > > I don't want to get into the nitty-gritty here, but, basically, I've > created a new type of AbstractLoadPlanBasedEntityLoader, LazyGroupLoader, > which loads the lazy group properties into the existing entity. > > If caching is disabled for the SessionFactory, then one loader is > constructed per lazy group, and associations will be loaded using > FetchMode.JOIN. > > If caching is enabled for the SessionFactory, then 2 loaders are > constructed per lazy group. One loader is used when caching is enabled for > "get" operations (using Fetch.SELECT for cached associated > entities/collections; Fetch.JOIN for other associations). The other loader > is used when caching is disabled for "get" operations. > > Here are some of the changes to the default behavior (described above) > that could be useful: > > 1) Change all associations in lazy groups to be loaded using > FetchMode.SELECT (as is currently done without the fix), or using > FetchMode.JOIN (regardless of caching). A new configuration property could > be added: > > hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | > join ) > > 2) Allow the FetchMode to be configured for a particular lazy association. > According to the documentation [1], @Fetch can't be used for this because, > "... FetchMode.JOIN acts as a FetchType.EAGER strategy. Even if we mark the > association as FetchType.LAZY, the FetchMode.JOIN will load the association > eagerly." > > A new annotation could be introduced: @LazyFetch. > > Comments or suggestions? > > Thanks, > Gail > > [1] http://docs.jboss.org/hibernate/orm/5.2/userguide/html_ > single/Hibernate_User_Guide.html#fetching-fetchmode-join > From rory.odonnell at oracle.com Fri Mar 2 05:58:03 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 2 Mar 2018 10:58:03 +0000 Subject: [hibernate-dev] JDK 10: Release Candidate & JDK 11 Early Access builds available Message-ID: <62d10639-e19e-b4ef-8aba-36f830065e93@oracle.com> Hi Sanne, *JDK 10 build 45 is our JDK 10 Release Candidate and now available at http://jdk.java.net/10/* * Schedule, status & features o http://openjdk.java.net/projects/jdk/10/ * Release Notes o http://jdk.java.net/10/release-notes * Summary of changes in b45: o JDK-8198658 - Docs still point to JDK 9 docs *JDK 11 EA build 3, under both the GPL and Oracle EA licenses, are now available at **http://jdk.java.net/11**.* * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/2/jdk-11+2.html * JEPs targeted to JDK 11, so far o 309: Dynamic Class-File Constants o 318: Epsilon: An Arbitrarily Low-Overhead Garbage Collector o *320: **Remove the Java EE and CORBA Modules * ** + ** *This build includes JEP 320, so build is significantly smaller (nine fewer modules, 22 fewer megabyteson Linux/x64).* o 323: Local-Variable Syntax for Lambda Parameters * Open Source Project fixes in JDK 11 build 1 o JDK-8195096 - Apache Tomcat + Exception with custom LogManager on starting Apache Tomcat o JDK-8193802 - Apache Maven + NullPointerException from JarFileSystem.getVersionMap() o JDK-8191842 - jOOQ + JShell: Inferred type information is lost when assigning types to a "var" Finally, the Crypto roadmap was updated - 23-Feb-2018** ** * Add support for AEAD TLS Cipher Suites o Target date changed from 2018-04-17 to 2018-07-17 Regards, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From steve at hibernate.org Fri Mar 2 08:07:50 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Mar 2018 13:07:50 +0000 Subject: [hibernate-dev] 5.3 finalization plan In-Reply-To: References: Message-ID: I have all of the caching and statistics changes done, however there are currently a few test failures because of the region-name issue. If I don't hear replies by Monday, I'll just pick a solution for that. Aka, speak now or forever hold your peace :) On Thu, Mar 1, 2018 at 1:37 PM Steve Ebersole wrote: > In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified > discussion about the remaining currently unresolved discussions and what > exactly we are going to do for 5.3 mainly in regards to compatibility with > an eye to 6.0 > > > > Cache region-name as exposed in API/SPI > > This one is a "sneaky" compatibility concern. When discussing this, it > seems like we had a consensus that the way this should work is for the name > passed in to be un-prefixed. Unfortunately the current behavior is to > accept the qualified region name. IMO we should change this. However, > there is a big danger in that : it would introduce a run-time behavior > incompatibility, as opposed to a compile one, which in a way is worse. See > the new test I just added to master for examples of what I mean > - org.hibernate.test.cache.RegionNameTest > > One option for compatibility is to introduce a new compatibility flag for > this. Something like "hibernate.cache.region_name_api_prefixed" > (true/false). Or a better way might be to accept either, and to avoid the > extra perf hit of add a new setting to disallow calls with the prefixed > name. > > Also Sanne brought up the idea of ORM simply no longer dealing with prefix > (this is at odds with the current API/SPI calls as tested). > > Other thoughts/ideas? > > > Caching > > It was decided to include HHH-11356[1] (cache SPI redesign) in 5.3. See > the Jira for details. > > > Statistics (caching) > > HHH-11356 redefines how regions and access strategies are structured, > related and accessed. I won't get too in to the details here (read the > Jira if interested) but that required changes to other code that uses the > SPI. Most of those are internal and were easy to adjust. However > Statistics, as a consumer of these regions and access strategies, also > required some changes. HHH-12323[2] is the Jira for these changes. > > Again the see the Jira for details. > > > Type System > > The other major change for 6.0 is the metamodel, type system change. This > one is pervasive. All of the strategies to bridge Type and read-by-name / > read-by-position, imo, are not feasible. > > The changes in the run-time metamodel are too much to bridge, which is a > complicating factor. Right down to PersisterFactory. > > > > P.S. where there is already a Jira it would be best if we can keep the > discussions on the Jira itself. > > > [1] https://hibernate.atlassian.net/browse/HHH-11356 > [2] https://hibernate.atlassian.net/browse/HHH-11356 > > From gbadner at redhat.com Fri Mar 2 16:51:48 2018 From: gbadner at redhat.com (Gail Badner) Date: Fri, 2 Mar 2018 13:51:48 -0800 Subject: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement In-Reply-To: References: Message-ID: Steve, is this related to https://hibernate.atlassian.net/browse/HHH-3949? On Thu, Mar 1, 2018 at 10:11 PM, Gail Badner wrote: > This is not necessarily needed for 5.3.0, but I would like to get it into > the 5.3 branch. > > So far, there is one change to an SPI, Queryable#lazyGroupSelectFragment > is added: > > public String lazyGroupSelectFragment( > String tableAlias, > String suffix, > String fetchGroupName); > > The method gets implemented in AbstractEntityPersister. > > I don't think it's possible to create a default method in Queryable > because the method needs access to private/protect methods in > AbstractEntityPersister. > > If I don't get HHH-11223 in for 5.3.0, should I at least push the SPI > change for 5.3.0? > > On Thu, Mar 1, 2018 at 9:55 PM, Gail Badner wrote: > >> Hi, >> >> Currently, when a lazy group is loaded that has associations, there are 2 >> SQL statements executed. >> >> For example, suppose the DEFAULT lazy group contains the following: >> >> * Order#customer is a lazy many-to-one association; >> >> * Order#text is a lazy LOB. >> >> >> When one of these properties is referenced, Hibernate loads both of them. >> >> >> Currently, it takes 2 SQL statements to get the association loaded. >> >> >> 1) Loads #text and the FK value for #customer (select o.text, >> o.customer_id from orders o where o.id = ?) >> >> 2) Loads the state for #customer (select ... from customers c where c.id = >> ?) >> >> >> In other words, FetchMode.SELECT is used to load associations in a lazy >> group. >> >> >> HHH-11223 involves combining the 2 SQL statements into a single >> statement using a join (i.e., using FetchMode.JOIN), but only when at least >> one of the following is true: >> >> >> * caching is disabled for the SessionFactory (e.g., >> hibernate.cache.use_second_level_cache=false; >> >> * caching is not enabled for "get" operations (i.e., >> session.getCacheMode().isGetEnabled() == false); >> >> * the associated entity type (and subclasses?) is not cached >> >> HHH-11223 only mentions to-one associations, but I think collections in a >> lazy group could also be loaded using a join as well. >> >> I think I'm pretty close, but I need to do a lot more testing to ensure >> it covers things like: >> >> * lazy association in composite ID >> * lazy association in an embeddable >> * lazy association in a secondary table >> * lazy association in a subclass >> * too many bags >> >> This is what I have implemented so far: https://github.com/hibern >> ate/hibernate-orm/pull/2170 >> >> At the moment, I'm not looking for a comprehensive review. I'm just >> looking for a review of the overall design. >> >> I don't want to get into the nitty-gritty here, but, basically, I've >> created a new type of AbstractLoadPlanBasedEntityLoader, LazyGroupLoader, >> which loads the lazy group properties into the existing entity. >> >> If caching is disabled for the SessionFactory, then one loader is >> constructed per lazy group, and associations will be loaded using >> FetchMode.JOIN. >> >> If caching is enabled for the SessionFactory, then 2 loaders are >> constructed per lazy group. One loader is used when caching is enabled for >> "get" operations (using Fetch.SELECT for cached associated >> entities/collections; Fetch.JOIN for other associations). The other loader >> is used when caching is disabled for "get" operations. >> >> Here are some of the changes to the default behavior (described above) >> that could be useful: >> >> 1) Change all associations in lazy groups to be loaded using >> FetchMode.SELECT (as is currently done without the fix), or using >> FetchMode.JOIN (regardless of caching). A new configuration property could >> be added: >> >> hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | >> join ) >> >> 2) Allow the FetchMode to be configured for a particular lazy >> association. According to the documentation [1], @Fetch can't be used for >> this because, "... FetchMode.JOIN acts as a FetchType.EAGER strategy. Even >> if we mark the association as FetchType.LAZY, the FetchMode.JOIN will load >> the association eagerly." >> >> A new annotation could be introduced: @LazyFetch. >> >> Comments or suggestions? >> >> Thanks, >> Gail >> >> [1] http://docs.jboss.org/hibernate/orm/5.2/userguide/html_s >> ingle/Hibernate_User_Guide.html#fetching-fetchmode-join >> > > From steve at hibernate.org Fri Mar 2 17:24:19 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Mar 2018 22:24:19 +0000 Subject: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement In-Reply-To: References: Message-ID: Honestly I am not sure about whether they are "related". I mean in 3949 the query sent to the database already does what you want it to do. I theory 3949 should be easier to fix. But what I find interesting there is that NO_PROXY is requested but it seems as if proxies are still used. On Fri, Mar 2, 2018 at 3:52 PM Gail Badner wrote: > Steve, is this related to https://hibernate.atlassian.net/browse/HHH-3949? > > On Thu, Mar 1, 2018 at 10:11 PM, Gail Badner wrote: > > > This is not necessarily needed for 5.3.0, but I would like to get it into > > the 5.3 branch. > > > > So far, there is one change to an SPI, Queryable#lazyGroupSelectFragment > > is added: > > > > public String lazyGroupSelectFragment( > > String tableAlias, > > String suffix, > > String fetchGroupName); > > > > The method gets implemented in AbstractEntityPersister. > > > > I don't think it's possible to create a default method in Queryable > > because the method needs access to private/protect methods in > > AbstractEntityPersister. > > > > If I don't get HHH-11223 in for 5.3.0, should I at least push the SPI > > change for 5.3.0? > > > > On Thu, Mar 1, 2018 at 9:55 PM, Gail Badner wrote: > > > >> Hi, > >> > >> Currently, when a lazy group is loaded that has associations, there are > 2 > >> SQL statements executed. > >> > >> For example, suppose the DEFAULT lazy group contains the following: > >> > >> * Order#customer is a lazy many-to-one association; > >> > >> * Order#text is a lazy LOB. > >> > >> > >> When one of these properties is referenced, Hibernate loads both of > them. > >> > >> > >> Currently, it takes 2 SQL statements to get the association loaded. > >> > >> > >> 1) Loads #text and the FK value for #customer (select o.text, > >> o.customer_id from orders o where o.id = ?) > >> > >> 2) Loads the state for #customer (select ... from customers c where > c.id = > >> ?) > >> > >> > >> In other words, FetchMode.SELECT is used to load associations in a lazy > >> group. > >> > >> > >> HHH-11223 involves combining the 2 SQL statements into a single > >> statement using a join (i.e., using FetchMode.JOIN), but only when at > least > >> one of the following is true: > >> > >> > >> * caching is disabled for the SessionFactory (e.g., > >> hibernate.cache.use_second_level_cache=false; > >> > >> * caching is not enabled for "get" operations (i.e., > >> session.getCacheMode().isGetEnabled() == false); > >> > >> * the associated entity type (and subclasses?) is not cached > >> > >> HHH-11223 only mentions to-one associations, but I think collections in > a > >> lazy group could also be loaded using a join as well. > >> > >> I think I'm pretty close, but I need to do a lot more testing to ensure > >> it covers things like: > >> > >> * lazy association in composite ID > >> * lazy association in an embeddable > >> * lazy association in a secondary table > >> * lazy association in a subclass > >> * too many bags > >> > >> This is what I have implemented so far: https://github.com/hibern > >> ate/hibernate-orm/pull/2170 > >> > >> At the moment, I'm not looking for a comprehensive review. I'm just > >> looking for a review of the overall design. > >> > >> I don't want to get into the nitty-gritty here, but, basically, I've > >> created a new type of AbstractLoadPlanBasedEntityLoader, > LazyGroupLoader, > >> which loads the lazy group properties into the existing entity. > >> > >> If caching is disabled for the SessionFactory, then one loader is > >> constructed per lazy group, and associations will be loaded using > >> FetchMode.JOIN. > >> > >> If caching is enabled for the SessionFactory, then 2 loaders are > >> constructed per lazy group. One loader is used when caching is enabled > for > >> "get" operations (using Fetch.SELECT for cached associated > >> entities/collections; Fetch.JOIN for other associations). The other > loader > >> is used when caching is disabled for "get" operations. > >> > >> Here are some of the changes to the default behavior (described above) > >> that could be useful: > >> > >> 1) Change all associations in lazy groups to be loaded using > >> FetchMode.SELECT (as is currently done without the fix), or using > >> FetchMode.JOIN (regardless of caching). A new configuration property > could > >> be added: > >> > >> hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | > >> join ) > >> > >> 2) Allow the FetchMode to be configured for a particular lazy > >> association. According to the documentation [1], @Fetch can't be used > for > >> this because, "... FetchMode.JOIN acts as a FetchType.EAGER strategy. > Even > >> if we mark the association as FetchType.LAZY, the FetchMode.JOIN will > load > >> the association eagerly." > >> > >> A new annotation could be introduced: @LazyFetch. > >> > >> Comments or suggestions? > >> > >> Thanks, > >> Gail > >> > >> [1] http://docs.jboss.org/hibernate/orm/5.2/userguide/html_s > >> ingle/Hibernate_User_Guide.html#fetching-fetchmode-join > >> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Fri Mar 2 17:34:13 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 02 Mar 2018 22:34:13 +0000 Subject: [hibernate-dev] HHH-11223 : Initialize bytecode enhanced lazy group using a single SQL statement In-Reply-To: References: Message-ID: My personal feeling is that if the change itself is not going to make it into 5.3 then the SPI addition should not either. There are definitely 2 sides to this though. On the one hand, if you add this SPI method it will *without question* have to change for 6.0. In a way it is creating an incompatibility 5.3->6.0 that is (1) not there currently and (2) unless/until we actually include the fix that uses it, not needed. This will for sure change in 6 because the entire process of generating SQL is different - those values would be pointless[1]. On the other hand, any fix to this in 5.3 would need (it sounds like) this SPI change. So if we don't add it now, we won't be able to fix this in 5.3 at all. However, I think it is worth pointing out that the entire run-time model (here Entityersister, via Queryable) is drastically changing in a completely non-deprecatable way - so this particular change is "a drop in the bucket" of 6.0 changes in this area. So in this particular case, I don't think the 5.3->6.0 compat breakage is that big of a deal. All that said, I would say go for it. Just make as sure as possible that the signature is good for your needs. [1] Yes we could deprecate the method in 6.0 and just have it do nothing (because it would not have enough info to do anything useful in the new model). But personally I very much dislike that - it really just cheats the definition of deprecation. On Fri, Mar 2, 2018 at 12:12 AM Gail Badner wrote: > This is not necessarily needed for 5.3.0, but I would like to get it into > the 5.3 branch. > > So far, there is one change to an SPI, Queryable#lazyGroupSelectFragment is > added: > > public String lazyGroupSelectFragment( > String tableAlias, > String suffix, > String fetchGroupName); > > The method gets implemented in AbstractEntityPersister. > > I don't think it's possible to create a default method in Queryable because > the method needs access to private/protect methods in > AbstractEntityPersister. > > If I don't get HHH-11223 in for 5.3.0, should I at least push the SPI > change for 5.3.0? > > On Thu, Mar 1, 2018 at 9:55 PM, Gail Badner wrote: > > > Hi, > > > > Currently, when a lazy group is loaded that has associations, there are 2 > > SQL statements executed. > > > > For example, suppose the DEFAULT lazy group contains the following: > > > > * Order#customer is a lazy many-to-one association; > > > > * Order#text is a lazy LOB. > > > > > > When one of these properties is referenced, Hibernate loads both of them. > > > > > > Currently, it takes 2 SQL statements to get the association loaded. > > > > > > 1) Loads #text and the FK value for #customer (select o.text, > > o.customer_id from orders o where o.id = ?) > > > > 2) Loads the state for #customer (select ... from customers c where c.id > = > > ?) > > > > > > In other words, FetchMode.SELECT is used to load associations in a lazy > > group. > > > > > > HHH-11223 involves combining the 2 SQL statements into a single statement > > using a join (i.e., using FetchMode.JOIN), but only when at least one of > > the following is true: > > > > > > * caching is disabled for the SessionFactory (e.g., > > hibernate.cache.use_second_level_cache=false; > > > > * caching is not enabled for "get" operations (i.e., > > session.getCacheMode().isGetEnabled() == false); > > > > * the associated entity type (and subclasses?) is not cached > > > > HHH-11223 only mentions to-one associations, but I think collections in a > > lazy group could also be loaded using a join as well. > > > > I think I'm pretty close, but I need to do a lot more testing to ensure > it > > covers things like: > > > > * lazy association in composite ID > > * lazy association in an embeddable > > * lazy association in a secondary table > > * lazy association in a subclass > > * too many bags > > > > This is what I have implemented so far: https://github.com/ > > hibernate/hibernate-orm/pull/2170 > > > > At the moment, I'm not looking for a comprehensive review. I'm just > > looking for a review of the overall design. > > > > I don't want to get into the nitty-gritty here, but, basically, I've > > created a new type of AbstractLoadPlanBasedEntityLoader, LazyGroupLoader, > > which loads the lazy group properties into the existing entity. > > > > If caching is disabled for the SessionFactory, then one loader is > > constructed per lazy group, and associations will be loaded using > > FetchMode.JOIN. > > > > If caching is enabled for the SessionFactory, then 2 loaders are > > constructed per lazy group. One loader is used when caching is enabled > for > > "get" operations (using Fetch.SELECT for cached associated > > entities/collections; Fetch.JOIN for other associations). The other > loader > > is used when caching is disabled for "get" operations. > > > > Here are some of the changes to the default behavior (described above) > > that could be useful: > > > > 1) Change all associations in lazy groups to be loaded using > > FetchMode.SELECT (as is currently done without the fix), or using > > FetchMode.JOIN (regardless of caching). A new configuration property > could > > be added: > > > > hibernate.bytecode.lazyGroup_association_fetchMode=(default | select | > > join ) > > > > 2) Allow the FetchMode to be configured for a particular lazy > association. > > According to the documentation [1], @Fetch can't be used for this > because, > > "... FetchMode.JOIN acts as a FetchType.EAGER strategy. Even if we mark > the > > association as FetchType.LAZY, the FetchMode.JOIN will load the > association > > eagerly." > > > > A new annotation could be introduced: @LazyFetch. > > > > Comments or suggestions? > > > > Thanks, > > Gail > > > > [1] http://docs.jboss.org/hibernate/orm/5.2/userguide/html_ > > single/Hibernate_User_Guide.html#fetching-fetchmode-join > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Mar 5 06:37:34 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 5 Mar 2018 12:37:34 +0100 Subject: [hibernate-dev] NoORM - Improve consistency of our pom files with JBoss parent and WildFly parent Message-ID: Hi, So, I started the effort of making our version properties consistent with JBoss parent/WildFly parent with Search but the idea is to generalize this to all our NoORM projects and be as consistent as possible between the projects. The idea is to, as much as possible, use the exact same notation as the other JBoss projects when declaring the version properties of our dependencies You can see what it implies in this diff: https://github.com/hibernate/hibernate-search/pull/1639/files#diff-600376dffeb79835ede4a0b285078036R184 So, from now on, when you need to add new dependencies in Search: - check if JBoss parent or WildFly parent already contains this dependency, if so use the exact same property name - if not, use if it is descriptive and discriminating enough - if the package name is used for several artifacts or is not descriptive enough, use My plan is to be done with OGM in 2 weeks and do it for HV 6.1 as I don't want to do it in a micro. So please avoid big pom refactorings in OGM for the next 2 weeks. Dependency upgrades are OK, I'll merge them along the way. Thanks! -- Guillaume From paranoiabla at gmail.com Mon Mar 5 07:08:28 2018 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Mon, 5 Mar 2018 14:08:28 +0200 Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14 In-Reply-To: References: Message-ID: I managed to reproduce it. Here's the bug: https://hibernate.atlassian.net/browse/HHH-12354 and here is the project to reproduce it: https://github.com/ptahchiev/hibernate-test-case-templates/tree/nlp 2018-03-01 10:49 GMT+02:00 Vlad Mihalcea : > Hi Petar, > > You can use this template: > > http://in.relation.to/2016/01/14/hibernate-jpa-test-case-template/ > > to create a test case that replicates the issue. You don't need to provide > all entities, > just the 4 entities that build that hierarchy you have mentioned in your > email. > > If you can replicate it, please open a Jira issue and attach the test case > so that it's easier > to investigate the cause and provide a fix. > > Thanks, > Vlad > > On Thu, Mar 1, 2018 at 10:41 AM, Petar Tahchiev > wrote: > >> Hi Christian, >> >> My model has more than 250 entities big. Here's the code that throws the >> NLP: >> >> Class c1 = clazz1.getMappedClass(); >> Class c2 = commonPersistentClass.getMappedClass(); >> MappedSuperclass commonMappedSuperclass = null; >> >> // First we traverse up the clazz2/commonPersistentClass super types >> until we find a common type >> while ( !c2.isAssignableFrom( c1 ) ) { >> if ( commonPersistentClass == null) { >> if ( commonMappedSuperclass.getSuperPersistentClass() == null ) >> { // <------------------------ NLPEX happens here!!!!!! >> commonMappedSuperclass = >> commonMappedSuperclass.getSuperMappedSuperclass(); >> commonPersistentClass = null; >> } >> else { >> commonPersistentClass = >> commonMappedSuperclass.getSuperPersistentClass(); >> commonMappedSuperclass = null; >> } >> } >> else { >> if ( commonPersistentClass.getSuperclass() == null ) { >> commonMappedSuperclass = >> commonPersistentClass.getSuperMappedSuperclass(); >> commonPersistentClass = null; >> } >> else { >> commonPersistentClass = commonPersistentClass.getSuperclass(); >> commonMappedSuperclass = null; >> } >> } >> } >> >> As you can see the commonMappedSuperclass is not initialized and stays >> null! >> At this moment c1 is CustomerEntity and c2 is UserGroupEntity. The >> hierarchy looks like this: >> >> Principal >> / \ >> Usergroup User >> | >> Customer >> >> HTH >> >> >> >> 2018-02-28 21:52 GMT+02:00 Christian Beikov : >> >> > Hey, I saw the comment on the issue. Thanks for reporting. Could you >> > maybe post the model that causes this? I'd need to create a reproducer >> > to be able to analyze this further. >> > >> > >> > Mit freundlichen Gr??en, >> > ------------------------------------------------------------ >> ------------ >> > *Christian Beikov* >> > Am 28.02.2018 um 20:11 schrieb Petar Tahchiev: >> > > Hi guys, >> > > I have this exception with latest 5.2.14 (my project runs fine with >> > 5.2.13): >> > > >> > > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: >> > > default] Unable to build Hibernate SessionFactory >> > > at >> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp >> > l.persistenceException(EntityManagerFactoryBuilderImpl.java:970) >> > > at >> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderI >> mpl.build( >> > EntityManagerFactoryBuilderImpl.java:895) >> > > at >> > > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceP >> > rovider.createContainerEntityManagerFactory(SpringHibernateJ >> paPersistenceP >> > rovider.java:57) >> > > at >> > > org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean. >> > createNativeEntityManagerFactory(LocalContainerEntityManagerFac >> > toryBean.java:365) >> > > at >> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean. >> > buildNativeEntityManagerFactory(AbstractEntityManagerFactory >> Bean.java:387) >> > > at >> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBe >> > an.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376) >> > > at >> > > org.springframework.orm.jpa.LocalContainerEntityManagerFac >> > toryBean.afterPropertiesSet(LocalContainerEntityManagerFac >> > toryBean.java:341) >> > > at >> > > org.springframework.beans.factory.support.AbstractAutowireCa >> pableBeanFac >> > tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769) >> > > at >> > > org.springframework.beans.factory.support.AbstractAutowireCa >> pableBeanFac >> > tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706) >> > > ... 32 more >> > > Caused by: org.hibernate.MappingException: Could not instantiate >> > persister >> > > org.hibernate.persister.entity.SingleTableEntityPersister >> > > at >> > > org.hibernate.persister.internal.PersisterFactoryImpl. >> > createEntityPersister(PersisterFactoryImpl.java:112) >> > > at >> > > org.hibernate.persister.internal.PersisterFactoryImpl. >> > createEntityPersister(PersisterFactoryImpl.java:77) >> > > at >> > > org.hibernate.metamodel.internal.MetamodelImpl. >> > initialize(MetamodelImpl.java:128) >> > > at >> > > org.hibernate.internal.SessionFactoryImpl.( >> > SessionFactoryImpl.java:300) >> > > at >> > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build( >> > SessionFactoryBuilderImpl.java:460) >> > > at >> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderI >> mpl.build( >> > EntityManagerFactoryBuilderImpl.java:892) >> > > ... 39 more >> > > Caused by: java.lang.NullPointerException >> > > at >> > > org.hibernate.persister.entity.AbstractPropertyMapping. >> > getSuperCollection(AbstractPropertyMapping.java:285) >> > > at >> > > org.hibernate.persister.entity.AbstractPropertyMapping.addPr >> opertyPath( >> > AbstractPropertyMapping.java:198) >> > > at >> > > org.hibernate.persister.entity.AbstractPropertyMapping. >> > initPropertyPaths(AbstractPropertyMapping.java:395) >> > > at >> > > org.hibernate.persister.entity.AbstractEntityPersister. >> > initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300) >> > > at >> > > org.hibernate.persister.entity.AbstractEntityPersister. >> > initPropertyPaths(AbstractEntityPersister.java:2347) >> > > at >> > > org.hibernate.persister.entity.AbstractEntityPersister.postConstruct( >> > AbstractEntityPersister.java:3906) >> > > at >> > > org.hibernate.persister.entity.SingleTableEntityPersister.( >> > SingleTableEntityPersister.java:437) >> > > at sun.reflect.GeneratedConstructorAccessor94.newInstance( >> Unknown >> > > Source) >> > > at >> > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance( >> > DelegatingConstructorAccessorImpl.java:45) >> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:4 >> 23) >> > > at >> > > org.hibernate.persister.internal.PersisterFactoryImpl. >> > createEntityPersister(PersisterFactoryImpl.java:96) >> > > ... 44 more >> > > >> > > >> > > >> > > >> > > >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From christian.beikov at gmail.com Mon Mar 5 07:20:58 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Mon, 5 Mar 2018 13:20:58 +0100 Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14 In-Reply-To: References: Message-ID: I have a reproducer as well and have a partial fix already. Just doing some more testing now to make sure some other edge cases I discovered are handled properly. Am 05.03.2018 13:08 schrieb "Petar Tahchiev" : > I managed to reproduce it. Here's the bug: https://hibernate.atlassian. > net/browse/HHH-12354 and here is the project to reproduce it: > https://github.com/ptahchiev/hibernate-test-case-templates/tree/nlp > > 2018-03-01 10:49 GMT+02:00 Vlad Mihalcea : > >> Hi Petar, >> >> You can use this template: >> >> http://in.relation.to/2016/01/14/hibernate-jpa-test-case-template/ >> >> to create a test case that replicates the issue. You don't need to >> provide all entities, >> just the 4 entities that build that hierarchy you have mentioned in your >> email. >> >> If you can replicate it, please open a Jira issue and attach the test >> case so that it's easier >> to investigate the cause and provide a fix. >> >> Thanks, >> Vlad >> >> On Thu, Mar 1, 2018 at 10:41 AM, Petar Tahchiev >> wrote: >> >>> Hi Christian, >>> >>> My model has more than 250 entities big. Here's the code that throws the >>> NLP: >>> >>> Class c1 = clazz1.getMappedClass(); >>> Class c2 = commonPersistentClass.getMappedClass(); >>> MappedSuperclass commonMappedSuperclass = null; >>> >>> // First we traverse up the clazz2/commonPersistentClass super types >>> until we find a common type >>> while ( !c2.isAssignableFrom( c1 ) ) { >>> if ( commonPersistentClass == null) { >>> if ( commonMappedSuperclass.getSuperPersistentClass() == null ) >>> { // <------------------------ NLPEX happens here!!!!!! >>> commonMappedSuperclass = >>> commonMappedSuperclass.getSuperMappedSuperclass(); >>> commonPersistentClass = null; >>> } >>> else { >>> commonPersistentClass = >>> commonMappedSuperclass.getSuperPersistentClass(); >>> commonMappedSuperclass = null; >>> } >>> } >>> else { >>> if ( commonPersistentClass.getSuperclass() == null ) { >>> commonMappedSuperclass = >>> commonPersistentClass.getSuperMappedSuperclass(); >>> commonPersistentClass = null; >>> } >>> else { >>> commonPersistentClass = commonPersistentClass.getSuperclass(); >>> commonMappedSuperclass = null; >>> } >>> } >>> } >>> >>> As you can see the commonMappedSuperclass is not initialized and stays >>> null! >>> At this moment c1 is CustomerEntity and c2 is UserGroupEntity. The >>> hierarchy looks like this: >>> >>> Principal >>> / \ >>> Usergroup User >>> | >>> Customer >>> >>> HTH >>> >>> >>> >>> 2018-02-28 21:52 GMT+02:00 Christian Beikov >> >: >>> >>> > Hey, I saw the comment on the issue. Thanks for reporting. Could you >>> > maybe post the model that causes this? I'd need to create a reproducer >>> > to be able to analyze this further. >>> > >>> > >>> > Mit freundlichen Gr??en, >>> > ------------------------------------------------------------ >>> ------------ >>> > *Christian Beikov* >>> > Am 28.02.2018 um 20:11 schrieb Petar Tahchiev: >>> > > Hi guys, >>> > > I have this exception with latest 5.2.14 (my project runs fine with >>> > 5.2.13): >>> > > >>> > > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: >>> > > default] Unable to build Hibernate SessionFactory >>> > > at >>> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp >>> > l.persistenceException(EntityManagerFactoryBuilderImpl.java:970) >>> > > at >>> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderI >>> mpl.build( >>> > EntityManagerFactoryBuilderImpl.java:895) >>> > > at >>> > > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceP >>> > rovider.createContainerEntityManagerFactory(SpringHibernateJ >>> paPersistenceP >>> > rovider.java:57) >>> > > at >>> > > org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean. >>> > createNativeEntityManagerFactory(LocalContainerEntityManagerFac >>> > toryBean.java:365) >>> > > at >>> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean. >>> > buildNativeEntityManagerFactory(AbstractEntityManagerFactory >>> Bean.java:387) >>> > > at >>> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBe >>> > an.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376) >>> > > at >>> > > org.springframework.orm.jpa.LocalContainerEntityManagerFac >>> > toryBean.afterPropertiesSet(LocalContainerEntityManagerFac >>> > toryBean.java:341) >>> > > at >>> > > org.springframework.beans.factory.support.AbstractAutowireCa >>> pableBeanFac >>> > tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769) >>> > > at >>> > > org.springframework.beans.factory.support.AbstractAutowireCa >>> pableBeanFac >>> > tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706) >>> > > ... 32 more >>> > > Caused by: org.hibernate.MappingException: Could not instantiate >>> > persister >>> > > org.hibernate.persister.entity.SingleTableEntityPersister >>> > > at >>> > > org.hibernate.persister.internal.PersisterFactoryImpl. >>> > createEntityPersister(PersisterFactoryImpl.java:112) >>> > > at >>> > > org.hibernate.persister.internal.PersisterFactoryImpl. >>> > createEntityPersister(PersisterFactoryImpl.java:77) >>> > > at >>> > > org.hibernate.metamodel.internal.MetamodelImpl. >>> > initialize(MetamodelImpl.java:128) >>> > > at >>> > > org.hibernate.internal.SessionFactoryImpl.( >>> > SessionFactoryImpl.java:300) >>> > > at >>> > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build( >>> > SessionFactoryBuilderImpl.java:460) >>> > > at >>> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderI >>> mpl.build( >>> > EntityManagerFactoryBuilderImpl.java:892) >>> > > ... 39 more >>> > > Caused by: java.lang.NullPointerException >>> > > at >>> > > org.hibernate.persister.entity.AbstractPropertyMapping. >>> > getSuperCollection(AbstractPropertyMapping.java:285) >>> > > at >>> > > org.hibernate.persister.entity.AbstractPropertyMapping.addPr >>> opertyPath( >>> > AbstractPropertyMapping.java:198) >>> > > at >>> > > org.hibernate.persister.entity.AbstractPropertyMapping. >>> > initPropertyPaths(AbstractPropertyMapping.java:395) >>> > > at >>> > > org.hibernate.persister.entity.AbstractEntityPersister. >>> > initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300) >>> > > at >>> > > org.hibernate.persister.entity.AbstractEntityPersister. >>> > initPropertyPaths(AbstractEntityPersister.java:2347) >>> > > at >>> > > org.hibernate.persister.entity.AbstractEntityPersister.postC >>> onstruct( >>> > AbstractEntityPersister.java:3906) >>> > > at >>> > > org.hibernate.persister.entity.SingleTableEntityPersister.( >>> > SingleTableEntityPersister.java:437) >>> > > at sun.reflect.GeneratedConstructorAccessor94.newInstance(Unkno >>> wn >>> > > Source) >>> > > at >>> > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance( >>> > DelegatingConstructorAccessorImpl.java:45) >>> > > at java.lang.reflect.Constructor.newInstance(Constructor.java:4 >>> 23) >>> > > at >>> > > org.hibernate.persister.internal.PersisterFactoryImpl. >>> > createEntityPersister(PersisterFactoryImpl.java:96) >>> > > ... 44 more >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> >>> >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search= > 0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > From guillaume.smet at gmail.com Mon Mar 5 07:27:08 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 5 Mar 2018 13:27:08 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? Message-ID: Hi, So far we had 4 duplicate reports of https://hibernate.atlassian.net/browse/HHH-12332 (so not counting the users having seen the bug and not opening a new one). I think this issue qualifies as "we should really get a hotfix release soon". I let the duplicated issues open for now as I saw a couple of reproducers and we should check that all the reported cases are fixed once we have a proper fix. Apart from fixing the NPE, the OP has a point when he says there's something wrong here: https://github.com/hibernate/hibernate-orm/blame/5.2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractPropertyMapping.java#L277 . I suspect c1 and c2 should be reassigned somehow. Christian, I saw you planned to fix it, what's your plan about it? Thanks. -- Guillaume From guillaume.smet at gmail.com Mon Mar 5 07:34:27 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 5 Mar 2018 13:34:27 +0100 Subject: [hibernate-dev] Null-Pointer Exception with 5.2.14 In-Reply-To: References: Message-ID: Hi Christian, Looks like we just crossposted. FWIW, there is another report here: https://hibernate.atlassian.net/browse/HHH-12347 . We should check this case is covered too. I marked the 2 other issues as duplicate of https://hibernate.atlassian.net/browse/HHH-12332 , feel free to close them as Duplicate once you have checked they are covered by your fix. Thanks. On Mon, Mar 5, 2018 at 1:20 PM, Christian Beikov wrote: > I have a reproducer as well and have a partial fix already. Just doing some > more testing now to make sure some other edge cases I discovered are > handled properly. > > Am 05.03.2018 13:08 schrieb "Petar Tahchiev" : > > > I managed to reproduce it. Here's the bug: https://hibernate.atlassian. > > net/browse/HHH-12354 and here is the project to reproduce it: > > https://github.com/ptahchiev/hibernate-test-case-templates/tree/nlp > > > > 2018-03-01 10:49 GMT+02:00 Vlad Mihalcea : > > > >> Hi Petar, > >> > >> You can use this template: > >> > >> http://in.relation.to/2016/01/14/hibernate-jpa-test-case-template/ > >> > >> to create a test case that replicates the issue. You don't need to > >> provide all entities, > >> just the 4 entities that build that hierarchy you have mentioned in your > >> email. > >> > >> If you can replicate it, please open a Jira issue and attach the test > >> case so that it's easier > >> to investigate the cause and provide a fix. > >> > >> Thanks, > >> Vlad > >> > >> On Thu, Mar 1, 2018 at 10:41 AM, Petar Tahchiev > >> wrote: > >> > >>> Hi Christian, > >>> > >>> My model has more than 250 entities big. Here's the code that throws > the > >>> NLP: > >>> > >>> Class c1 = clazz1.getMappedClass(); > >>> Class c2 = commonPersistentClass.getMappedClass(); > >>> MappedSuperclass commonMappedSuperclass = null; > >>> > >>> // First we traverse up the clazz2/commonPersistentClass super types > >>> until we find a common type > >>> while ( !c2.isAssignableFrom( c1 ) ) { > >>> if ( commonPersistentClass == null) { > >>> if ( commonMappedSuperclass.getSuperPersistentClass() == null ) > >>> { // <------------------------ NLPEX happens here!!!!!! > >>> commonMappedSuperclass = > >>> commonMappedSuperclass.getSuperMappedSuperclass(); > >>> commonPersistentClass = null; > >>> } > >>> else { > >>> commonPersistentClass = > >>> commonMappedSuperclass.getSuperPersistentClass(); > >>> commonMappedSuperclass = null; > >>> } > >>> } > >>> else { > >>> if ( commonPersistentClass.getSuperclass() == null ) { > >>> commonMappedSuperclass = > >>> commonPersistentClass.getSuperMappedSuperclass(); > >>> commonPersistentClass = null; > >>> } > >>> else { > >>> commonPersistentClass = commonPersistentClass. > getSuperclass(); > >>> commonMappedSuperclass = null; > >>> } > >>> } > >>> } > >>> > >>> As you can see the commonMappedSuperclass is not initialized and stays > >>> null! > >>> At this moment c1 is CustomerEntity and c2 is UserGroupEntity. The > >>> hierarchy looks like this: > >>> > >>> Principal > >>> / \ > >>> Usergroup User > >>> | > >>> Customer > >>> > >>> HTH > >>> > >>> > >>> > >>> 2018-02-28 21:52 GMT+02:00 Christian Beikov < > christian.beikov at gmail.com > >>> >: > >>> > >>> > Hey, I saw the comment on the issue. Thanks for reporting. Could you > >>> > maybe post the model that causes this? I'd need to create a > reproducer > >>> > to be able to analyze this further. > >>> > > >>> > > >>> > Mit freundlichen Gr??en, > >>> > ------------------------------------------------------------ > >>> ------------ > >>> > *Christian Beikov* > >>> > Am 28.02.2018 um 20:11 schrieb Petar Tahchiev: > >>> > > Hi guys, > >>> > > I have this exception with latest 5.2.14 (my project runs fine with > >>> > 5.2.13): > >>> > > > >>> > > Caused by: javax.persistence.PersistenceException: > [PersistenceUnit: > >>> > > default] Unable to build Hibernate SessionFactory > >>> > > at > >>> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImp > >>> > l.persistenceException(EntityManagerFactoryBuilderImpl.java:970) > >>> > > at > >>> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderI > >>> mpl.build( > >>> > EntityManagerFactoryBuilderImpl.java:895) > >>> > > at > >>> > > org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceP > >>> > rovider.createContainerEntityManagerFactory(SpringHibernateJ > >>> paPersistenceP > >>> > rovider.java:57) > >>> > > at > >>> > > org.springframework.orm.jpa.LocalContainerEntityManagerFac > toryBean. > >>> > createNativeEntityManagerFactory(LocalContainerEntityManagerFac > >>> > toryBean.java:365) > >>> > > at > >>> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBean. > >>> > buildNativeEntityManagerFactory(AbstractEntityManagerFactory > >>> Bean.java:387) > >>> > > at > >>> > > org.springframework.orm.jpa.AbstractEntityManagerFactoryBe > >>> > an.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:376) > >>> > > at > >>> > > org.springframework.orm.jpa.LocalContainerEntityManagerFac > >>> > toryBean.afterPropertiesSet(LocalContainerEntityManagerFac > >>> > toryBean.java:341) > >>> > > at > >>> > > org.springframework.beans.factory.support.AbstractAutowireCa > >>> pableBeanFac > >>> > tory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1769) > >>> > > at > >>> > > org.springframework.beans.factory.support.AbstractAutowireCa > >>> pableBeanFac > >>> > tory.initializeBean(AbstractAutowireCapableBeanFactory.java:1706) > >>> > > ... 32 more > >>> > > Caused by: org.hibernate.MappingException: Could not instantiate > >>> > persister > >>> > > org.hibernate.persister.entity.SingleTableEntityPersister > >>> > > at > >>> > > org.hibernate.persister.internal.PersisterFactoryImpl. > >>> > createEntityPersister(PersisterFactoryImpl.java:112) > >>> > > at > >>> > > org.hibernate.persister.internal.PersisterFactoryImpl. > >>> > createEntityPersister(PersisterFactoryImpl.java:77) > >>> > > at > >>> > > org.hibernate.metamodel.internal.MetamodelImpl. > >>> > initialize(MetamodelImpl.java:128) > >>> > > at > >>> > > org.hibernate.internal.SessionFactoryImpl.( > >>> > SessionFactoryImpl.java:300) > >>> > > at > >>> > > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build( > >>> > SessionFactoryBuilderImpl.java:460) > >>> > > at > >>> > > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderI > >>> mpl.build( > >>> > EntityManagerFactoryBuilderImpl.java:892) > >>> > > ... 39 more > >>> > > Caused by: java.lang.NullPointerException > >>> > > at > >>> > > org.hibernate.persister.entity.AbstractPropertyMapping. > >>> > getSuperCollection(AbstractPropertyMapping.java:285) > >>> > > at > >>> > > org.hibernate.persister.entity.AbstractPropertyMapping.addPr > >>> opertyPath( > >>> > AbstractPropertyMapping.java:198) > >>> > > at > >>> > > org.hibernate.persister.entity.AbstractPropertyMapping. > >>> > initPropertyPaths(AbstractPropertyMapping.java:395) > >>> > > at > >>> > > org.hibernate.persister.entity.AbstractEntityPersister. > >>> > initOrdinaryPropertyPaths(AbstractEntityPersister.java:2300) > >>> > > at > >>> > > org.hibernate.persister.entity.AbstractEntityPersister. > >>> > initPropertyPaths(AbstractEntityPersister.java:2347) > >>> > > at > >>> > > org.hibernate.persister.entity.AbstractEntityPersister.postC > >>> onstruct( > >>> > AbstractEntityPersister.java:3906) > >>> > > at > >>> > > org.hibernate.persister.entity.SingleTableEntityPersister.( > >>> > SingleTableEntityPersister.java:437) > >>> > > at sun.reflect.GeneratedConstructorAccessor94 > .newInstance(Unkno > >>> wn > >>> > > Source) > >>> > > at > >>> > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance( > >>> > DelegatingConstructorAccessorImpl.java:45) > >>> > > at java.lang.reflect.Constructor. > newInstance(Constructor.java:4 > >>> 23) > >>> > > at > >>> > > org.hibernate.persister.internal.PersisterFactoryImpl. > >>> > createEntityPersister(PersisterFactoryImpl.java:96) > >>> > > ... 44 more > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >>> > >>> > >>> > >>> -- > >>> Regards, Petar! > >>> Karlovo, Bulgaria. > >>> --- > >>> Public PGP Key at: > >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> > >> > > > > > > -- > > Regards, Petar! > > Karlovo, Bulgaria. > > --- > > Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search= > > 0x19658550C3110611 > > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From davide at hibernate.org Mon Mar 5 07:54:03 2018 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 5 Mar 2018 12:54:03 +0000 Subject: [hibernate-dev] NoORM - Improve consistency of our pom files with JBoss parent and WildFly parent In-Reply-To: References: Message-ID: Sure, thanks On Mon, Mar 5, 2018 at 11:37 AM, Guillaume Smet wrote: > Hi, > > So, I started the effort of making our version properties consistent with > JBoss parent/WildFly parent with Search but the idea is to generalize this > to all our NoORM projects and be as consistent as possible between the > projects. > > The idea is to, as much as possible, use the exact same notation as the > other JBoss projects when declaring the version properties of our > dependencies > > You can see what it implies in this diff: > https://github.com/hibernate/hibernate-search/pull/1639/files#diff-600376dffeb79835ede4a0b285078036R184 > > So, from now on, when you need to add new dependencies in Search: > - check if JBoss parent or WildFly parent already contains this dependency, > if so use the exact same property name > - if not, use if it is descriptive and > discriminating enough > - if the package name is used for several artifacts or is not descriptive > enough, use > > My plan is to be done with OGM in 2 weeks and do it for HV 6.1 as I don't > want to do it in a micro. > > So please avoid big pom refactorings in OGM for the next 2 weeks. > Dependency upgrades are OK, I'll merge them along the way. > > Thanks! > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Mar 5 08:26:29 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 5 Mar 2018 13:26:29 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: Message-ID: On 5 March 2018 at 12:27, Guillaume Smet wrote: > Hi, > > So far we had 4 duplicate reports of > https://hibernate.atlassian.net/browse/HHH-12332 (so not counting the users > having seen the bug and not opening a new one). > > I think this issue qualifies as "we should really get a hotfix release > soon". +1 that would be nice, and the most effective way to prevent further noise and pain. > > I let the duplicated issues open for now as I saw a couple of reproducers > and we should check that all the reported cases are fixed once we have a > proper fix. > > Apart from fixing the NPE, the OP has a point when he says there's > something wrong here: > https://github.com/hibernate/hibernate-orm/blame/5.2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractPropertyMapping.java#L277 > . I suspect c1 and c2 should be reassigned somehow. > > Christian, I saw you planned to fix it, what's your plan about it? > > Thanks. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Mar 5 08:53:16 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 5 Mar 2018 13:53:16 +0000 Subject: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises? Message-ID: Issue HHH-12353 was just reported and I have to agree it looks dodgy. Essentially invoking: entityManager.getReference( Person.class ) might not return a type compatible with Person, when Person is final and annotated with @Proxy(proxyClass = AnotherTypeX.class), then AnotherTypeX might be returned and this is not necessarily a subtype of Person. That's ok as I understand we hardly have alternatives, but the EntityManager API for getReference mandates this signature: T getReference(Class entityClass, Object primaryKey) so we're not actually returning the expected type T in all circumstances, confusing compilers and tooling into giving the wrong suggestions. I see some options: a# disallow using @Proxy on a final entity - seems reasonable since the docs warn against pitfalls. b# throw an exception on Person.class being used as parameter, as the user should actually use the proxytype? c# somehow have the proxy still extend the final entity? Option b# seems problematic as it's not obvious to users either, and we would need to return a proxy reference even when there actually is a managed Person instance in the current session. Option c# is probably unrealistic and problematic too, as it would require enhancing of the final class and I guess we can't rely on that consistently. In summary, I believe we should throw a bootstrap exception requiring to remove the `final` modifier on the parent entity. Or challenge the specification :( Thanks, Sanne From guillaume.smet at gmail.com Mon Mar 5 08:55:06 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 5 Mar 2018 14:55:06 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: Message-ID: Hi Christian, On Mon, Mar 5, 2018 at 2:15 PM, Christian Beikov wrote: > > I have a fix for the NPE the user reported, but there is one edge case, > which hasn't been rerported yet as it seems exotic, that I am still trying > to figure out. > I can provide the "partial fix" later today if you like, but I'd prefer to > fix the overall problem before releasing. > I'd say let's try to have a proper global fix, but if it's too long to get the right fix, let's revisit this decision. Just MHO, let's wait for Steve and the others. -- Guillaume From crancran at gmail.com Mon Mar 5 09:20:52 2018 From: crancran at gmail.com (Chris Cranford) Date: Mon, 5 Mar 2018 09:20:52 -0500 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: Message-ID: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> On 03/05/2018 08:26 AM, Sanne Grinovero wrote: > On 5 March 2018 at 12:27, Guillaume Smet > wrote: >> Hi, So far we had 4 duplicate reports of >> https://hibernate.atlassian.net/browse/HHH-12332 (so not counting the >> users having seen the bug and not opening a new one). I think this >> issue qualifies as "we should really get a hotfix release soon". > +1 that would be nice, and the most effective way to prevent further > noise and pain. I also would agree. From andrea at hibernate.org Mon Mar 5 09:35:37 2018 From: andrea at hibernate.org (andrea boriero) Date: Mon, 5 Mar 2018 14:35:37 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: If there are no objections I can manage a release as soon as a fix is ready. On 5 March 2018 at 14:20, Chris Cranford wrote: > On 03/05/2018 08:26 AM, Sanne Grinovero wrote: > > On 5 March 2018 at 12:27, Guillaume Smet > > wrote: > >> Hi, So far we had 4 duplicate reports of > >> https://hibernate.atlassian.net/browse/HHH-12332 (so not counting the > >> users having seen the bug and not opening a new one). I think this > >> issue qualifies as "we should really get a hotfix release soon". > > +1 that would be nice, and the most effective way to prevent further > > noise and pain. > I also would agree. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Mar 5 09:50:08 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Mar 2018 14:50:08 +0000 Subject: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises? In-Reply-To: References: Message-ID: +1 (a) is the only feasible option On Mon, Mar 5, 2018, 7:53 AM Sanne Grinovero wrote: > Issue HHH-12353 was just reported and I have to agree it looks dodgy. > > Essentially invoking: > > entityManager.getReference( Person.class ) > > might not return a type compatible with Person, when Person is final > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then > AnotherTypeX might be returned and this is not necessarily a subtype > of Person. > > That's ok as I understand we hardly have alternatives, but the > EntityManager API for getReference mandates this signature: > > T getReference(Class entityClass, Object primaryKey) > > so we're not actually returning the expected type T in all > circumstances, confusing compilers and tooling into giving the wrong > suggestions. > > I see some options: > a# disallow using @Proxy on a final entity - seems reasonable since > the docs warn against pitfalls. > b# throw an exception on Person.class being used as parameter, as the > user should actually use the proxytype? > c# somehow have the proxy still extend the final entity? > > Option b# seems problematic as it's not obvious to users either, and > we would need to return a proxy reference even when there actually is > a managed Person instance in the current session. > > Option c# is probably unrealistic and problematic too, as it would > require enhancing of the final class and I guess we can't rely on that > consistently. > > In summary, I believe we should throw a bootstrap exception requiring > to remove the `final` modifier on the parent entity. Or challenge the > specification :( > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Mon Mar 5 09:54:25 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 5 Mar 2018 15:54:25 +0100 Subject: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises? In-Reply-To: References: Message-ID: Hey, It's just three and six years, respectively, since we discussed this matter last [1], [2] (wow, I'm feeling old somehow now ;) Detecting the situation at boot time and raising an exception early on would be the best. --Gunnar [1] http://lists.jboss.org/pipermail/hibernate-dev/2015-April/012520.html [2] http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007629.html 2018-03-05 14:53 GMT+01:00 Sanne Grinovero : > Issue HHH-12353 was just reported and I have to agree it looks dodgy. > > Essentially invoking: > > entityManager.getReference( Person.class ) > > might not return a type compatible with Person, when Person is final > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then > AnotherTypeX might be returned and this is not necessarily a subtype > of Person. > > That's ok as I understand we hardly have alternatives, but the > EntityManager API for getReference mandates this signature: > > T getReference(Class entityClass, Object primaryKey) > > so we're not actually returning the expected type T in all > circumstances, confusing compilers and tooling into giving the wrong > suggestions. > > I see some options: > a# disallow using @Proxy on a final entity - seems reasonable since > the docs warn against pitfalls. > b# throw an exception on Person.class being used as parameter, as the > user should actually use the proxytype? > c# somehow have the proxy still extend the final entity? > > Option b# seems problematic as it's not obvious to users either, and > we would need to return a proxy reference even when there actually is > a managed Person instance in the current session. > > Option c# is probably unrealistic and problematic too, as it would > require enhancing of the final class and I guess we can't rely on that > consistently. > > In summary, I believe we should throw a bootstrap exception requiring > to remove the `final` modifier on the parent entity. Or challenge the > specification :( > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Mar 5 10:24:04 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Mar 2018 15:24:04 +0000 Subject: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises? In-Reply-To: References: Message-ID: Fun trip down memory lane :) No one really like my proposed solution, but also no one really seemed to dislike it enough to implement something themselves ;) Anyway, those older discussions are a piece of the same overall discussion that this one belongs to. This discussion is just a specific part of it. Sanne and I both thought that the API should just accept the interface - we just had different opinions about how that should work in mapping and in the impl of the call. Neither of our suggestions is spec compliant though. And in this specific case I think (a) is the only real option On Mon, Mar 5, 2018 at 8:57 AM Gunnar Morling wrote: > Hey, > > It's just three and six years, respectively, since we discussed this matter > last [1], [2] (wow, I'm feeling old somehow now ;) > > Detecting the situation at boot time and raising an exception early on > would be the best. > > --Gunnar > > [1] http://lists.jboss.org/pipermail/hibernate-dev/2015-April/012520.html > [2] > http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007629.html > > > 2018-03-05 14:53 GMT+01:00 Sanne Grinovero : > > > Issue HHH-12353 was just reported and I have to agree it looks dodgy. > > > > Essentially invoking: > > > > entityManager.getReference( Person.class ) > > > > might not return a type compatible with Person, when Person is final > > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then > > AnotherTypeX might be returned and this is not necessarily a subtype > > of Person. > > > > That's ok as I understand we hardly have alternatives, but the > > EntityManager API for getReference mandates this signature: > > > > T getReference(Class entityClass, Object primaryKey) > > > > so we're not actually returning the expected type T in all > > circumstances, confusing compilers and tooling into giving the wrong > > suggestions. > > > > I see some options: > > a# disallow using @Proxy on a final entity - seems reasonable since > > the docs warn against pitfalls. > > b# throw an exception on Person.class being used as parameter, as the > > user should actually use the proxytype? > > c# somehow have the proxy still extend the final entity? > > > > Option b# seems problematic as it's not obvious to users either, and > > we would need to return a proxy reference even when there actually is > > a managed Person instance in the current session. > > > > Option c# is probably unrealistic and problematic too, as it would > > require enhancing of the final class and I guess we can't rely on that > > consistently. > > > > In summary, I believe we should throw a bootstrap exception requiring > > to remove the `final` modifier on the parent entity. Or challenge the > > specification :( > > > > Thanks, > > Sanne > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Mar 5 10:28:38 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Mar 2018 15:28:38 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: I agree that in general it is ok to cut a release with a partial solution in a case like this On Mon, Mar 5, 2018 at 8:40 AM andrea boriero wrote: > If there are no objections I can manage a release as soon as a fix is > ready. > > On 5 March 2018 at 14:20, Chris Cranford wrote: > > > On 03/05/2018 08:26 AM, Sanne Grinovero wrote: > > > On 5 March 2018 at 12:27, Guillaume Smet > > > wrote: > > >> Hi, So far we had 4 duplicate reports of > > >> https://hibernate.atlassian.net/browse/HHH-12332 (so not counting the > > >> users having seen the bug and not opening a new one). I think this > > >> issue qualifies as "we should really get a hotfix release soon". > > > +1 that would be nice, and the most effective way to prevent further > > > noise and pain. > > I also would agree. > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Mar 5 10:32:30 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 5 Mar 2018 15:32:30 +0000 Subject: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises? In-Reply-To: References: Message-ID: On 5 March 2018 at 15:24, Steve Ebersole wrote: > Fun trip down memory lane :) > > No one really like my proposed solution, but also no one really seemed to > dislike it enough to implement something themselves ;) > > Anyway, those older discussions are a piece of the same overall discussion > that this one belongs to. This discussion is just a specific part of it. > Sanne and I both thought that the API should just accept the interface - we > just had different opinions about how that should work in mapping and in the > impl of the call. Neither of our suggestions is spec compliant though. And > in this specific case I think (a) is the only real option Right, the JPA API doesn't leave much room to explore the alternatives we discussed in the past. What do you suggest we do now? In a nudge towards backwards compatibility it would be nice to start logging a bootstrap warning when a final class is being declared with such a proxy: we could warn about the inconsistent return that will happen at runtime, and would also be a good opportunity to warn we might remove support for such a tricky mapping altogether in a future release. And thanks Gunnar for finding the previous discussions, I had a vague idea we discussed this before :) Sanne > > On Mon, Mar 5, 2018 at 8:57 AM Gunnar Morling wrote: >> >> Hey, >> >> It's just three and six years, respectively, since we discussed this >> matter >> last [1], [2] (wow, I'm feeling old somehow now ;) >> >> Detecting the situation at boot time and raising an exception early on >> would be the best. >> >> --Gunnar >> >> [1] http://lists.jboss.org/pipermail/hibernate-dev/2015-April/012520.html >> [2] >> http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007629.html >> >> >> 2018-03-05 14:53 GMT+01:00 Sanne Grinovero : >> >> > Issue HHH-12353 was just reported and I have to agree it looks dodgy. >> > >> > Essentially invoking: >> > >> > entityManager.getReference( Person.class ) >> > >> > might not return a type compatible with Person, when Person is final >> > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then >> > AnotherTypeX might be returned and this is not necessarily a subtype >> > of Person. >> > >> > That's ok as I understand we hardly have alternatives, but the >> > EntityManager API for getReference mandates this signature: >> > >> > T getReference(Class entityClass, Object primaryKey) >> > >> > so we're not actually returning the expected type T in all >> > circumstances, confusing compilers and tooling into giving the wrong >> > suggestions. >> > >> > I see some options: >> > a# disallow using @Proxy on a final entity - seems reasonable since >> > the docs warn against pitfalls. >> > b# throw an exception on Person.class being used as parameter, as the >> > user should actually use the proxytype? >> > c# somehow have the proxy still extend the final entity? >> > >> > Option b# seems problematic as it's not obvious to users either, and >> > we would need to return a proxy reference even when there actually is >> > a managed Person instance in the current session. >> > >> > Option c# is probably unrealistic and problematic too, as it would >> > require enhancing of the final class and I guess we can't rely on that >> > consistently. >> > >> > In summary, I believe we should throw a bootstrap exception requiring >> > to remove the `final` modifier on the parent entity. Or challenge the >> > specification :( >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Mon Mar 5 10:42:34 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Mar 2018 15:42:34 +0000 Subject: [hibernate-dev] HHH-12353: have getReference stick to the Java API it promises? In-Reply-To: References: Message-ID: Sure, I think using DeprecationLogger is a good short-term option. On Mon, Mar 5, 2018 at 9:32 AM Sanne Grinovero wrote: > On 5 March 2018 at 15:24, Steve Ebersole wrote: > > Fun trip down memory lane :) > > > > No one really like my proposed solution, but also no one really seemed to > > dislike it enough to implement something themselves ;) > > > > Anyway, those older discussions are a piece of the same overall > discussion > > that this one belongs to. This discussion is just a specific part of it. > > Sanne and I both thought that the API should just accept the interface - > we > > just had different opinions about how that should work in mapping and in > the > > impl of the call. Neither of our suggestions is spec compliant though. > And > > in this specific case I think (a) is the only real option > > Right, the JPA API doesn't leave much room to explore the alternatives > we discussed in the past. > > What do you suggest we do now? > > In a nudge towards backwards compatibility it would be nice to start > logging a bootstrap warning when a final class is being declared with > such a proxy: we could warn about the inconsistent return that will > happen at runtime, and would also be a good opportunity to warn we > might remove support for such a tricky mapping altogether in a future > release. > > And thanks Gunnar for finding the previous discussions, I had a vague > idea we discussed this before :) > > Sanne > > > > > > > On Mon, Mar 5, 2018 at 8:57 AM Gunnar Morling > wrote: > >> > >> Hey, > >> > >> It's just three and six years, respectively, since we discussed this > >> matter > >> last [1], [2] (wow, I'm feeling old somehow now ;) > >> > >> Detecting the situation at boot time and raising an exception early on > >> would be the best. > >> > >> --Gunnar > >> > >> [1] > http://lists.jboss.org/pipermail/hibernate-dev/2015-April/012520.html > >> [2] > >> http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007629.html > >> > >> > >> 2018-03-05 14:53 GMT+01:00 Sanne Grinovero : > >> > >> > Issue HHH-12353 was just reported and I have to agree it looks dodgy. > >> > > >> > Essentially invoking: > >> > > >> > entityManager.getReference( Person.class ) > >> > > >> > might not return a type compatible with Person, when Person is final > >> > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then > >> > AnotherTypeX might be returned and this is not necessarily a subtype > >> > of Person. > >> > > >> > That's ok as I understand we hardly have alternatives, but the > >> > EntityManager API for getReference mandates this signature: > >> > > >> > T getReference(Class entityClass, Object primaryKey) > >> > > >> > so we're not actually returning the expected type T in all > >> > circumstances, confusing compilers and tooling into giving the wrong > >> > suggestions. > >> > > >> > I see some options: > >> > a# disallow using @Proxy on a final entity - seems reasonable since > >> > the docs warn against pitfalls. > >> > b# throw an exception on Person.class being used as parameter, as the > >> > user should actually use the proxytype? > >> > c# somehow have the proxy still extend the final entity? > >> > > >> > Option b# seems problematic as it's not obvious to users either, and > >> > we would need to return a proxy reference even when there actually is > >> > a managed Person instance in the current session. > >> > > >> > Option c# is probably unrealistic and problematic too, as it would > >> > require enhancing of the final class and I guess we can't rely on that > >> > consistently. > >> > > >> > In summary, I believe we should throw a bootstrap exception requiring > >> > to remove the `final` modifier on the parent entity. Or challenge the > >> > specification :( > >> > > >> > Thanks, > >> > Sanne > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Mon Mar 5 11:46:27 2018 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 5 Mar 2018 11:46:27 -0500 Subject: [hibernate-dev] 5.3 finalization plan In-Reply-To: References: Message-ID: <0dafeea1-e61b-4357-0dfb-718f8d68fbc6@redhat.com> On 03/01/2018 02:37 PM, Steve Ebersole wrote: > In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified > discussion about the remaining currently unresolved discussions and what > exactly we are going to do for 5.3 mainly in regards to compatibility with > an eye to 6.0 > > > > Cache region-name as exposed in API/SPI > > This one is a "sneaky" compatibility concern. When discussing this, it > seems like we had a consensus that the way this should work is for the name > passed in to be un-prefixed. Unfortunately the current behavior is to > accept the qualified region name. IMO we should change this. However, > there is a big danger in that : it would introduce a run-time behavior > incompatibility, as opposed to a compile one, which in a way is worse. See > the new test I just added to master for examples of what I mean > - org.hibernate.test.cache.RegionNameTest > > One option for compatibility is to introduce a new compatibility flag for > this. Something like "hibernate.cache.region_name_api_prefixed" > (true/false). Or a better way might be to accept either, and to avoid the > extra perf hit of add a new setting to disallow calls with the prefixed > name. > > Also Sanne brought up the idea of ORM simply no longer dealing with prefix > (this is at odds with the current API/SPI calls as tested). > > Other thoughts/ideas? Will the different cache providers need to get the cache prefix from the session factory instead? > > > Caching > > It was decided to include HHH-11356[1] (cache SPI redesign) in 5.3. See > the Jira for details. > > > Statistics (caching) > > HHH-11356 redefines how regions and access strategies are structured, > related and accessed. I won't get too in to the details here (read the > Jira if interested) but that required changes to other code that uses the > SPI. Most of those are internal and were easy to adjust. However > Statistics, as a consumer of these regions and access strategies, also > required some changes. HHH-12323[2] is the Jira for these changes. > > Again the see the Jira for details. > > > Type System > > The other major change for 6.0 is the metamodel, type system change. This > one is pervasive. All of the strategies to bridge Type and read-by-name / > read-by-position, imo, are not feasible. > > The changes in the run-time metamodel are too much to bridge, which is a > complicating factor. Right down to PersisterFactory. > > > > P.S. where there is already a Jira it would be best if we can keep the > discussions on the Jira itself. > > > [1] https://hibernate.atlassian.net/browse/HHH-11356 > [2] https://hibernate.atlassian.net/browse/HHH-11356 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Mar 5 11:47:41 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 05 Mar 2018 16:47:41 +0000 Subject: [hibernate-dev] 5.3 finalization plan In-Reply-To: <0dafeea1-e61b-4357-0dfb-718f8d68fbc6@redhat.com> References: <0dafeea1-e61b-4357-0dfb-718f8d68fbc6@redhat.com> Message-ID: My preference is for the providers to handle that, yes. I have already spoken with the Ehcache devs. I have reached out to the Infinispan team but have not heard back On Mon, Mar 5, 2018 at 10:46 AM Scott Marlow wrote: > > > On 03/01/2018 02:37 PM, Steve Ebersole wrote: > > In 2 weeks I will be releasing 5.3 CR2. I waned to start a unified > > discussion about the remaining currently unresolved discussions and what > > exactly we are going to do for 5.3 mainly in regards to compatibility > with > > an eye to 6.0 > > > > > > > > Cache region-name as exposed in API/SPI > > > > This one is a "sneaky" compatibility concern. When discussing this, it > > seems like we had a consensus that the way this should work is for the > name > > passed in to be un-prefixed. Unfortunately the current behavior is to > > accept the qualified region name. IMO we should change this. However, > > there is a big danger in that : it would introduce a run-time behavior > > incompatibility, as opposed to a compile one, which in a way is worse. > See > > the new test I just added to master for examples of what I mean > > - org.hibernate.test.cache.RegionNameTest > > > > One option for compatibility is to introduce a new compatibility flag for > > this. Something like "hibernate.cache.region_name_api_prefixed" > > (true/false). Or a better way might be to accept either, and to avoid > the > > extra perf hit of add a new setting to disallow calls with the prefixed > > name. > > > > Also Sanne brought up the idea of ORM simply no longer dealing with > prefix > > (this is at odds with the current API/SPI calls as tested). > > > > Other thoughts/ideas? > > Will the different cache providers need to get the cache prefix from the > session factory instead? > > > > > > > Caching > > > > It was decided to include HHH-11356[1] (cache SPI redesign) in 5.3. See > > the Jira for details. > > > > > > Statistics (caching) > > > > HHH-11356 redefines how regions and access strategies are structured, > > related and accessed. I won't get too in to the details here (read the > > Jira if interested) but that required changes to other code that uses the > > SPI. Most of those are internal and were easy to adjust. However > > Statistics, as a consumer of these regions and access strategies, also > > required some changes. HHH-12323[2] is the Jira for these changes. > > > > Again the see the Jira for details. > > > > > > Type System > > > > The other major change for 6.0 is the metamodel, type system change. > This > > one is pervasive. All of the strategies to bridge Type and read-by-name > / > > read-by-position, imo, are not feasible. > > > > The changes in the run-time metamodel are too much to bridge, which is a > > complicating factor. Right down to PersisterFactory. > > > > > > > > P.S. where there is already a Jira it would be best if we can keep the > > discussions on the Jira itself. > > > > > > [1] https://hibernate.atlassian.net/browse/HHH-11356 > > [2] https://hibernate.atlassian.net/browse/HHH-11356 > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From gbadner at redhat.com Mon Mar 5 13:54:32 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 5 Mar 2018 10:54:32 -0800 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: +1 to a quick release, with a partial solution if necessary. On Mon, Mar 5, 2018 at 7:28 AM, Steve Ebersole wrote: > I agree that in general it is ok to cut a release with a partial solution > in a case like this > > On Mon, Mar 5, 2018 at 8:40 AM andrea boriero > wrote: > > > If there are no objections I can manage a release as soon as a fix is > > ready. > > > > On 5 March 2018 at 14:20, Chris Cranford wrote: > > > > > On 03/05/2018 08:26 AM, Sanne Grinovero wrote: > > > > On 5 March 2018 at 12:27, Guillaume Smet > > > > wrote: > > > >> Hi, So far we had 4 duplicate reports of > > > >> https://hibernate.atlassian.net/browse/HHH-12332 (so not counting > the > > > >> users having seen the bug and not opening a new one). I think this > > > >> issue qualifies as "we should really get a hotfix release soon". > > > > +1 that would be nice, and the most effective way to prevent further > > > > noise and pain. > > > I also would agree. > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Mar 5 17:16:09 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 5 Mar 2018 23:16:09 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: Just so that nobody misses it, Christian pushed a PR here: https://github.com/hibernate/hibernate-orm/pull/2180 . Will require someone more familiar with ORM than me to review it :). Thanks. On Mon, Mar 5, 2018 at 7:54 PM, Gail Badner wrote: > +1 to a quick release, with a partial solution if necessary. > > On Mon, Mar 5, 2018 at 7:28 AM, Steve Ebersole > wrote: > > > I agree that in general it is ok to cut a release with a partial solution > > in a case like this > > > > On Mon, Mar 5, 2018 at 8:40 AM andrea boriero > > wrote: > > > > > If there are no objections I can manage a release as soon as a fix is > > > ready. > > > > > > On 5 March 2018 at 14:20, Chris Cranford wrote: > > > > > > > On 03/05/2018 08:26 AM, Sanne Grinovero wrote: > > > > > On 5 March 2018 at 12:27, Guillaume Smet > > > > > > wrote: > > > > >> Hi, So far we had 4 duplicate reports of > > > > >> https://hibernate.atlassian.net/browse/HHH-12332 (so not counting > > the > > > > >> users having seen the bug and not opening a new one). I think this > > > > >> issue qualifies as "we should really get a hotfix release soon". > > > > > +1 that would be nice, and the most effective way to prevent > further > > > > > noise and pain. > > > > I also would agree. > > > > _______________________________________________ > > > > hibernate-dev mailing list > > > > hibernate-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Mar 6 05:57:36 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 6 Mar 2018 11:57:36 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: Hi, So, AFAICS, Andrea found another failing case for the new PR. I would vote for reverting the original patch [ https://hibernate.atlassian.net/browse/HHH-11544] for now and let Christian the time to think of a proper fix. I'm a bit worried we will miss something if we try to find a fix in a hurry. AFAICS, the original issue was a bit of a corner case so better get the other more common cases working. Anyone against reverting the original patch? Christian? -- Guillaume On Mon, Mar 5, 2018 at 11:16 PM, Guillaume Smet wrote: > Just so that nobody misses it, Christian pushed a PR here: > https://github.com/hibernate/hibernate-orm/pull/2180 . > > Will require someone more familiar with ORM than me to review it :). > > Thanks. > > On Mon, Mar 5, 2018 at 7:54 PM, Gail Badner wrote: > >> +1 to a quick release, with a partial solution if necessary. >> >> On Mon, Mar 5, 2018 at 7:28 AM, Steve Ebersole >> wrote: >> >> > I agree that in general it is ok to cut a release with a partial >> solution >> > in a case like this >> > >> > On Mon, Mar 5, 2018 at 8:40 AM andrea boriero >> > wrote: >> > >> > > If there are no objections I can manage a release as soon as a fix is >> > > ready. >> > > >> > > On 5 March 2018 at 14:20, Chris Cranford wrote: >> > > >> > > > On 03/05/2018 08:26 AM, Sanne Grinovero wrote: >> > > > > On 5 March 2018 at 12:27, Guillaume Smet < >> guillaume.smet at gmail.com> >> > > > > wrote: >> > > > >> Hi, So far we had 4 duplicate reports of >> > > > >> https://hibernate.atlassian.net/browse/HHH-12332 (so not >> counting >> > the >> > > > >> users having seen the bug and not opening a new one). I think >> this >> > > > >> issue qualifies as "we should really get a hotfix release soon". >> > > > > +1 that would be nice, and the most effective way to prevent >> further >> > > > > noise and pain. >> > > > I also would agree. >> > > > _______________________________________________ >> > > > hibernate-dev mailing list >> > > > hibernate-dev at lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > > >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From andrea at hibernate.org Tue Mar 6 06:15:32 2018 From: andrea at hibernate.org (andrea boriero) Date: Tue, 6 Mar 2018 11:15:32 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: nothing against reverting the PR that caused this issue. On 6 March 2018 at 10:57, Guillaume Smet wrote: > Hi, > > So, AFAICS, Andrea found another failing case for the new PR. > > I would vote for reverting the original patch [ > https://hibernate.atlassian.net/browse/HHH-11544] for now and let > Christian the time to think of a proper fix. I'm a bit worried we will miss > something if we try to find a fix in a hurry. > > AFAICS, the original issue was a bit of a corner case so better get the > other more common cases working. > > Anyone against reverting the original patch? Christian? > > -- > Guillaume > > On Mon, Mar 5, 2018 at 11:16 PM, Guillaume Smet > wrote: > >> Just so that nobody misses it, Christian pushed a PR here: >> https://github.com/hibernate/hibernate-orm/pull/2180 . >> >> Will require someone more familiar with ORM than me to review it :). >> >> Thanks. >> >> On Mon, Mar 5, 2018 at 7:54 PM, Gail Badner wrote: >> >>> +1 to a quick release, with a partial solution if necessary. >>> >>> On Mon, Mar 5, 2018 at 7:28 AM, Steve Ebersole >>> wrote: >>> >>> > I agree that in general it is ok to cut a release with a partial >>> solution >>> > in a case like this >>> > >>> > On Mon, Mar 5, 2018 at 8:40 AM andrea boriero >>> > wrote: >>> > >>> > > If there are no objections I can manage a release as soon as a fix is >>> > > ready. >>> > > >>> > > On 5 March 2018 at 14:20, Chris Cranford wrote: >>> > > >>> > > > On 03/05/2018 08:26 AM, Sanne Grinovero wrote: >>> > > > > On 5 March 2018 at 12:27, Guillaume Smet < >>> guillaume.smet at gmail.com> >>> > > > > wrote: >>> > > > >> Hi, So far we had 4 duplicate reports of >>> > > > >> https://hibernate.atlassian.net/browse/HHH-12332 (so not >>> counting >>> > the >>> > > > >> users having seen the bug and not opening a new one). I think >>> this >>> > > > >> issue qualifies as "we should really get a hotfix release soon". >>> > > > > +1 that would be nice, and the most effective way to prevent >>> further >>> > > > > noise and pain. >>> > > > I also would agree. >>> > > > _______________________________________________ >>> > > > hibernate-dev mailing list >>> > > > hibernate-dev at lists.jboss.org >>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > > >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > > >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > From christian.beikov at gmail.com Tue Mar 6 06:21:29 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Tue, 6 Mar 2018 12:21:29 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> Message-ID: <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Hey, I'm fine with reverting the patch as well, though I just fixed the issue Andrea found and am confident about the solution now. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 06.03.2018 um 11:57 schrieb Guillaume Smet: > Hi, > > So, AFAICS, Andrea found another failing case for the new PR. > > I would vote for reverting the original patch [ > https://hibernate.atlassian.net/browse/HHH-11544] for now and let Christian > the time to think of a proper fix. I'm a bit worried we will miss something > if we try to find a fix in a hurry. > > AFAICS, the original issue was a bit of a corner case so better get the > other more common cases working. > > Anyone against reverting the original patch? Christian? > From sanne at hibernate.org Tue Mar 6 08:23:49 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 6 Mar 2018 13:23:49 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: On 6 March 2018 at 11:21, Christian Beikov wrote: > Hey, > > I'm fine with reverting the patch as well, though I just fixed the issue > Andrea found and am confident about the solution now. Hi Christian, that's great! Let's go with your fix then. Thanks, Sanne > > > Mit freundlichen Gr??en, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 06.03.2018 um 11:57 schrieb Guillaume Smet: >> Hi, >> >> So, AFAICS, Andrea found another failing case for the new PR. >> >> I would vote for reverting the original patch [ >> https://hibernate.atlassian.net/browse/HHH-11544] for now and let Christian >> the time to think of a proper fix. I'm a bit worried we will miss something >> if we try to find a fix in a hurry. >> >> AFAICS, the original issue was a bit of a corner case so better get the >> other more common cases working. >> >> Anyone against reverting the original patch? Christian? >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Mar 6 08:44:49 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 06 Mar 2018 13:44:49 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: +1 If you are confident, that's good for me On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero wrote: > On 6 March 2018 at 11:21, Christian Beikov > wrote: > > Hey, > > > > I'm fine with reverting the patch as well, though I just fixed the issue > > Andrea found and am confident about the solution now. > > Hi Christian, that's great! Let's go with your fix then. > > Thanks, > Sanne > > > > > > > > Mit freundlichen Gr??en, > > ------------------------------------------------------------------------ > > *Christian Beikov* > > Am 06.03.2018 um 11:57 schrieb Guillaume Smet: > >> Hi, > >> > >> So, AFAICS, Andrea found another failing case for the new PR. > >> > >> I would vote for reverting the original patch [ > >> https://hibernate.atlassian.net/browse/HHH-11544] for now and let > Christian > >> the time to think of a proper fix. I'm a bit worried we will miss > something > >> if we try to find a fix in a hurry. > >> > >> AFAICS, the original issue was a bit of a corner case so better get the > >> other more common cases working. > >> > >> Anyone against reverting the original patch? Christian? > >> > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Tue Mar 6 14:13:45 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 6 Mar 2018 11:13:45 -0800 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: When are you planning to release? I'd like to take a look at the original fix and PR as well. On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole wrote: > +1 > > If you are confident, that's good for me > > > On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero wrote: > > > On 6 March 2018 at 11:21, Christian Beikov > > wrote: > > > Hey, > > > > > > I'm fine with reverting the patch as well, though I just fixed the > issue > > > Andrea found and am confident about the solution now. > > > > Hi Christian, that's great! Let's go with your fix then. > > > > Thanks, > > Sanne > > > > > > > > > > > > > Mit freundlichen Gr??en, > > > ------------------------------------------------------------ > ------------ > > > *Christian Beikov* > > > Am 06.03.2018 um 11:57 schrieb Guillaume Smet: > > >> Hi, > > >> > > >> So, AFAICS, Andrea found another failing case for the new PR. > > >> > > >> I would vote for reverting the original patch [ > > >> https://hibernate.atlassian.net/browse/HHH-11544] for now and let > > Christian > > >> the time to think of a proper fix. I'm a bit worried we will miss > > something > > >> if we try to find a fix in a hurry. > > >> > > >> AFAICS, the original issue was a bit of a corner case so better get > the > > >> other more common cases working. > > >> > > >> Anyone against reverting the original patch? Christian? > > >> > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From chris at hibernate.org Tue Mar 6 14:32:59 2018 From: chris at hibernate.org (Chris Cranford) Date: Tue, 6 Mar 2018 14:32:59 -0500 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: Gail - I asked Andrea earlier and he hoped Wednesday March 7th; however he did say it depends on the status of Christian's fix. On 03/06/2018 02:13 PM, Gail Badner wrote: > When are you planning to release? I'd like to take a look at the original > fix and PR as well. > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole wrote: > >> +1 >> >> If you are confident, that's good for me >> >> >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero wrote: >> >>> On 6 March 2018 at 11:21, Christian Beikov >>> wrote: >>>> Hey, >>>> >>>> I'm fine with reverting the patch as well, though I just fixed the >> issue >>>> Andrea found and am confident about the solution now. >>> Hi Christian, that's great! Let's go with your fix then. >>> >>> Thanks, >>> Sanne >>> >>> >>>> >>>> Mit freundlichen Gr??en, >>>> ------------------------------------------------------------ >> ------------ >>>> *Christian Beikov* >>>> Am 06.03.2018 um 11:57 schrieb Guillaume Smet: >>>>> Hi, >>>>> >>>>> So, AFAICS, Andrea found another failing case for the new PR. >>>>> >>>>> I would vote for reverting the original patch [ >>>>> https://hibernate.atlassian.net/browse/HHH-11544] for now and let >>> Christian >>>>> the time to think of a proper fix. I'm a bit worried we will miss >>> something >>>>> if we try to find a fix in a hurry. >>>>> >>>>> AFAICS, the original issue was a bit of a corner case so better get >> the >>>>> other more common cases working. >>>>> >>>>> Anyone against reverting the original patch? Christian? >>>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Wed Mar 7 06:11:49 2018 From: andrea at hibernate.org (andrea boriero) Date: Wed, 7 Mar 2018 11:11:49 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: sorry but I had an horrible night and not feeling great right now so I'll do the release late this afternoon or tomorrow morning. On 6 March 2018 at 19:32, Chris Cranford wrote: > Gail - > > I asked Andrea earlier and he hoped Wednesday March 7th; however he did > say it depends on the status of Christian's fix. > > On 03/06/2018 02:13 PM, Gail Badner wrote: > > When are you planning to release? I'd like to take a look at the original > > fix and PR as well. > > > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole > wrote: > > > >> +1 > >> > >> If you are confident, that's good for me > >> > >> > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero > wrote: > >> > >>> On 6 March 2018 at 11:21, Christian Beikov > > >>> wrote: > >>>> Hey, > >>>> > >>>> I'm fine with reverting the patch as well, though I just fixed the > >> issue > >>>> Andrea found and am confident about the solution now. > >>> Hi Christian, that's great! Let's go with your fix then. > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>>> > >>>> Mit freundlichen Gr??en, > >>>> ------------------------------------------------------------ > >> ------------ > >>>> *Christian Beikov* > >>>> Am 06.03.2018 um 11:57 schrieb Guillaume Smet: > >>>>> Hi, > >>>>> > >>>>> So, AFAICS, Andrea found another failing case for the new PR. > >>>>> > >>>>> I would vote for reverting the original patch [ > >>>>> https://hibernate.atlassian.net/browse/HHH-11544] for now and let > >>> Christian > >>>>> the time to think of a proper fix. I'm a bit worried we will miss > >>> something > >>>>> if we try to find a fix in a hurry. > >>>>> > >>>>> AFAICS, the original issue was a bit of a corner case so better get > >> the > >>>>> other more common cases working. > >>>>> > >>>>> Anyone against reverting the original patch? Christian? > >>>>> > >>>> _______________________________________________ > >>>> hibernate-dev mailing list > >>>> hibernate-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Wed Mar 7 07:25:41 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 7 Mar 2018 13:25:41 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: Apparently, there is still an issue with the latest fix but a different one: https://hibernate.atlassian.net/browse/HHH-12332?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=101427#comment-101427 I posted a message to try to help the OP isolating the issue. I know it's not very satisfactory but I would really prefer that we revert this all for now. It's too risky just to fix a corner case. -- Guillaume On Wed, Mar 7, 2018 at 12:11 PM, andrea boriero wrote: > sorry but I had an horrible night and not feeling great right now so I'll > do the release late this afternoon or tomorrow morning. > > On 6 March 2018 at 19:32, Chris Cranford wrote: > > > Gail - > > > > I asked Andrea earlier and he hoped Wednesday March 7th; however he did > > say it depends on the status of Christian's fix. > > > > On 03/06/2018 02:13 PM, Gail Badner wrote: > > > When are you planning to release? I'd like to take a look at the > original > > > fix and PR as well. > > > > > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole > > wrote: > > > > > >> +1 > > >> > > >> If you are confident, that's good for me > > >> > > >> > > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero > > wrote: > > >> > > >>> On 6 March 2018 at 11:21, Christian Beikov < > christian.beikov at gmail.com > > > > > >>> wrote: > > >>>> Hey, > > >>>> > > >>>> I'm fine with reverting the patch as well, though I just fixed the > > >> issue > > >>>> Andrea found and am confident about the solution now. > > >>> Hi Christian, that's great! Let's go with your fix then. > > >>> > > >>> Thanks, > > >>> Sanne > > >>> > > >>> > > >>>> > > >>>> Mit freundlichen Gr??en, > > >>>> ------------------------------------------------------------ > > >> ------------ > > >>>> *Christian Beikov* > > >>>> Am 06.03.2018 um 11:57 schrieb Guillaume Smet: > > >>>>> Hi, > > >>>>> > > >>>>> So, AFAICS, Andrea found another failing case for the new PR. > > >>>>> > > >>>>> I would vote for reverting the original patch [ > > >>>>> https://hibernate.atlassian.net/browse/HHH-11544] for now and let > > >>> Christian > > >>>>> the time to think of a proper fix. I'm a bit worried we will miss > > >>> something > > >>>>> if we try to find a fix in a hurry. > > >>>>> > > >>>>> AFAICS, the original issue was a bit of a corner case so better get > > >> the > > >>>>> other more common cases working. > > >>>>> > > >>>>> Anyone against reverting the original patch? Christian? > > >>>>> > > >>>> _______________________________________________ > > >>>> hibernate-dev mailing list > > >>>> hibernate-dev at lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >>> _______________________________________________ > > >>> hibernate-dev mailing list > > >>> hibernate-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Wed Mar 7 07:39:15 2018 From: andrea at hibernate.org (andrea boriero) Date: Wed, 7 Mar 2018 12:39:15 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: I agree with the revert solution Guillaume proposed. On 7 March 2018 at 12:25, Guillaume Smet wrote: > Apparently, there is still an issue with the latest fix but a different > one: > https://hibernate.atlassian.net/browse/HHH-12332?page=com. > atlassian.jira.plugin.system.issuetabpanels%3Acomment- > tabpanel&focusedCommentId=101427#comment-101427 > > I posted a message to try to help the OP isolating the issue. > > I know it's not very satisfactory but I would really prefer that we revert > this all for now. It's too risky just to fix a corner case. > > -- > Guillaume > > On Wed, Mar 7, 2018 at 12:11 PM, andrea boriero > wrote: > >> sorry but I had an horrible night and not feeling great right now so I'll >> do the release late this afternoon or tomorrow morning. >> >> On 6 March 2018 at 19:32, Chris Cranford wrote: >> >> > Gail - >> > >> > I asked Andrea earlier and he hoped Wednesday March 7th; however he did >> > say it depends on the status of Christian's fix. >> > >> > On 03/06/2018 02:13 PM, Gail Badner wrote: >> > > When are you planning to release? I'd like to take a look at the >> original >> > > fix and PR as well. >> > > >> > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole >> > wrote: >> > > >> > >> +1 >> > >> >> > >> If you are confident, that's good for me >> > >> >> > >> >> > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero >> > wrote: >> > >> >> > >>> On 6 March 2018 at 11:21, Christian Beikov < >> christian.beikov at gmail.com >> > > >> > >>> wrote: >> > >>>> Hey, >> > >>>> >> > >>>> I'm fine with reverting the patch as well, though I just fixed the >> > >> issue >> > >>>> Andrea found and am confident about the solution now. >> > >>> Hi Christian, that's great! Let's go with your fix then. >> > >>> >> > >>> Thanks, >> > >>> Sanne >> > >>> >> > >>> >> > >>>> >> > >>>> Mit freundlichen Gr??en, >> > >>>> ------------------------------------------------------------ >> > >> ------------ >> > >>>> *Christian Beikov* >> > >>>> Am 06.03.2018 um 11:57 schrieb Guillaume Smet: >> > >>>>> Hi, >> > >>>>> >> > >>>>> So, AFAICS, Andrea found another failing case for the new PR. >> > >>>>> >> > >>>>> I would vote for reverting the original patch [ >> > >>>>> https://hibernate.atlassian.net/browse/HHH-11544] for now and let >> > >>> Christian >> > >>>>> the time to think of a proper fix. I'm a bit worried we will miss >> > >>> something >> > >>>>> if we try to find a fix in a hurry. >> > >>>>> >> > >>>>> AFAICS, the original issue was a bit of a corner case so better >> get >> > >> the >> > >>>>> other more common cases working. >> > >>>>> >> > >>>>> Anyone against reverting the original patch? Christian? >> > >>>>> >> > >>>> _______________________________________________ >> > >>>> hibernate-dev mailing list >> > >>>> hibernate-dev at lists.jboss.org >> > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >>> _______________________________________________ >> > >>> hibernate-dev mailing list >> > >>> hibernate-dev at lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> > >> hibernate-dev mailing list >> > >> hibernate-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> >> > > _______________________________________________ >> > > hibernate-dev mailing list >> > > hibernate-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From sanne at hibernate.org Wed Mar 7 07:53:12 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 7 Mar 2018 12:53:12 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: Let's not rush things and see what Christian thinks: he should be allowed to analyze this - if he has time and wants to - w/o too much pressure. I see the last report is an NPE, that's typically not too hard to fix so I'd rather try again. The risk with a full revert is that it's never getting fixed: we're missing some unit tests for "unknown" corner cases, so I propose we put ourselves at least in the position to be able to collect enough feedback to be able to (eventually) reproduce them and then proceed with confidence. On 7 March 2018 at 12:39, andrea boriero wrote: > I agree with the revert solution Guillaume proposed. > > On 7 March 2018 at 12:25, Guillaume Smet wrote: > >> Apparently, there is still an issue with the latest fix but a different >> one: >> https://hibernate.atlassian.net/browse/HHH-12332?page=com. >> atlassian.jira.plugin.system.issuetabpanels%3Acomment- >> tabpanel&focusedCommentId=101427#comment-101427 >> >> I posted a message to try to help the OP isolating the issue. >> >> I know it's not very satisfactory but I would really prefer that we revert >> this all for now. It's too risky just to fix a corner case. >> >> -- >> Guillaume >> >> On Wed, Mar 7, 2018 at 12:11 PM, andrea boriero >> wrote: >> >>> sorry but I had an horrible night and not feeling great right now so I'll >>> do the release late this afternoon or tomorrow morning. >>> >>> On 6 March 2018 at 19:32, Chris Cranford wrote: >>> >>> > Gail - >>> > >>> > I asked Andrea earlier and he hoped Wednesday March 7th; however he did >>> > say it depends on the status of Christian's fix. >>> > >>> > On 03/06/2018 02:13 PM, Gail Badner wrote: >>> > > When are you planning to release? I'd like to take a look at the >>> original >>> > > fix and PR as well. >>> > > >>> > > On Tue, Mar 6, 2018 at 5:44 AM, Steve Ebersole >>> > wrote: >>> > > >>> > >> +1 >>> > >> >>> > >> If you are confident, that's good for me >>> > >> >>> > >> >>> > >> On Tue, Mar 6, 2018, 7:24 AM Sanne Grinovero >>> > wrote: >>> > >> >>> > >>> On 6 March 2018 at 11:21, Christian Beikov < >>> christian.beikov at gmail.com >>> > > >>> > >>> wrote: >>> > >>>> Hey, >>> > >>>> >>> > >>>> I'm fine with reverting the patch as well, though I just fixed the >>> > >> issue >>> > >>>> Andrea found and am confident about the solution now. >>> > >>> Hi Christian, that's great! Let's go with your fix then. >>> > >>> >>> > >>> Thanks, >>> > >>> Sanne >>> > >>> >>> > >>> >>> > >>>> >>> > >>>> Mit freundlichen Gr??en, >>> > >>>> ------------------------------------------------------------ >>> > >> ------------ >>> > >>>> *Christian Beikov* >>> > >>>> Am 06.03.2018 um 11:57 schrieb Guillaume Smet: >>> > >>>>> Hi, >>> > >>>>> >>> > >>>>> So, AFAICS, Andrea found another failing case for the new PR. >>> > >>>>> >>> > >>>>> I would vote for reverting the original patch [ >>> > >>>>> https://hibernate.atlassian.net/browse/HHH-11544] for now and let >>> > >>> Christian >>> > >>>>> the time to think of a proper fix. I'm a bit worried we will miss >>> > >>> something >>> > >>>>> if we try to find a fix in a hurry. >>> > >>>>> >>> > >>>>> AFAICS, the original issue was a bit of a corner case so better >>> get >>> > >> the >>> > >>>>> other more common cases working. >>> > >>>>> >>> > >>>>> Anyone against reverting the original patch? Christian? >>> > >>>>> >>> > >>>> _______________________________________________ >>> > >>>> hibernate-dev mailing list >>> > >>>> hibernate-dev at lists.jboss.org >>> > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> > >>> hibernate-dev mailing list >>> > >>> hibernate-dev at lists.jboss.org >>> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >> _______________________________________________ >>> > >> hibernate-dev mailing list >>> > >> hibernate-dev at lists.jboss.org >>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >> >>> > > _______________________________________________ >>> > > hibernate-dev mailing list >>> > > hibernate-dev at lists.jboss.org >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From guillaume.smet at gmail.com Wed Mar 7 08:02:29 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 7 Mar 2018 14:02:29 +0100 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: On Wed, Mar 7, 2018 at 1:53 PM, Sanne Grinovero wrote: > Let's not rush things and see what Christian thinks: he should be > allowed to analyze this - if he has time and wants to - w/o too much > pressure. I see the last report is an NPE, that's typically not too > hard to fix so I'd rather try again. > Well, not having too much pressure is exactly the reason why I'd like us to revert. We would then have time to iterate with the people having reported the issue without having a last release out there that does not work as expected. We apparently have at least one person willing to test the WIP PR so that's a good thing for that. > The risk with a full revert is that it's never getting fixed: we're > missing some unit tests for "unknown" corner cases, so I propose we > put ourselves at least in the position to be able to collect enough > feedback to be able to (eventually) reproduce them and then proceed > with confidence. Reverting and releasing does not mean not pursuing the issues and making progress on this. That only means we can do it without pressure. -- Guillaume From sanne at hibernate.org Wed Mar 7 08:16:40 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 7 Mar 2018 13:16:40 +0000 Subject: [hibernate-dev] ORM - HHH-12332 - Releasing a 5.2.15 quickly? In-Reply-To: References: <3c4cf0e2-f2d2-aee2-ea84-73396bca9f62@gmail.com> <4c895a91-d09c-625a-f018-602f0dbdd5a0@gmail.com> Message-ID: On 7 March 2018 at 13:02, Guillaume Smet wrote: > On Wed, Mar 7, 2018 at 1:53 PM, Sanne Grinovero wrote: >> >> Let's not rush things and see what Christian thinks: he should be >> allowed to analyze this - if he has time and wants to - w/o too much >> pressure. I see the last report is an NPE, that's typically not too >> hard to fix so I'd rather try again. > > > Well, not having too much pressure is exactly the reason why I'd like us to > revert. We would then have time to iterate with the people having reported > the issue without having a last release out there that does not work as > expected. > > We apparently have at least one person willing to test the WIP PR so that's > a good thing for that. > >> >> The risk with a full revert is that it's never getting fixed: we're >> missing some unit tests for "unknown" corner cases, so I propose we >> put ourselves at least in the position to be able to collect enough >> feedback to be able to (eventually) reproduce them and then proceed >> with confidence. > > > Reverting and releasing does not mean not pursuing the issues and making > progress on this. That only means we can do it without pressure. Ok, if that's the intent fair enough. Still if Christian has a better solution soon there might be no need for it so I'd leave it to him. > > -- > Guillaume From steve at hibernate.org Wed Mar 7 12:12:58 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Mar 2018 17:12:58 +0000 Subject: [hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results Message-ID: I am trying to finish up these caching and stats related changes, but am currently fighting a few remaining test failures. In my initial investigation IMO some of these tests are wrong, but hoped someone(s) else could check may expectation/belief. E.g. have a look at `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`. It seems to me that the assertions using stats regarding cache hit/miss/put counts are wrong right from the very beginning. But I was hoping to get to a point where absolutely zero test changes were necessary. So was hoping to get others opinions. The test issues a number of cacheable queries. The first time happens in a Session in which the just queried entity is then inserted. This insertion ought to (validly) trigger an invalidation of these already cached query results. However the test assertions assert the opposite - that the insertion not invalidate the cache. Possibly the old code handle this specially (cache hit + "invalidated results") - I still need to dig into the old code to see if that is true. But to me, anyway, that seems wrong. Unless we add a new stat collection for query caching for the number of times we also considered cached results invalidated due to "update timestamps". WDYT? From andrea at hibernate.org Wed Mar 7 12:43:48 2018 From: andrea at hibernate.org (andrea boriero) Date: Wed, 7 Mar 2018 17:43:48 +0000 Subject: [hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results In-Reply-To: References: Message-ID: is the first check assertEquals( qs.getCacheHitCount(), 0 ); ? On 7 March 2018 at 17:12, Steve Ebersole wrote: > I am trying to finish up these caching and stats related changes, but am > currently fighting a few remaining test failures. In my initial > investigation IMO some of these tests are wrong, but hoped someone(s) else > could check may expectation/belief. E.g. have a look at > `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`. > It seems to me that the assertions using stats regarding cache hit/miss/put > counts are wrong right from the very beginning. > > But I was hoping to get to a point where absolutely zero test changes were > necessary. So was hoping to get others opinions. > > The test issues a number of cacheable queries. The first time happens in a > Session in which the just queried entity is then inserted. This insertion > ought to (validly) trigger an invalidation of these already cached query > results. However the test assertions assert the opposite - that the > insertion not invalidate the cache. Possibly the old code handle this > specially (cache hit + "invalidated results") - I still need to dig into > the old code to see if that is true. But to me, anyway, that seems wrong. > Unless we add a new stat collection for query caching for the number of > times we also considered cached results invalidated due to "update > timestamps". > > WDYT? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Mar 7 12:48:35 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 07 Mar 2018 17:48:35 +0000 Subject: [hibernate-dev] Self sanity check - caching and stats changes - invalidated query cache results In-Reply-To: References: Message-ID: Sorry for the noise - I misread the error. I missed that it was doing an invalidation (update) in the middle of the test as well. That failure is valid after all. Somehow the query execution count is getting out of sync with miss/put counts. Those values should always be equal. I'll have to track down where/why execution count is not incremented. On Wed, Mar 7, 2018 at 11:44 AM andrea boriero wrote: > is the first check assertEquals( qs.getCacheHitCount(), 0 ); ? > > On 7 March 2018 at 17:12, Steve Ebersole wrote: > >> I am trying to finish up these caching and stats related changes, but am >> currently fighting a few remaining test failures. In my initial >> investigation IMO some of these tests are wrong, but hoped someone(s) else >> could check may expectation/belief. E.g. have a look at >> `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`. >> It seems to me that the assertions using stats regarding cache >> hit/miss/put >> counts are wrong right from the very beginning. >> >> But I was hoping to get to a point where absolutely zero test changes were >> necessary. So was hoping to get others opinions. >> >> The test issues a number of cacheable queries. The first time happens in >> a >> Session in which the just queried entity is then inserted. This insertion >> ought to (validly) trigger an invalidation of these already cached query >> results. However the test assertions assert the opposite - that the >> insertion not invalidate the cache. Possibly the old code handle this >> specially (cache hit + "invalidated results") - I still need to dig into >> the old code to see if that is true. But to me, anyway, that seems wrong. >> Unless we add a new stat collection for query caching for the number of >> times we also considered cached results invalidated due to "update >> timestamps". >> >> WDYT? >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gbadner at redhat.com Wed Mar 7 17:30:41 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 7 Mar 2018 14:30:41 -0800 Subject: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid Message-ID: Hi, This is an unusual mapping. My gut feeling is that it is not a valid mapping, but I don't see anything in the spec that would indicate it is invalid. Here is the mapping: @Entity public class Product { @Id @Column(name = "id") private int id; @OneToOne(cascade = CascadeType.ALL) @JoinColumn(name = "id", referencedColumnName = "productId", insertable = false, updatable = false) private ProductInfo productInfo; } @Entity public class ProductInfo{ @Id private int id; @Column(name = "productId", unique = true, updatable = false) private int productId; } Hibernate ignores referencedColumnName = "productId" and assumes that Product and ProductInfo share the same ID value. When the IDs are not the same, Product#productInfo will be null. It seem to me that the foreign key column should be ProductInfo#productId and should reference Product#id, but this doesn't make sense for a unidirectional one-to-one owned by Product. IMO, a bidirectional @OneToOne with ProductInfo owning the association would make more sense. A test case can be found at [1] Is the mapping invalid, or is this a bug in Hibernate? Thanks, Gail [1] https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5cf35da85efc51ce70c5e0648ce89006 From sanne at hibernate.org Wed Mar 7 19:58:46 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 8 Mar 2018 00:58:46 +0000 Subject: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method Message-ID: Hi all, good news on the backwards compatibility; David suggested we could use his "bridger" tool to have the Session API binary compatible with older versions. - https://github.com/dmlloyd/bridger I created a prototype patch, it's all actually quite self-explanatory: - https://github.com/Sanne/hibernate-orm/commit/8d14a5efa29e6682a7d823a2252873a8d319cc7c I had more trouble testing it. Here a failed approach: I could not get Gradle to compile with a different version used for testing, while at the same time not driving dependencies in my IDE nuts :) - https://github.com/Sanne/hibernate-orm/commit/28f5110cf9ccee9614bceb454036d5204cf9ff6f Next, I resorted to an external, trivial Maven project; this worked beautifully! You can see the warnings in the logs suggesting "you're using a method which doesn't exist anymore, but it's ok.." . - https://github.com/Sanne/binary-compatibility-test Next steps: # Agree on applying the approach? I see no problems with it but clearly this will need to be supported by us all. # Figure out how to get the integration tests working in the ORM / Gradle build # Fix some pending problem with Envers: it's no longer compiling as a non-abstract extension of Session doesn't implement getFlushMode; might be tricky or not, I've not looked yet. # See if we can avoid listing the placeholder method in javadocs Thanks, Sanne From steve at hibernate.org Wed Mar 7 21:44:07 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 08 Mar 2018 02:44:07 +0000 Subject: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method In-Reply-To: References: Message-ID: On Wed, Mar 7, 2018 at 6:59 PM Sanne Grinovero wrote: > Hi all, > > good news on the backwards compatibility; David suggested we could use > his "bridger" tool to have the Session API binary compatible with > older versions. > - https://github.com/dmlloyd/bridger > Wow, very cool! Thanks for the tool David! I had more trouble testing it. > Here a failed approach: I could not get Gradle to compile with a > different version used for testing, while at the same time not driving > dependencies in my IDE nuts :) > - > https://github.com/Sanne/hibernate-orm/commit/28f5110cf9ccee9614bceb454036d5204cf9ff6f > > You mean compile tests using the current project version but run tests against an older version? If so, by far the easiest option will be a separate sourceSet. Here you can use the project dependency in testCompile and the older version in testRuntime. If that's not what you mean, can you explain some more? From andrea at hibernate.org Thu Mar 8 05:46:42 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 8 Mar 2018 10:46:42 +0000 Subject: [hibernate-dev] Starting 5.2.15 release Message-ID: *Please do not push anything to 5.2 branch.Thanks,Andrea* From sanne at hibernate.org Thu Mar 8 06:17:48 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 8 Mar 2018 11:17:48 +0000 Subject: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method In-Reply-To: References: Message-ID: On 8 March 2018 at 02:44, Steve Ebersole wrote: > > > On Wed, Mar 7, 2018 at 6:59 PM Sanne Grinovero wrote: >> >> Hi all, >> >> good news on the backwards compatibility; David suggested we could use >> his "bridger" tool to have the Session API binary compatible with >> older versions. >> - https://github.com/dmlloyd/bridger > > > Wow, very cool! Thanks for the tool David! > > >> I had more trouble testing it. >> Here a failed approach: I could not get Gradle to compile with a >> different version used for testing, while at the same time not driving >> dependencies in my IDE nuts :) >> - >> https://github.com/Sanne/hibernate-orm/commit/28f5110cf9ccee9614bceb454036d5204cf9ff6f >> > > You mean compile tests using the current project version but run tests > against an older version? If so, by far the easiest option will be a > separate sourceSet. Here you can use the project dependency in testCompile > and the older version in testRuntime. > > If that's not what you mean, can you explain some more? Thanks for the suggestions Steve. I got it working now but used a new project module, which I named "compatibility-testing". Ok to introduce that? It just has some tests using the (legacy) getFlushMode(), and dependencies setup as: dependencies { // [!] Compile with Hibernate ORM 5.1, but then run the tests with the current version testCompileOnly "org.hibernate:hibernate-core:5.1.12.Final" testCompileOnly "org.hibernate:hibernate-testing:5.1.12.Final" testRuntimeOnly project( ':hibernate-core' ) testRuntimeOnly project( ':hibernate-testing' ) } For some reason both Eclipse and IDEA get confused and the code shows as not compiling; it works fine via Gradle though so I'm afraid we'll just have to ignore the IDE warnings. I'll experiment a bit more with sourceSet to see if we can avoid that as it seems very inconvenient; Andrea will be with me this afternoon so maybe he can have a look too. Thanks, Sanne From andrea at hibernate.org Thu Mar 8 08:24:49 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 8 Mar 2018 13:24:49 +0000 Subject: [hibernate-dev] Hibernate ORM 5.2.15.Final has been released Message-ID: *For details:http://in.relation.to/2018/03/08/hibernate-orm-5215-final-release * From crancran at gmail.com Thu Mar 8 09:55:02 2018 From: crancran at gmail.com (Chris Cranford) Date: Thu, 8 Mar 2018 09:55:02 -0500 Subject: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method In-Reply-To: References: Message-ID: <9f80f373-36c8-d172-e3fc-373dc96cb2ec@gmail.com> Sanne - On 03/07/2018 07:58 PM, Sanne Grinovero wrote: > # Fix some pending problem with Envers: it's no longer compiling as a > non-abstract extension of Session doesn't implement getFlushMode; > might be tricky or not, I've not looked yet. I assume this is due to o.h.envers.internal.entities.mapper.relation.lazy.ToOneDelegateSessionImplementor ? From guillaume.smet at hibernate.org Thu Mar 8 09:59:30 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Thu, 8 Mar 2018 15:59:30 +0100 Subject: [hibernate-dev] Hibernate Validator 6.0.8.Final Message-ID: Hi, We just released Hibernate Validator 6.0.8.Final with: - constraint validator payload - some performance improvements - a couple of bugfixes More information in the blog post: http://in.relation.to/2018/03/08/hibernate-validator-608-final-out/ . Have a nice day. -- Guillaume From sanne at hibernate.org Thu Mar 8 10:55:08 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 8 Mar 2018 15:55:08 +0000 Subject: [hibernate-dev] HHH-12372 Restore binary compatibility with applications using the legacy Session#getFlushMode() method In-Reply-To: <9f80f373-36c8-d172-e3fc-373dc96cb2ec@gmail.com> References: <9f80f373-36c8-d172-e3fc-373dc96cb2ec@gmail.com> Message-ID: On 8 March 2018 at 14:55, Chris Cranford wrote: > Sanne - > > On 03/07/2018 07:58 PM, Sanne Grinovero wrote: >> # Fix some pending problem with Envers: it's no longer compiling as a >> non-abstract extension of Session doesn't implement getFlushMode; >> might be tricky or not, I've not looked yet. > I assume this is due to > o.h.envers.internal.entities.mapper.relation.lazy.ToOneDelegateSessionImplementor > ? Yes, exactly: /home/sanne/sources/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/internal/entities/mapper/relation/lazy/ToOneDelegateSessionImplementor.java:19: error: ToOneDelegateSessionImplementor is not abstract and does not override abstract method getFlushMode() in Session public class ToOneDelegateSessionImplementor extends AbstractDelegateSessionImplementor { From steve at hibernate.org Thu Mar 8 14:22:06 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 08 Mar 2018 19:22:06 +0000 Subject: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid In-Reply-To: References: Message-ID: For sure our model can handle this mapping, although maybe only from the other side (that's generally the more natural mapping) - internally it's called a "logical many-to-one". Personally I'd say there is nothing wrong with the mapping per-se. On Wed, Mar 7, 2018 at 4:36 PM Gail Badner wrote: > Hi, > > This is an unusual mapping. My gut feeling is that it is not a valid > mapping, but I don't see anything in the spec that would indicate it is > invalid. > > Here is the mapping: > > @Entity > public class Product { > @Id > @Column(name = "id") > private int id; > > @OneToOne(cascade = CascadeType.ALL) > @JoinColumn(name = "id", referencedColumnName = "productId", > insertable = false, updatable = false) > private ProductInfo productInfo; > > } > > @Entity > public class ProductInfo{ > @Id > private int id; > > @Column(name = "productId", unique = true, updatable = false) > private int productId; > } > > Hibernate ignores referencedColumnName = "productId" and assumes that > Product and ProductInfo share the same ID value. > When the IDs are not the same, Product#productInfo will be null. > > It seem to me that the foreign key column should be > ProductInfo#productId and should reference Product#id, but this > doesn't make sense > for a unidirectional one-to-one owned by Product. > > IMO, a bidirectional @OneToOne with ProductInfo owning the association > would make more sense. > > A test case can be found at [1] > > Is the mapping invalid, or is this a bug in Hibernate? > > Thanks, > Gail > [1] > https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5cf35da85efc51ce70c5e0648ce89006 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Thu Mar 8 17:38:04 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 8 Mar 2018 14:38:04 -0800 Subject: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid In-Reply-To: References: Message-ID: Hi Steve, I know that a bidirectional one-to-one association works properly with Product#productInfo on the "mappedBy" side, and ProductInfo#product on the owning side. With that mapping, ProductInfo#product is a ManyToOne that is a "logical" OneToOne. I agree that is the more natural way to map this association, but this use case is for a unidirectional one-to-one. What I'm seeing in the debugger for this unidirectional one-to-one association, Product#productInfo, is that it is OneToOneType with: * #foreignKeyType == ForeignKeyDirection.TO_PARENT * #referenceToPrimaryKey == true Both of these seem wrong to me for a unidirectional one-to-one, but maybe I'm missing something. I should mention that, in this particular case, no foreign key is generated. Even so, ForeignKeyDirection.TO_PARENT, means that Hibernate assumes that the foreign key is defined in ProductInfo, not Product, doesn't it? If the foreign key were in ProductInfo, then it would make sense that #referenceToPrimaryKey == true. I want to make sure that I understand what should be expected behavior for this use case. Since Product#productInfo is a unidirectional one-to-one, I would have expected that OneToOneType would have: * #foreignKeyType == ForeignKeyDirection.FROM_PARENT (with foreign key column Product#id) * #referenceToPrimaryKey == false (since it references non-PK column ProductInfo#productId) Also, Product#id will always be non-null, but that doesn't mean that there is a non-null association with ProductInfo. It seems that Hibernate should complain when an association cannot be found, unless the association is annotated with @NotFound(NotFoundAction.IGNORE). Does this sound right to you? Thanks, Gail On Thu, Mar 8, 2018 at 11:22 AM, Steve Ebersole wrote: > For sure our model can handle this mapping, although maybe only from the > other side (that's generally the more natural mapping) - internally it's > called a "logical many-to-one". Personally I'd say there is nothing wrong > with the mapping per-se. > > > On Wed, Mar 7, 2018 at 4:36 PM Gail Badner wrote: > >> Hi, >> >> This is an unusual mapping. My gut feeling is that it is not a valid >> mapping, but I don't see anything in the spec that would indicate it is >> invalid. >> >> Here is the mapping: >> >> @Entity >> public class Product { >> @Id >> @Column(name = "id") >> private int id; >> >> @OneToOne(cascade = CascadeType.ALL) >> @JoinColumn(name = "id", referencedColumnName = "productId", >> insertable = false, updatable = false) >> private ProductInfo productInfo; >> >> } >> >> @Entity >> public class ProductInfo{ >> @Id >> private int id; >> >> @Column(name = "productId", unique = true, updatable = false) >> private int productId; >> } >> >> Hibernate ignores referencedColumnName = "productId" and assumes that >> Product and ProductInfo share the same ID value. >> When the IDs are not the same, Product#productInfo will be null. >> >> It seem to me that the foreign key column should be >> ProductInfo#productId and should reference Product#id, but this >> doesn't make sense >> for a unidirectional one-to-one owned by Product. >> >> IMO, a bidirectional @OneToOne with ProductInfo owning the association >> would make more sense. >> >> A test case can be found at [1] >> >> Is the mapping invalid, or is this a bug in Hibernate? >> >> Thanks, >> Gail >> [1] https://github.com/gbadner/hibernate-test-case-templates/commit/ >> d806d4ef5cf35da85efc51ce70c5e0648ce89006 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Thu Mar 8 19:13:50 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 09 Mar 2018 00:13:50 +0000 Subject: [hibernate-dev] Is unidirectional one-to-one referencing a non-primary key valid In-Reply-To: References: Message-ID: Well now you are asking 2 different questions I think: 1) Is this a conceptually valid mapping? Which is what you explicitly asked originally. I said that imo the mapping itself is conceptually valid. 2) Do we support this? Clearly not. More in line... On Thu, Mar 8, 2018, 4:38 PM Gail Badner wrote: > Hi Steve, > > I know that a bidirectional one-to-one association works properly with > Product#productInfo on the "mappedBy" side, and ProductInfo#product on the > owning side. With that mapping, ProductInfo#product is a ManyToOne that > is a "logical" OneToOne. > > I agree that is the more natural way to map this association, but this use > case is for a unidirectional one-to-one. > I never said that the bi-directional is the more natural mapping. I said that mapping the association from ProductInfo (either uni- or bi-directionally) is more natural. > What I'm seeing in the debugger for this unidirectional one-to-one > association, Product#productInfo, is that it is OneToOneType with: > * #foreignKeyType == ForeignKeyDirection.TO_PARENT > * #referenceToPrimaryKey == true > > Both of these seem wrong to me for a unidirectional one-to-one, but maybe > I'm missing something. > > I should mention that, in this particular case, no foreign key is > generated. Even so, ForeignKeyDirection.TO_PARENT, means that Hibernate > assumes that the foreign key is defined in ProductInfo, not Product, > doesn't it? If the foreign key were in ProductInfo, then it would make > sense that #referenceToPrimaryKey == true. > > I want to make sure that I understand what should be expected behavior for > this use case. > > Since Product#productInfo is a unidirectional one-to-one, I would have > expected that OneToOneType would have: > * #foreignKeyType == ForeignKeyDirection.FROM_PARENT (with foreign key > column Product#id) > * #referenceToPrimaryKey == false (since it references non-PK column > ProductInfo#productId) > IMO everything you say above here directly follows from Hibernate not handling the `referencedColumnName` on `Product#productInfo`. My guess is that if you resolved this, the rest would fall into place, or at least get you very close > Also, Product#id will always be non-null, but that doesn't mean that there > is a non-null association with ProductInfo. It seems that Hibernate should > complain when an association cannot be found, unless the association is > annotated with @NotFound(NotFoundAction.IGNORE). > > Does this sound right to you? > I think we want to be careful there. But generally speaking I think that's valid when the association is not marked optional > Thanks, > Gail > > On Thu, Mar 8, 2018 at 11:22 AM, Steve Ebersole > wrote: > >> For sure our model can handle this mapping, although maybe only from the >> other side (that's generally the more natural mapping) - internally it's >> called a "logical many-to-one". Personally I'd say there is nothing wrong >> with the mapping per-se. >> >> >> On Wed, Mar 7, 2018 at 4:36 PM Gail Badner wrote: >> >>> Hi, >>> >>> This is an unusual mapping. My gut feeling is that it is not a valid >>> mapping, but I don't see anything in the spec that would indicate it is >>> invalid. >>> >>> Here is the mapping: >>> >>> @Entity >>> public class Product { >>> @Id >>> @Column(name = "id") >>> private int id; >>> >>> @OneToOne(cascade = CascadeType.ALL) >>> @JoinColumn(name = "id", referencedColumnName = "productId", >>> insertable = false, updatable = false) >>> private ProductInfo productInfo; >>> >>> } >>> >>> @Entity >>> public class ProductInfo{ >>> @Id >>> private int id; >>> >>> @Column(name = "productId", unique = true, updatable = false) >>> private int productId; >>> } >>> >>> Hibernate ignores referencedColumnName = "productId" and assumes that >>> Product and ProductInfo share the same ID value. >>> When the IDs are not the same, Product#productInfo will be null. >>> >>> It seem to me that the foreign key column should be >>> ProductInfo#productId and should reference Product#id, but this >>> doesn't make sense >>> for a unidirectional one-to-one owned by Product. >>> >>> IMO, a bidirectional @OneToOne with ProductInfo owning the association >>> would make more sense. >>> >>> A test case can be found at [1] >>> >>> Is the mapping invalid, or is this a bug in Hibernate? >>> >>> Thanks, >>> Gail >>> [1] >>> https://github.com/gbadner/hibernate-test-case-templates/commit/d806d4ef5cf35da85efc51ce70c5e0648ce89006 >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From sanne at hibernate.org Fri Mar 9 08:04:46 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 9 Mar 2018 13:04:46 +0000 Subject: [hibernate-dev] Proxying the Session: a requirement ? Message-ID: It turns out that using Bridger to restore backwards binary compatibility will make the Session un-proxable. Specifically any code attempint to invoke something like: Session wrapped = (Session) Proxy.newProxyInstance( Session.class.getClassLoader(), new Class[] { Session.class } wrapper ); will fail at runtime, as the JDK Proxy utility can't deal with bridge methods. We do proxy the Session in some of our own code - which is of course something that could be resolved with alternatives - but I wonder if this approach will break many more frameworks and tools I'm not aware of. What do you all think, is this a deal breaker? I'm starting to think the cure is worse than the disease :/ Thanks, Sanne From steve at hibernate.org Fri Mar 9 08:09:59 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 09 Mar 2018 13:09:59 +0000 Subject: [hibernate-dev] Proxying the Session: a requirement ? In-Reply-To: References: Message-ID: I think most environments would proxy the JPA contracts if anything. For Session we do offer the "base delegator" for a delegation solution rather than proxying. All told, unless we hear differently I'd say you are safe to break proxying of the Session. Assuming of course you fix the thread-based current-session stuff which afaik is the only place we actually proxy the Session On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero wrote: > It turns out that using Bridger to restore backwards binary > compatibility will make the Session un-proxable. > > Specifically any code attempint to invoke something like: > > Session wrapped = (Session) Proxy.newProxyInstance( > Session.class.getClassLoader(), > new Class[] { Session.class } > wrapper > ); > > will fail at runtime, as the JDK Proxy utility can't deal with bridge > methods. > > We do proxy the Session in some of our own code - which is of course > something that could be resolved with alternatives - but I wonder if > this approach will break many more frameworks and tools I'm not aware > of. > > What do you all think, is this a deal breaker? I'm starting to think > the cure is worse than the disease :/ > > Thanks, > Sanne > From sanne at hibernate.org Fri Mar 9 08:14:00 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 9 Mar 2018 13:14:00 +0000 Subject: [hibernate-dev] Proxying the Session: a requirement ? In-Reply-To: References: Message-ID: On 9 March 2018 at 13:09, Steve Ebersole wrote: > I think most environments would proxy the JPA contracts if anything. For > Session we do offer the "base delegator" for a delegation solution rather > than proxying. > > All told, unless we hear differently I'd say you are safe to break proxying > of the Session. Assuming of course you fix the thread-based current-session > stuff which afaik is the only place we actually proxy the Session 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. > > On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero wrote: >> >> It turns out that using Bridger to restore backwards binary >> compatibility will make the Session un-proxable. >> >> Specifically any code attempint to invoke something like: >> >> Session wrapped = (Session) Proxy.newProxyInstance( >> Session.class.getClassLoader(), >> new Class[] { Session.class } >> wrapper >> ); >> >> will fail at runtime, as the JDK Proxy utility can't deal with bridge >> methods. >> >> We do proxy the Session in some of our own code - which is of course >> something that could be resolved with alternatives - but I wonder if >> this approach will break many more frameworks and tools I'm not aware >> of. >> >> What do you all think, is this a deal breaker? I'm starting to think >> the cure is worse than the disease :/ >> >> Thanks, >> Sanne

On 9 March 2018 at 13:09, Steve Ebersole <steve at hibernate.org> wrote:
I think most environments would proxy the JPA contracts if anything.  For Session we do offer the "base delegator" for a delegation solution rather than proxying.

All told, unless we hear differently I'd say you are safe to break proxying of the Session.  Assuming of course you fix the thread-based current-session stuff which afaik is the only place we actually proxy the Session

On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero <sanne at hibernate.org> wrote:
It turns out that using Bridger to restore backwards binary
compatibility will make the Session un-proxable.

Specifically any code attempint to invoke something like:

Session wrapped = (Session) Proxy.newProxyInstance(
      Session.class.getClassLoader(),
      new Class[] { Session.class }
      wrapper
);

will fail at runtime, as the JDK Proxy utility can't deal with bridge methods.

We do proxy the Session in some of our own code - which is of course
something that could be resolved with alternatives - but I wonder if
this approach will break many more frameworks and tools I'm not aware
of.

What do you all think, is this a deal breaker? I'm starting to think
the cure is worse than the disease :/

Thanks,
Sanne

From steve at hibernate.org Fri Mar 9 08:24:07 2018 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 09 Mar 2018 13:24:07 +0000 Subject: [hibernate-dev] Proxying the Session: a requirement ? In-Reply-To: References: Message-ID: I'm really struggling with porting back these caching changes (timestamps), so we have time. I think I will push the CR date another week or 2 to finish up all these things we all are working on. Just NO MORE scope creep. What we have already planned to do for 5.3 is what will be in 5.3 - no more :) On Fri, Mar 9, 2018 at 7:14 AM Sanne Grinovero wrote: > On 9 March 2018 at 13:09, Steve Ebersole wrote: > > I think most environments would proxy the JPA contracts if anything. For > > Session we do offer the "base delegator" for a delegation solution rather > > than proxying. > > > > All told, unless we hear differently I'd say you are safe to break > proxying > > of the Session. Assuming of course you fix the thread-based > current-session > > stuff which afaik is the only place we actually proxy the Session > > 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. > > > > > On Fri, Mar 9, 2018 at 7:05 AM Sanne Grinovero > wrote: > >> > >> It turns out that using Bridger to restore backwards binary > >> compatibility will make the Session un-proxable. > >> > >> Specifically any code attempint to invoke something like: > >> > >> Session wrapped = (Session) Proxy.newProxyInstance( > >> Session.class.getClassLoader(), > >> new Class[] { Session.class } > >> wrapper > >> ); > >> > >> will fail at runtime, as the JDK Proxy utility can't deal with bridge > >> methods. > >> > >> We do proxy the Session in some of our own code - which is of course > >> something that could be resolved with alternatives - but I wonder if > >> this approach will break many more frameworks and tools I'm not aware > >> of. > >> > >> What do you all think, is this a deal breaker? I'm starting to think > >> the cure is worse than the disease :/ > >> > >> Thanks, > >> Sanne

On 9 March > 2018 at 13:09, Steve Ebersole <steve at hibernate.org> > wrote:
I think > most environments would proxy the JPA contracts if anything.  For > Session we do offer the "base delegator" for a delegation solution rather > than proxying.

All told, unless we hear differently I'd > say you are safe to break proxying of the Session.  Assuming of course > you fix the thread-based current-session stuff which afaik is the only > place we actually proxy the Session
class="h5">
On Fri, Mar 9, 2018 > at 7:05 AM Sanne Grinovero < target="_blank">sanne at hibernate.org> wrote:
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex">It turns out that using Bridger to restore > backwards binary
> compatibility will make the Session un-proxable.
>
> Specifically any code attempint to invoke something like:
>
> Session wrapped = (Session) Proxy.newProxyInstance(
>       Session.class.getClassLoader(),
>       new Class[] { Session.class }
>       wrapper
> );
>
> will fail at runtime, as the JDK Proxy utility can't deal with bridge > methods.
>
> We do proxy the Session in some of our own code - which is of course
> something that could be resolved with alternatives - but I wonder if
> this approach will break many more frameworks and tools I'm not aware
> of.
>
> What do you all think, is this a deal breaker? I'm starting to think
> the cure is worse than the disease :/
>
> Thanks,
> Sanne
>
>

> From guillaume.smet at gmail.com Fri Mar 9 08:42:29 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 9 Mar 2018 14:42:29 +0100 Subject: [hibernate-dev] Proxying the Session: a requirement ? In-Reply-To: References: Message-ID: 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. -- Guillaume From christian.beikov at gmail.com Fri Mar 9 15:20:15 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Fri, 9 Mar 2018 21:20:15 +0100 Subject: [hibernate-dev] Joins over type variable defined assocations NPE problems Message-ID: 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* From guillaume.smet at gmail.com Mon Mar 12 06:52:40 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 12 Mar 2018 11:52:40 +0100 Subject: [hibernate-dev] Travis build being very unstable with ORM Message-ID: Hi, I don't know if it's an issue you had before with our CI but the Travis builds are very unstable, failing with this message: :hibernate-core:testPicked up _JAVA_OPTIONS: -Xmx2048m -Xms512m No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself. Just got 3 in a row... Moreover the only time I got a build to finish, the build was really really long. Wondering if it's such an improvement to base the PR testing on Travis for ORM. WDYT? -- Guillaume From sanne at hibernate.org Mon Mar 12 07:16:08 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 12 Mar 2018 11:16:08 +0000 Subject: [hibernate-dev] Travis build being very unstable with ORM In-Reply-To: References: Message-ID: On 12 March 2018 at 10:52, Guillaume Smet wrote: > Hi, > > I don't know if it's an issue you had before with our CI but the Travis > builds are very unstable, failing with this message: > :hibernate-core:testPicked up _JAVA_OPTIONS: -Xmx2048m -Xms512m > No output has been received in the last 10m0s, this potentially indicates a > stalled build or something wrong with the build itself. 2GB is not enough, I thought I had reconfigured it with - https://github.com/hibernate/hibernate-orm/commit/66d3232eb671f9482f4c300f29d23d83b80cdaff I was expecting Travis to apply the Gradle settings but maybe I'm missing something? Incidentally, the reason is a leak in the tests, specifically - org.hibernate.test.bytecode.enhancement.access.MixedAccessTest Luis is having a look at that, but independently from that problem I suggest we reconfigure it all to use 4GB anyway as 2GB was too limiting. Thanks, Sanne > > Just got 3 in a row... > > Moreover the only time I got a build to finish, the build was really really > long. > > Wondering if it's such an improvement to base the PR testing on Travis for > ORM. > > WDYT? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Mon Mar 12 07:30:39 2018 From: davide at hibernate.org (Davide D'Alto) Date: Mon, 12 Mar 2018 11:30:39 +0000 Subject: [hibernate-dev] CI Updates Message-ID: I'm going to run some updates on CI this Friday. Cheers, Davide From jonathan.bregler at sap.com Mon Mar 12 11:27:40 2018 From: jonathan.bregler at sap.com (Bregler, Jonathan) Date: Mon, 12 Mar 2018 15:27:40 +0000 Subject: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions Message-ID: 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Stack Trace.txt Url: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20180312/825354f4/attachment-0001.txt From sanne at hibernate.org Mon Mar 12 11:44:47 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 12 Mar 2018 15:44:47 +0000 Subject: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions In-Reply-To: References: Message-ID: 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From jonathan.bregler at sap.com Mon Mar 12 12:13:52 2018 From: jonathan.bregler at sap.com (Bregler, Jonathan) Date: Mon, 12 Mar 2018 16:13:52 +0000 Subject: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions In-Reply-To: References: Message-ID: <0dd779ba43d84ea99b3edd8e414786fe@sap.com> Hi Sanne, Multi-release JARs sound promising. I'll forward your suggestion to the HANA JDBC driver team. Thanks, Jonathan -----Original Message----- From: sanne.grinovero at gmail.com [mailto:sanne.grinovero at gmail.com] On Behalf Of Sanne Grinovero Sent: Monday, March 12, 2018 4:45 PM To: Bregler, Jonathan Cc: hibernate-dev at 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From andrea at hibernate.org Mon Mar 12 12:54:57 2018 From: andrea at hibernate.org (andrea boriero) Date: Mon, 12 Mar 2018 16:54:57 +0000 Subject: [hibernate-dev] Joins over type variable defined assocations NPE problems In-Reply-To: References: Message-ID: 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Tue Mar 13 07:50:06 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 13 Mar 2018 11:50:06 +0000 Subject: [hibernate-dev] Proxying the Session: a requirement ? In-Reply-To: References: Message-ID: 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 From sanne at hibernate.org Tue Mar 13 08:36:09 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 13 Mar 2018 12:36:09 +0000 Subject: [hibernate-dev] Proxying the Session: a requirement ? In-Reply-To: References: Message-ID: Spring seems to choke on a single, specific method; sadly it's not even meant to proxy a Session but it happens to do so: https://github.com/spring-projects/spring-framework/blob/master/spring-orm/src/main/java/org/springframework/orm/jpa/ExtendedEntityManagerCreator.java#L219-L238 This is meant to create a proxy of *EntityManager* yet when the `emIfc` argument is null it will list all interfaces the wrapped object implements, and pass them all to the Proxy method. I will guess they have some good reason to do so, we could see if they could change the approach, possibly simply blacklist the Session to filter it out from this inferred set of interfaces, or make sure this argument is never null. The parameter seems to be null at least when running the Spring Data integration tests; I would say that's not reassuring. Either way, seems like we should abandon this idea: while this approach could be improved in future libraries, it doesn't look like it will help backwards compatibility of existing applications. Thanks, Sanne On 13 March 2018 at 11:50, Sanne Grinovero wrote: > 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 From guillaume.smet at hibernate.org Tue Mar 13 10:46:26 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 13 Mar 2018 15:46:26 +0100 Subject: [hibernate-dev] Hibernate Search 5.9.1.Final released Message-ID: 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 From sanne at hibernate.org Tue Mar 13 10:57:48 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 13 Mar 2018 14:57:48 +0000 Subject: [hibernate-dev] [hibernate-announce] Hibernate Search 5.9.1.Final released In-Reply-To: References: Message-ID: 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-announce at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-announce From steve at hibernate.org Tue Mar 13 11:20:43 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 13 Mar 2018 15:20:43 +0000 Subject: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions In-Reply-To: <0dd779ba43d84ea99b3edd8e414786fe@sap.com> References: <0dd779ba43d84ea99b3edd8e414786fe@sap.com> Message-ID: 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.grinovero at gmail.com [mailto:sanne.grinovero at gmail.com] On > Behalf Of Sanne Grinovero > Sent: Monday, March 12, 2018 4:45 PM > To: Bregler, Jonathan > Cc: hibernate-dev at 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 at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at hibernate.org Tue Mar 13 12:04:08 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 13 Mar 2018 17:04:08 +0100 Subject: [hibernate-dev] NoORM IRC meeting minutes Message-ID: 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 From jonathan.bregler at sap.com Tue Mar 13 12:36:31 2018 From: jonathan.bregler at sap.com (Bregler, Jonathan) Date: Tue, 13 Mar 2018 16:36:31 +0000 Subject: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions In-Reply-To: References: <0dd779ba43d84ea99b3edd8e414786fe@sap.com> Message-ID: <9188d40a013b48b68018b952da617f28@sap.com> 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:steve at hibernate.org] Sent: Tuesday, March 13, 2018 4:21 PM To: Bregler, Jonathan Cc: Sanne Grinovero ; hibernate-dev at 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.grinovero at gmail.com [mailto:sanne.grinovero at gmail.com] On Behalf Of Sanne Grinovero Sent: Monday, March 12, 2018 4:45 PM To: Bregler, Jonathan > Cc: hibernate-dev at 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Tue Mar 13 15:06:31 2018 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 13 Mar 2018 19:06:31 +0000 Subject: [hibernate-dev] Joins over type variable defined assocations NPE problems In-Reply-To: References: Message-ID: 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 at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From christian.beikov at gmail.com Wed Mar 14 02:21:19 2018 From: christian.beikov at gmail.com (Christian Beikov) Date: Wed, 14 Mar 2018 07:21:19 +0100 Subject: [hibernate-dev] Joins over type variable defined assocations NPE problems In-Reply-To: References: Message-ID: Thanks for the feedback. I tried removing the attribute from the PropertyMapping at first, but it didn't work out in the end. Not remembering the full details, but it had something to do with load plans trying to resolve the properties contained in the subclass propery closure against the super type. I didn't see a nice way to make this work, so I decided to register "null" and empty join columns for such unresolvable types. Now, in the load plan, I simply skip association attributes that have empty join columns. The fix passes the testsuite and the original reporter confirmed that the fix works for him. Mit freundlichen Gr??en, ------------------------------------------------------------------------ *Christian Beikov* Am 13.03.2018 um 20:06 schrieb 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 at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Mar 14 07:52:56 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 14 Mar 2018 11:52:56 +0000 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote Message-ID: Hi all, this one is a very desirable feature, yet tricky as there's high chances of ambiguity and confusion for end users. # Infinispan Remote indexing Infinispan embeds the Hibernate Search engine, and uses it to index data being inserted in any cache having indexing enabled. As you know Infinispan can be used to store Java POJOs, which get serialized using JBoss Marshalling - or encoded into Protobuf entries using Infinispan Protostream as helper layer. Hibernate OGM supports both modes, one meant for "Infinispan Embedded" and one for "Infinispan Remote" as that's what each encoding strategy is suited for. # Protobuf & indexing Protobuf is a well defined format with plenty of documentation which focuses on a "schema" of the encoding; Hibernate OGM is able to generate such schemas dynamically and will generate encoders and decoders which follow the encoding guidelines for Java objects. The meta schema of protobuf is not super flexible, yet there's the option of annotating the Protobuf schema elements using "annotations" in comments. Protostream allows inserting Hibernate Search annotations directly in these comments and will use them to generate the server side indexing configuration, implicitly also allowing such properties to be queried using indexed. For example you might have this string literally within the comments: "@Field(store = Store.YES, analyze = Analyze.YES)" A full example of schema can be found here [1]. (The Infinispan documentation is a bit sparse on this as they encourage people to use another code gen tool, best refer to tests as examples when working for OGM) # What should OGM users experience? A naive solution would be to allow people to use the Hibernate Search annotations on their JPA entities, and we have OGM copy these into the generated schema; there's a number of problems with that: - not all such annotations "translate" equally well [2] - there's a mismatch between JPA properties and underlying encoding fields - if I run a FullTextQuery do I expect it to work remotely? - what if I want to use Hibernate Search locally as well or instead? - references to local classes obviously won't work (custom fieldbridges, analyzers, etc..) An alternative is to look at these as "indexes" of the underlying store, so we'd use them to hint the Infinispan server about user provided hints such as those generated by `javax.persistence.Index`. I do think this is the cleaner approach, yet has two drawbacks: A- I guess ORM might implicitly generate some indexes in its metadata which the user might not have explicitly asked; e.g. accelerate unique constraints and foreign keys; it's possible these might not be as useful as expected in the Infinispan case. B- we won't be able to leverage the awesome full-text capabilities :-( I believe A is something we could ignore for now and revisit if there's actual demand. B is also not urgent, yet disappointing limitation as this capability is a distinguishing feature of this NoSQL. Would we agree that exposing such full-text capabilities would best be let to an ad-hoc backend in Hibernate Search 6? Thanks, Sanne 1 - http://blog.infinispan.org/2018/02/restful-queries-coming-to-infinispan-92.html 2 - https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/impl/indexing/IndexingMetadataCreator.java#L31 From steve at hibernate.org Wed Mar 14 16:44:01 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 14 Mar 2018 20:44:01 +0000 Subject: [hibernate-dev] Joins over type variable defined assocations NPE problems In-Reply-To: References: Message-ID: Well, to be clear I said to have PropertyMapping for the super to treat that path as illegal... On Wed, Mar 14, 2018 at 1:21 AM Christian Beikov wrote: > Thanks for the feedback. I tried removing the attribute from the > PropertyMapping at first, but it didn't work out in the end. Not > remembering the full details, but it had something to do with load plans > trying to resolve the properties contained in the subclass propery closure > against the super type. I didn't see a nice way to make this work, so I > decided to register "null" and empty join columns for such unresolvable > types. Now, in the load plan, I simply skip association attributes that > have empty join columns. > > The fix passes the testsuite and the original reporter confirmed that the > fix works for him. > > Mit freundlichen Gr??en, > ------------------------------ > *Christian Beikov* > Am 13.03.2018 um 20:06 schrieb 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 at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From steve at hibernate.org Thu Mar 15 09:04:38 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 15 Mar 2018 13:04:38 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache Message-ID: Given the changes to the second-level cache SPI, I wonder if we want to take that as an opportunity to consider dropping the `hibernate-ehcache` module? There are a few reasons I am considering this... 1. We have the JCache integration in place and users can use Ehcache via that support already. 2. This is really the same discussion we had wrt Spring Cache[1]. IMO the answer should be consistent. We moved hibernate-infinispan for many of these same reasons... 3. A large part of the argument for keeping hibernate-ehcache was that it is already in place and therefore did not require much effort to support/maintain. However, given the new SPI there is actually a pretty big effort to adapt hibernate-ehcache to those new SPIs. So far I am the one doing that - which in and of itself is fine since I am the one who changed the SPIs ;) But it makes me think it is far less of a maintenance effort just to drop it and support just hibernate-ehcache. WDYT? [1] https://github.com/hibernate/hibernate-orm/pull/1639 From sanne at hibernate.org Thu Mar 15 09:44:35 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 15 Mar 2018 13:44:35 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: On 15 March 2018 at 13:04, Steve Ebersole wrote: > Given the changes to the second-level cache SPI, I wonder if we want to > take that as an opportunity to consider dropping the `hibernate-ehcache` > module? > > There are a few reasons I am considering this... > > 1. We have the JCache integration in place and users can use Ehcache > via that support already. > 2. This is really the same discussion we had wrt Spring Cache[1]. IMO > the answer should be consistent. We moved hibernate-infinispan for many of > these same reasons... > 3. A large part of the argument for keeping hibernate-ehcache was that > it is already in place and therefore did not require much effort to > support/maintain. However, given the new SPI there is actually a pretty > big effort to adapt hibernate-ehcache to those new SPIs. So far I am the > one doing that - which in and of itself is fine since I am the one who > changed the SPIs ;) But it makes me think it is far less of a maintenance > effort just to drop it and support just hibernate-ehcache. I guess you meant "support just JCache" ? +1 since the new SPI is different. I do wonder if the JCache API will be a straitjacket for futher performance improvements, but I guess we could re-insert this module if there's more concrete elements? At least any work due to SPI changes could be deferred. We'll still be testing with Ehcache - over JCache - I hope? Thanks, Sanne > > WDYT? > > > [1] https://github.com/hibernate/hibernate-orm/pull/1639 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Mar 15 09:47:03 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 15 Mar 2018 13:47:03 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: On 15 March 2018 at 13:44, Sanne Grinovero wrote: > On 15 March 2018 at 13:04, Steve Ebersole wrote: >> Given the changes to the second-level cache SPI, I wonder if we want to >> take that as an opportunity to consider dropping the `hibernate-ehcache` >> module? >> >> There are a few reasons I am considering this... >> >> 1. We have the JCache integration in place and users can use Ehcache >> via that support already. >> 2. This is really the same discussion we had wrt Spring Cache[1]. IMO >> the answer should be consistent. We moved hibernate-infinispan for many of >> these same reasons... >> 3. A large part of the argument for keeping hibernate-ehcache was that >> it is already in place and therefore did not require much effort to >> support/maintain. However, given the new SPI there is actually a pretty >> big effort to adapt hibernate-ehcache to those new SPIs. So far I am the >> one doing that - which in and of itself is fine since I am the one who >> changed the SPIs ;) But it makes me think it is far less of a maintenance >> effort just to drop it and support just hibernate-ehcache. > > I guess you meant "support just JCache" ? > > +1 since the new SPI is different. I do wonder if the JCache API will > be a straitjacket for futher performance improvements, but I guess we > could re-insert this module if there's more concrete elements? At > least any work due to SPI changes could be deferred. > > We'll still be testing with Ehcache - over JCache - I hope? BTW what about all of Alex's sophisticated integration tests? I assume they are more thorough in the older Ehcache module than in the JCache module; would be a shame to lose those verifications. > > Thanks, > Sanne > > >> >> WDYT? >> >> >> [1] https://github.com/hibernate/hibernate-orm/pull/1639 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Mar 15 09:56:25 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 15 Mar 2018 13:56:25 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: Inline.... On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero wrote: > On 15 March 2018 at 13:04, Steve Ebersole wrote: > > Given the changes to the second-level cache SPI, I wonder if we want to > > take that as an opportunity to consider dropping the `hibernate-ehcache` > > module? > > > > There are a few reasons I am considering this... > > > > 1. We have the JCache integration in place and users can use Ehcache > > via that support already. > > 2. This is really the same discussion we had wrt Spring Cache[1]. IMO > > the answer should be consistent. We moved hibernate-infinispan for > many of > > these same reasons... > > 3. A large part of the argument for keeping hibernate-ehcache was that > > it is already in place and therefore did not require much effort to > > support/maintain. However, given the new SPI there is actually a > pretty > > big effort to adapt hibernate-ehcache to those new SPIs. So far I am > the > > one doing that - which in and of itself is fine since I am the one who > > changed the SPIs ;) But it makes me think it is far less of a > maintenance > > effort just to drop it and support just hibernate-ehcache. > > I guess you meant "support just JCache" ? > Oops, yes :) +1 since the new SPI is different. I do wonder if the JCache API will > be a straitjacket for futher performance improvements, but I guess we > could re-insert this module if there's more concrete elements? At > least any work due to SPI changes could be deferred. > For sure part of the new SPI design was to allow the cache providers to make some performance decisions up front. Any caching libraries integrating with Hibernate via hibernate-jcache would definitely lose that opportunity (hibernate-jcache would have to make generalized decisions). However, such providers are welcome to implement and provide their own RegionFactory that makes these kind of decisions. That flexibility is not going away - all that goes away is the specific adaptations of our caching SPI to individual caching libraries. We'll still be testing with Ehcache - over JCache - I hope? > Yeah, we'd probably use Ehcache as the provider for hibernate-jcache testing. Ideally we'd set up a "matrix" style testing to be able to plug in different providers - possibly even testing against both ehcache and spring-cache. infinispan-hibernate-cache would not fit this model as it does not integrate via the JCache abstraction, though we definitely want to make sure that integration is tested as well. From rvansa at redhat.com Thu Mar 15 10:26:09 2018 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 15 Mar 2018 15:26:09 +0100 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: On 03/15/2018 02:56 PM, Steve Ebersole wrote: > Inline.... > > On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero wrote: > >> On 15 March 2018 at 13:04, Steve Ebersole wrote: >>> Given the changes to the second-level cache SPI, I wonder if we want to >>> take that as an opportunity to consider dropping the `hibernate-ehcache` >>> module? >>> >>> There are a few reasons I am considering this... >>> >>> 1. We have the JCache integration in place and users can use Ehcache >>> via that support already. >>> 2. This is really the same discussion we had wrt Spring Cache[1]. IMO >>> the answer should be consistent. We moved hibernate-infinispan for >> many of >>> these same reasons... >>> 3. A large part of the argument for keeping hibernate-ehcache was that >>> it is already in place and therefore did not require much effort to >>> support/maintain. However, given the new SPI there is actually a >> pretty >>> big effort to adapt hibernate-ehcache to those new SPIs. So far I am >> the >>> one doing that - which in and of itself is fine since I am the one who >>> changed the SPIs ;) But it makes me think it is far less of a >> maintenance >>> effort just to drop it and support just hibernate-ehcache. >> I guess you meant "support just JCache" ? >> > Oops, yes :) > > > +1 since the new SPI is different. I do wonder if the JCache API will >> be a straitjacket for futher performance improvements, but I guess we >> could re-insert this module if there's more concrete elements? At >> least any work due to SPI changes could be deferred. >> > For sure part of the new SPI design was to allow the cache providers to > make some performance decisions up front. Any caching libraries > integrating with Hibernate via hibernate-jcache would definitely lose that > opportunity (hibernate-jcache would have to make generalized decisions). > However, such providers are welcome to implement and provide their own > RegionFactory that makes these kind of decisions. That flexibility is not > going away - all that goes away is the specific adaptations of our caching > SPI to individual caching libraries. > > > We'll still be testing with Ehcache - over JCache - I hope? > Yeah, we'd probably use Ehcache as the provider for hibernate-jcache > testing. Ideally we'd set up a "matrix" style testing to be able to plug > in different providers - possibly even testing against both ehcache and > spring-cache. infinispan-hibernate-cache would not fit this model as it > does not integrate via the JCache abstraction, though we definitely want to > make sure that integration is tested as well. Before Infinispan provides native implementation to 5.3/6.0 SPIs, JCache is a good way to bridge the gap. So if you're setting up a matrix testing, adding Infinispan JCache provider would give us some confidence that we can recommend that bridge in the meantime. R. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa JBoss Performance Team From sanne at hibernate.org Thu Mar 15 10:46:26 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 15 Mar 2018 14:46:26 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: On 15 March 2018 at 13:58, Steve Ebersole wrote: > On Thu, Mar 15, 2018 at 8:47 AM Sanne Grinovero wrote: >> >> >> BTW what about all of Alex's sophisticated integration tests? I assume >> they are more thorough in the older Ehcache module than in the JCache >> module; would be a shame to lose those verifications. > > > We'd pull those over to hibernate-jcache. I think that is actually a good > start on a "caching TCK" like Radim has asked about a few times. Sounds great, I just hope that it won't make the amount of work for you even worse than just adjusting the SPIs. Probably still worth it for the better maintainable outcome. From steve at hibernate.org Thu Mar 15 10:57:29 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 15 Mar 2018 14:57:29 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: I'd have to look at the tests :) On Thu, Mar 15, 2018 at 9:46 AM Sanne Grinovero wrote: > On 15 March 2018 at 13:58, Steve Ebersole wrote: > > On Thu, Mar 15, 2018 at 8:47 AM Sanne Grinovero > wrote: > >> > >> > >> BTW what about all of Alex's sophisticated integration tests? I assume > >> they are more thorough in the older Ehcache module than in the JCache > >> module; would be a shame to lose those verifications. > > > > > > We'd pull those over to hibernate-jcache. I think that is actually a > good > > start on a "caching TCK" like Radim has asked about a few times. > > Sounds great, I just hope that it won't make the amount of work for > you even worse than just adjusting the SPIs. Probably still worth it > for the better maintainable outcome. > From steve at hibernate.org Thu Mar 15 10:58:48 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 15 Mar 2018 14:58:48 +0000 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: On Thu, Mar 15, 2018 at 9:30 AM Radim Vansa wrote: > Before Infinispan provides native implementation to 5.3/6.0 SPIs, JCache > is a good way to bridge the gap. So if you're setting up a matrix > testing, adding Infinispan JCache provider would give us some confidence > that we can recommend that bridge in the meantime. > Great to know! I doubt I'll have the time to set up the matrix proper, but for sure we will at least manually test it with Infinispan From chris.w.dennis at gmail.com Thu Mar 15 11:15:58 2018 From: chris.w.dennis at gmail.com (Chris Dennis) Date: Thu, 15 Mar 2018 11:15:58 -0400 Subject: [hibernate-dev] 5.3 - hibernate-ehcache In-Reply-To: References: Message-ID: <3710304B-64E0-4D5F-BD97-8C478DF3623A@gmail.com> +1. From my point of view this makes sense. I?ll need to confer with higher-ups about what we would then do regarding our copy of the Ehcache 2.x provider and whether we want to port it across to the new SPI. That should in principle be a separate discussion, but I?m a little too heads-down in a complex release train process today to follow up on this. Hopefully more interesting/authoritative feedback will be available early next week. Chris > On Mar 15, 2018, at 9:56 AM, Steve Ebersole wrote: > > Inline.... > > On Thu, Mar 15, 2018 at 8:44 AM Sanne Grinovero > wrote: > >> On 15 March 2018 at 13:04, Steve Ebersole wrote: >>> Given the changes to the second-level cache SPI, I wonder if we want to >>> take that as an opportunity to consider dropping the `hibernate-ehcache` >>> module? >>> >>> There are a few reasons I am considering this... >>> >>> 1. We have the JCache integration in place and users can use Ehcache >>> via that support already. >>> 2. This is really the same discussion we had wrt Spring Cache[1]. IMO >>> the answer should be consistent. We moved hibernate-infinispan for >> many of >>> these same reasons... >>> 3. A large part of the argument for keeping hibernate-ehcache was that >>> it is already in place and therefore did not require much effort to >>> support/maintain. However, given the new SPI there is actually a >> pretty >>> big effort to adapt hibernate-ehcache to those new SPIs. So far I am >> the >>> one doing that - which in and of itself is fine since I am the one who >>> changed the SPIs ;) But it makes me think it is far less of a >> maintenance >>> effort just to drop it and support just hibernate-ehcache. >> >> I guess you meant "support just JCache" ? >> > > Oops, yes :) > > > +1 since the new SPI is different. I do wonder if the JCache API will >> be a straitjacket for futher performance improvements, but I guess we >> could re-insert this module if there's more concrete elements? At >> least any work due to SPI changes could be deferred. >> > > For sure part of the new SPI design was to allow the cache providers to > make some performance decisions up front. Any caching libraries > integrating with Hibernate via hibernate-jcache would definitely lose that > opportunity (hibernate-jcache would have to make generalized decisions). > However, such providers are welcome to implement and provide their own > RegionFactory that makes these kind of decisions. That flexibility is not > going away - all that goes away is the specific adaptations of our caching > SPI to individual caching libraries. > > > We'll still be testing with Ehcache - over JCache - I hope? >> > > Yeah, we'd probably use Ehcache as the provider for hibernate-jcache > testing. Ideally we'd set up a "matrix" style testing to be able to plug > in different providers - possibly even testing against both ehcache and > spring-cache. infinispan-hibernate-cache would not fit this model as it > does not integrate via the JCache abstraction, though we definitely want to > make sure that integration is tested as well. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Fri Mar 16 03:36:38 2018 From: gbadner at redhat.com (Gail Badner) Date: Fri, 16 Mar 2018 00:36:38 -0700 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 Message-ID: Hi, There were lots of differences in the compatibility report, so as a first step, I've excluded packages/classes that I considered SPI, internal, or "grey area". This reduced the the differences to a more manageable amount. You can see a summary of the incompatibilities along with suggested mitigation at [1]. The report is attached to [1], along with a zip with instructions for running the report. I believe there are some "false positives" in the report, and I have documented them in the section, "False Positives?". Feel free to comment on the article. Thanks, Gail [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51And53 From gbadner at redhat.com Fri Mar 16 19:09:02 2018 From: gbadner at redhat.com (Gail Badner) Date: Fri, 16 Mar 2018 16:09:02 -0700 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: I've moved the document to https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw . Please let me know if you need an invite to view the document. The attachments are still at https://developer.jboss.org/wiki/ HibernateORMBinaryCompatibilityBetween51And53. Regards, Gail On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner wrote: > Hi, > > There were lots of differences in the compatibility report, so as a first > step, I've excluded packages/classes that I considered SPI, internal, or > "grey area". This reduced the the differences to a more manageable amount. > > You can see a summary of the incompatibilities along with suggested > mitigation at [1]. > > The report is attached to [1], along with a zip with instructions for > running the report. > > I believe there are some "false positives" in the report, and I have > documented them in the section, "False Positives?". > > Feel free to comment on the article. > > Thanks, > Gail > > [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit > yBetween51And53 > > From sanne at hibernate.org Fri Mar 16 19:36:12 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 16 Mar 2018 23:36:12 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: Thanks Gail, great job! I fixed a trivial one, just a thousand to go ;) On 16 March 2018 at 23:09, Gail Badner wrote: > I've moved the document to > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > . > > Please let me know if you need an invite to view the document. > > The attachments are still at https://developer.jboss.org/wiki/ > HibernateORMBinaryCompatibilityBetween51And53. > > Regards, > Gail > > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner wrote: > >> Hi, >> >> There were lots of differences in the compatibility report, so as a first >> step, I've excluded packages/classes that I considered SPI, internal, or >> "grey area". This reduced the the differences to a more manageable amount. >> >> You can see a summary of the incompatibilities along with suggested >> mitigation at [1]. >> >> The report is attached to [1], along with a zip with instructions for >> running the report. >> >> I believe there are some "false positives" in the report, and I have >> documented them in the section, "False Positives?". >> >> Feel free to comment on the article. >> >> Thanks, >> Gail >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit >> yBetween51And53 >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From paranoiabla at gmail.com Mon Mar 19 10:41:54 2018 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Mon, 19 Mar 2018 16:41:54 +0200 Subject: [hibernate-dev] JPA Events Message-ID: Hi guys, I opened an issue in the JPA spec here yesterday: https://github.com/javaee/jpa-spec/issues/167 because @PreUpdate and @PrePersist events are not fired when I save a collection on the owner. Since then, a discussion with Oliver Gierke from the SpringDATA team started and I wanted to know your opinion on this. Basically the question is: if you have Product with a Collection attribute and you update the collection, shall @PreUpdate event be fired. As Oliver mentioned the JPA spec says: ------- The PreUpdate and PostUpdate callbacks occur before and after the database update operations to entity data respectively. ------- so to me it is obvious that when an attribute of the Product is changed then this means that @PreUpdate event for the Product must be fired. What do you think? Should I open a bug in Hibernate? -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From steve at hibernate.org Mon Mar 19 11:32:19 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 19 Mar 2018 15:32:19 +0000 Subject: [hibernate-dev] JPA Events In-Reply-To: References: Message-ID: It is actually very unclear. Look at the wording... "...update operations to *entity* data...". So clearly it boils down to your definition of "entity data" and what is being updated, as Oliver mentions as well. We take the interpretation that since we are not updating the entity table here, we do not fire the event (unless the entity is versioned, in which case the change in the collection would cause a version increment and the entity table to be updated as well). In Hibernate, this would translate to a collection event - but of course JPA has no such notion. And the distinction is actually quite important for supporting things like Envers, so it would need to be a VERY compelling reason to change this behavior in Hibernate. On Mon, Mar 19, 2018 at 9:55 AM Petar Tahchiev wrote: > Hi guys, > > I opened an issue in the JPA spec here yesterday: > > https://github.com/javaee/jpa-spec/issues/167 > > because @PreUpdate and @PrePersist events are not fired when I save a > collection on the owner. Since then, a discussion with Oliver Gierke from > the SpringDATA team started and I wanted to know your opinion on this. > > Basically the question is: if you have Product with a Collection > attribute and you update the collection, shall @PreUpdate event be fired. > > As Oliver mentioned the JPA spec says: > ------- > The PreUpdate and PostUpdate callbacks occur before and after the database > update operations to entity data respectively. > ------- > > so to me it is obvious that when an attribute of the Product is changed > then this means that @PreUpdate event for the Product must be fired. > > What do you think? Should I open a bug in Hibernate? > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Mon Mar 19 12:47:46 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 19 Mar 2018 17:47:46 +0100 Subject: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider() Message-ID: Hi, So I know we like to have API compatibility discussions these days, so let's start a new one. FWIW, this discussions doesn't come out of the blue, it's based on discussions we had for one of Marko's PRs. In HV, you can set the parameter name provider at the VF level and you can also override it on a per Validator basis using HibernateValidatorContext#parameterNameProvider(). To be honest, I'm a bit skeptical about the usefulness of overriding this setting at the Validator level: it really seems to be a global setting, especially because it has an influence on what could be considered a metadata and metadata are considered static in HV. At the moment, the parameter name is resolved at runtime each time it's required due to this feature. I would like to deprecate the feature for now and possibly remove it in a future version (I thought about maybe keeping the method for a while but logging a warning stating it's not doing anything anymore?). We expect some runtime performance enhancement (this is not the reason of this post) but it seems we could also get rid of storing the Executable in the metadata and reduce our memory footprint for executables, which would be nice. Thoughts? -- Guillaume From yoann at hibernate.org Mon Mar 19 13:28:07 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 19 Mar 2018 17:28:07 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] RFC on the Hibernate Search 6 APIs Message-ID: Hello, It's been some time we have been working on a proof-of-concept for Search 6, and I think it is mature enough to receive some early feedback. So to anyone interested: I would love to read your comments! Note that the APIs are not set in stone yet, everything could still change depending on the feedback. To help you form an opinion, I added a "showcase" module with a relatively realistic domain model (that of Libraries and their Books), a Hibernate Search mapping and some queries. The showcase uses the Elasticsearch backend, which is (for now) the only one available; Guillaume is working on the Lucene one. The proof-of-concept is available here: https://github.com/hibernate/hibernate-search-6-poc and the showcase is located in the "integrationtest/showcase/library" directory. You can find: - the domain model, mapped using annotations, in org.hibernate.search.v6poc.integrationtest.showcase.library.model - the data access objects implementing CRUD operations in org.hibernate.search.v6poc.integrationtest.showcase.library.dao; there are various implementations of the same DAO contracts (more on this in another email thread). - the custom bridge implementations in org.hibernate.search.v6poc.integrationtest.showcase.library.bridge (more on this in another email thread) A test allowing you to see it all in action is available in src/test/java/org/hibernate/search/v6poc/integrationtest/showcase/OrmElasticsearchLibraryShowcaseIT.java . You can launch it: - from the command line with "mvn clean install -DskipTests; mvn clean verify -pl integrationtest/showcase/library" (an Elasticsearch instance will be spawned automatically) - or more interstingly from your IDE, with breakpoints. You will need an Elasticsearch cluster running and accessible from localhost:9200. I will be starting separate email threads for some topics I would especially like feedback on. If there are some other topics you would like discussed, feel free to answer here or start another thread. As a reminder, and as an explanation of why so many things changed, here are the main goals of Hibernate Search 6: - Overhaul the APIs to remove the dependency to Lucene, so that other technologies can be integrated without hacks (Elasticsearch in particular, but also maybe in the future Solr). - Overhaul the bridge APIs to allow: - Better integration with other technologies (such as Elasticsearch), in particular by abstracting access to indexed documents (HSEARCH-2186 ) - Detection by Hibernate Search of the properties being used, for better dirty checking [not yet implemented, but the APIs should allow that] (HSEARCH-2496 ) - Overhaul the Query API to: - offer a less verbose syntax for simpler queries - return typed results: if you query the Book index, you get a List, not a raw List (HSEARCH-2225 ) - be generic, yet extensible depending on the integration (e.g. allow to nest Elasticsearch JSON inside a query predicate) (HSEARCH-2498 ) - Generally ensure the architecture: - will allow detection by Hibernate Search of the load graph to use when fetching entities from Hibernate ORM for mass indexing. - will make it easier to implement alternative mappers in the future ( HSEARCH-1800 , HSEARCH-1401 ). While we were at it, I gave a shot to some additional features I felt could be useful: - User-defined bridge annotations for user-defined bridges (HSEARCH-175 ) - Give access to more application context in the bridges (HSEARCH-1839 ) - Comply with the JPA access type when accessing entity properties ( HSEARCH-383 ) -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From yoann at hibernate.org Mon Mar 19 13:34:48 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Mon, 19 Mar 2018 17:34:48 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] Syntax for query building Message-ID: Hello, In Search 6, we are changing the Query DSL APIs to move away from Lucene dependencies. Since this breaks backward compatibility whatever we do, we had a look to improve the the syntax a little bit with some other changes. In particular, for query predicate building, we experimented with three syntaxes when it comes to nesting: - a fully-fluid syntax, allowing nested predicate definition through chained calls (and potentially an ".end()" call where necessary to get back to the parent predicate). - a lambda-based syntax, allowing nested predicate definition by passing lambdas that create the nested predicate. - an "object-based" syntax, allowing to create an object representing your predicate, and then pass it as an argument to another predicate to nest it. This is pretty similar to the QueryBuilder syntax in Search 5. In the showcase module of the proof-of-concept ( https://github.com/hibernate/hibernate-search-6-poc/tree/master/integrationtest/showcase/library), I included multiple implementations of the DAOs to demonstrate various syntaxes. Since the fully-fluid syntax does not allow to handle conditions or loops within a single chained call, some of the implementations actually mix multiple syntaxes: - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.object demonstrates pure "object-based" syntax - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.lambda demonstrates pure "lambda-based" syntax - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.fluidandlambda demonstrates fluid syntax resorting to lambda-based syntax when conditions or loops are necessary. - Package org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.fluidandobject demonstrates fluid syntax resorting to object-based syntax when conditions or loops are necessary. My questions: - Do all of these query building syntaxes make sense to you? - Do you think we need all of them? - Is one better than the others? Some elements of thought: - There may not be a "one-size-fits-all" solution; I personally like the "fluid" syntax best for "shallow" queries with little to no nesting, and the "fluid+lambda" syntax best for deeply nested queries. To make your own opinion, you can have a look at implementations of "DocumentDao#searchAroundMe" for a query with complex nesting, and at implementations of "LibraryDao#search" for a "shallow" query. - Purely lambda or purely object syntax, in my opinion, are more verbose. The syntax feels more "to the point" where we can use chained calls (fluid syntax). - The fluid syntax is not very IDE-friendly when nesting predicates, as code formatting will ignore the implicit structure of chained calls (it will remove indents that previously made nesting obvious). - With lambdas being regularly advised against for various reasons, we might want to offer at least one other way of doing things. -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From paranoiabla at gmail.com Mon Mar 19 14:01:42 2018 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Mon, 19 Mar 2018 20:01:42 +0200 Subject: [hibernate-dev] JPA Events In-Reply-To: References: Message-ID: Hi Steve, thank you for your reply. I really appreciate it. Here's my situation: my client asked me to get the dirty Products. Now the Product has a List manufacturers so to me it is obvious that when the manufacturers are changed then the Product is dirty, and this is exactly what I try to achieve. Unfortunately I can't do this - neither with JPA, nor with Hibernate directly. - JPA has only @PreUpdate and @PrePersist which are not invoked if the List manufacturers are changed. - Hibernate however has several more listeners (PreCollectionUpdateEventListener, PreCollectionRemoveEventListener, PreCollectionRecreateEventListener). So I created my own EventListeners and implement those interfaces. Now when the Collection is modified, I set the Product.isDirty flag to TRUE and try to save the Product. Unfortunately the moment I do that then another PreCollectionUpdate is fired so I get a StackOverflow error. I was thinking to update the product directly with JDBC and bypass Hibernate, but unfortunately my client has requested the solution to be database agnostic and so using plain JDBC will bring me a lot of troubles. I can, however, implement my requirements with EclipseLink, as noted in this comment: https://github.com/javaee/jpa-spec/issues/167#issuecomment-374254412 But I really like Hibernate and I don't want to migrate all my code to EclipseLink :( What does the rest of the Hibernate team think? I know it's a matter of interpretation of the spec, but is it really going to be a big change if PreUpdate events were fired when a List or a Map attributes are changed? 2018-03-19 17:32 GMT+02:00 Steve Ebersole : > It is actually very unclear. Look at the wording... "...update > operations to *entity* data...". So clearly it boils down to your > definition of "entity data" and what is being updated, as Oliver mentions > as well. We take the interpretation that since we are not updating the > entity table here, we do not fire the event (unless the entity is > versioned, in which case the change in the collection would cause a version > increment and the entity table to be updated as well). > > In Hibernate, this would translate to a collection event - but of course > JPA has no such notion. And the distinction is actually quite important > for supporting things like Envers, so it would need to be a VERY compelling > reason to change this behavior in Hibernate. > > On Mon, Mar 19, 2018 at 9:55 AM Petar Tahchiev > wrote: > >> Hi guys, >> >> I opened an issue in the JPA spec here yesterday: >> >> https://github.com/javaee/jpa-spec/issues/167 >> >> because @PreUpdate and @PrePersist events are not fired when I save a >> collection on the owner. Since then, a discussion with Oliver Gierke from >> the SpringDATA team started and I wanted to know your opinion on this. >> >> Basically the question is: if you have Product with a Collection >> attribute and you update the collection, shall @PreUpdate event be fired. >> >> As Oliver mentioned the JPA spec says: >> ------- >> The PreUpdate and PostUpdate callbacks occur before and after the database >> update operations to entity data respectively. >> ------- >> >> so to me it is obvious that when an attribute of the Product is changed >> then this means that @PreUpdate event for the Product must be fired. >> >> What do you think? Should I open a bug in Hibernate? >> >> -- >> Regards, Petar! >> Karlovo, Bulgaria. >> --- >> Public PGP Key at: >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From fercoli at redhat.com Mon Mar 19 14:43:55 2018 From: fercoli at redhat.com (Fabio Massimo Ercoli) Date: Mon, 19 Mar 2018 19:43:55 +0100 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: References: Message-ID: Hi Sanne, what you speak of in my opinion is a very very cool feature. Moreover server-side indexes (and remote dialect) are more suitable for Openshift applications. Using standard javax.persistence.Index APIs could be a very nice alternative to avoid confusion with Hibernate Search client side usage. For the problem (B) maybe we can extend the API (adding a some non standard annotation, at least one for the analyze). I'm really interested in this development. Thank you. Fabio On Wed, Mar 14, 2018 at 12:52 PM, Sanne Grinovero wrote: > Hi all, > > this one is a very desirable feature, yet tricky as there's high > chances of ambiguity and confusion for end users. > > > # Infinispan Remote indexing > > Infinispan embeds the Hibernate Search engine, and uses it to index > data being inserted in any cache having indexing enabled. As you know > Infinispan can be used to store Java POJOs, which get serialized using > JBoss Marshalling - or encoded into Protobuf entries using Infinispan > Protostream as helper layer. > > Hibernate OGM supports both modes, one meant for "Infinispan Embedded" > and one for "Infinispan Remote" as that's what each encoding strategy > is suited for. > > > # Protobuf & indexing > > Protobuf is a well defined format with plenty of documentation which > focuses on a "schema" of the encoding; Hibernate OGM is able to > generate such schemas dynamically and will generate encoders and > decoders which follow the encoding guidelines for Java objects. > > The meta schema of protobuf is not super flexible, yet there's the > option of annotating the Protobuf schema elements using "annotations" > in comments. > Protostream allows inserting Hibernate Search annotations directly in > these comments and will use them to generate the server side indexing > configuration, implicitly also allowing such properties to be queried > using indexed. > > For example you might have this string literally within the comments: > "@Field(store = Store.YES, analyze = Analyze.YES)" > > A full example of schema can be found here [1]. > (The Infinispan documentation is a bit sparse on this as they > encourage people to use another code gen tool, best refer to tests as > examples when working for OGM) > > > # What should OGM users experience? > > A naive solution would be to allow people to use the Hibernate Search > annotations on their JPA entities, and we have OGM copy these into the > generated schema; there's a number of problems with that: > - not all such annotations "translate" equally well [2] > - there's a mismatch between JPA properties and underlying encoding fields > - if I run a FullTextQuery do I expect it to work remotely? > - what if I want to use Hibernate Search locally as well or instead? > - references to local classes obviously won't work (custom > fieldbridges, analyzers, etc..) > > An alternative is to look at these as "indexes" of the underlying > store, so we'd use them to hint the Infinispan server about user > provided hints such as those generated by `javax.persistence.Index`. > I do think this is the cleaner approach, yet has two drawbacks: > A- I guess ORM might implicitly generate some indexes in its metadata > which the user might not have explicitly asked; e.g. accelerate unique > constraints and foreign keys; it's possible these might not be as > useful as expected in the Infinispan case. > B- we won't be able to leverage the awesome full-text capabilities :-( > > I believe A is something we could ignore for now and revisit if > there's actual demand. > > B is also not urgent, yet disappointing limitation as this capability > is a distinguishing feature of this NoSQL. Would we agree that > exposing such full-text capabilities would best be let to an ad-hoc > backend in Hibernate Search 6? > > > Thanks, > Sanne > > 1 - http://blog.infinispan.org/2018/02/restful-queries- > coming-to-infinispan-92.html > 2 - https://github.com/infinispan/infinispan/blob/master/remote- > query/remote-query-server/src/main/java/org/infinispan/ > query/remote/impl/indexing/IndexingMetadataCreator.java#L31 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Mar 19 19:06:25 2018 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 19 Mar 2018 23:06:25 +0000 Subject: [hibernate-dev] Cache testing & JCache Message-ID: The initial hibernate-jcache code would create JCache Cache instance "on the fly" as they were needed if not already defined. As part of a discussion about JCache support, it was agreed that this should not happen. To be clear... the integration code calls javax.cache.CacheManager#getCache(java.lang.String). If we are returned nothing, its a choice between throwing an exception or calling javax.cache.CacheManager#createCache. The consensus among the cache providers was that an exception should be thrown as the standard outcome. However, in testing I wonder if we want to allow that "on the fly" creation to happen. Opinions? And if not, thoughts on how to best pre-define all the needed Cache instances? From gbadner at redhat.com Tue Mar 20 01:16:46 2018 From: gbadner at redhat.com (Gail Badner) Date: Mon, 19 Mar 2018 22:16:46 -0700 Subject: [hibernate-dev] Cannot build documentation in 5.1 branch Message-ID: I'm in the process of releasing 5.1.13, and I'm not able to build Hibernate Integrations Guide. I was able to build it for 5.1.12 without any problem. The task that fails is assembleDocumentation and is the error is below. [1] There have not been any changes to that guide for 5.1.13, so I'm not sure why this would be failing. I even tried executing the same task using 5.1.12 source, and it fails with the same error. I need to tag the release tonight. I'll have to get this resolved somehow tomorrow so I can build the distributions for the release. Does anyone know how to fix this? Thanks, Gail [1] rendering Book(integrationsGuide) en-US/html Extending script classloader with the jdocbookXsl dependencies redirecting console output to file [/home/gbadner/git/hibernate-orm-5.1.13/documentation/target/docbook/work/integrationsGuide/log/console-en-US-html.log] Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd: Error reported by XML parser: The markup declarations contained or pointed to by the document type declaration must be well-formed. Resetting console output :documentation:renderDocBook_integrationsGuide_en-US_html FAILED From yoann at hibernate.org Tue Mar 20 03:56:39 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 20 Mar 2018 07:56:39 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] FieldBridge 2.0 Message-ID: Hello, In Search 6, we are changing the field bridge APIs to move away from Lucene dependencies. Similarly to the query DSL, this breaks backward compatibility whatever we do, so we had a look to improving the field bridge API a bit with some other changes. The result is we have three types of bridges: - *ValueBridges* can be applied to values, i.e. either a property value directly, or container values extracted from the property (list elements, map keys, ...). They cannot be parameterized and cannot have dedicated annotations (at least for now), and they are applied to a mapping using @Field(valueBridge = ...). They are supposed to be applied to simple types (LocalDate, some Enum, some immutable user type, ...) and perform a 1-1 mapping between the value and a *single* index field. Implementations are supposed to work as bidirectional functions: one method transforms the POJO-side type into the Index-side type, and one method does the opposite. - *TypeBridges* can be applied to types, can be parameterized, they each have a dedicated annotation (@MyCustomTypeBridge for instance). Their implementations are supposed to use specific APIs to access both the property values and the index fields, so that Hibernate Search is aware of the necessary input data (useful for dirty checking) and of the index fields created by the bridge, along with their characteristics (field type, stored or not, analyzer, ...). - *PropertyBridges* can be applied to properties, can be parameterized, they each have a dedicated annotation (@MyCustomPropertyBridge for instance). Their implementations are supposed to use specific APIs to access both the property values and the index fields, so that Hibernate Search is aware of the necessary input data (useful for dirty checking) and of the index fields created by the bridge, along with their characteristics (field type, stored or not, analyzer, ...). The expectation is that most users will only need to implement ValueBridge, which is the simpler one. Users with more advanced needs will be able to implement TypeBridge/PropertyBridge, which are more complex but are also much more powerful. Some aspects of the bridge API are still in the works, so don't be alarmed to not see them: - Access to the type/property data in TypeBridge and PropertyBridge is still a bit rough, missing in particular support for container types (List, Map, ...). - During projections, transforming the projected data using bridges is not supported yet. The showcase contains a few simple bridge implementations. - org.hibernate.search.v6poc.integrationtest.showcase.library.bridge. *ISBNBridge* is a ValueBridge. Hibernate Search is able to detect from its class metadata that it can only be applied to ISBN values, and generates a String field. The bridge is applied using a @Field annotation on org.hibernate.search.v6poc.integrationtest.showcase.library.model.Book#isbn. You can find an equivalent use of the bridge in the programmatic mapping in org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor. - Another value bridge is applied to org.hibernate.search.v6poc.integrationtest.showcase.library.model.Library#services and is implicitly applied to every value of the list. - org.hibernate.search.v6poc.integrationtest.showcase.library.bridge. *MultiKeywordStringBridge* is a PropertyBridge which turns a comma-separated string into multiple field values. It is admittedly a very simple PropertyBridge, but it has the advantage of showing pretty clearly how a custom bridge is declared and implemented. The bridge is applied using its custom "@MultiKeywordStringBridge" annotation on org.hibernate.search.v6poc.integrationtest.showcase.library.model.Document#tags. You can find an equivalent use of the bridge in the programmatic mapping in org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor: look for the line where "MultiKeywordStringBridge.Builder" is used. - org.hibernate.search.v6poc.entity.pojo.bridge.builtin.spatial. *GeoPointBridge* is a more representative example of what an advanced bridge could be. It's a built-in bridge, but it could definitely be implemented by a third-party: no internal APIs are used in its implementation. Note that one characteristic of this field is that it can be used both as a TypeBridge or as a PropertyBridge, just as the @Spatial annotation in Search 5. The bridge is applied using its dedicated "@GeoPointBridge" annotation to type org.hibernate.search.v6poc.integrationtest.showcase.library.model.Library, with "@Latitude" and "@Longitude" annotations on the relevant properties of this type. You can find an equivalent use of the bridge in the programmatic mapping in org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor: look for the line where "GeoPointBridge.Builder" is used, and the lines where "LatitudeMarker.Builder" and "LongitudeMarker.Builder" are used. So, with those few examples of bridges... WDYT? -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From yoann at hibernate.org Tue Mar 20 05:37:26 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 20 Mar 2018 09:37:26 +0000 Subject: [hibernate-dev] [HSEARCH][V6-POC] FieldBridge 2.0 In-Reply-To: References: Message-ID: If you want to have a look at the sources on Github directly, and don't want to clone the repo to have a look in your IDE, here is the paragraph listing the bridge implementations, but with links to Github sources: - ISBNBridge is a ValueBridge. Hibernate Search is able to detect from its class metadata that it can only be applied to ISBN values, and generates a String field. The bridge is applied using a @Field annotation on Book#isbn . You can find an equivalent use of the bridge in the programmatic mapping in ProgrammaticMappingContributor . - Another value bridge is applied to Library#services and is implicitly applied to every value of the list. - MultiKeywordStringBridge is a PropertyBridge which turns a comma-separated string into multiple field values. It is admittedly a very simple PropertyBridge, but it has the advantage of showing pretty clearly how a custom bridge is declared and implemented. The bridge is applied using its custom @MultiKeywordStringBridge annotation on Document#tags . You can find an equivalent use of the bridge in the programmatic mapping in ProgrammaticMappingContributor: look for the line where "MultiKeywordStringBridge.Builder" is used . - GeoPointBridge is a more representative example of what an advanced bridge could be. It's a built-in bridge, but it could definitely be implemented by a third-party: no internal APIs are used in its implementation. Note that one characteristic of this field is that it can be used both as a TypeBridge or as a PropertyBridge, just as the @Spatial annotation in Search 5. The bridge is applied using its dedicated @GeoPointBridge annotation to type Library , with @Latitude and @Longitude annotations on the Library#latitude and Library#longitude properties. You can find an equivalent use of the bridge in the programmatic mapping in ProgrammaticMappingContributor: look for the line where "GeoPointBridge.Builder" is used , and the lines where "LatitudeMarker.Builder" and "LongitudeMarker.Builder" are used . On Tue, 20 Mar 2018 at 08:56 Yoann Rodiere wrote: > Hello, > > In Search 6, we are changing the field bridge APIs to move away from > Lucene dependencies. Similarly to the query DSL, this breaks backward > compatibility whatever we do, so we had a look to improving the field > bridge API a bit with some other changes. > > The result is we have three types of bridges: > > - *ValueBridges* can be applied to values, i.e. either a property > value directly, or container values extracted from the property (list > elements, map keys, ...). They cannot be parameterized and cannot have > dedicated annotations (at least for now), and they are applied to a mapping > using @Field(valueBridge = ...). They are supposed to be applied to simple > types (LocalDate, some Enum, some immutable user type, ...) and perform a > 1-1 mapping between the value and a *single* index field. > Implementations are supposed to work as bidirectional functions: one method > transforms the POJO-side type into the Index-side type, and one method does > the opposite. > - *TypeBridges* can be applied to types, can be parameterized, they > each have a dedicated annotation (@MyCustomTypeBridge for instance). Their > implementations are supposed to use specific APIs to access both the > property values and the index fields, so that Hibernate Search is aware of > the necessary input data (useful for dirty checking) and of the index > fields created by the bridge, along with their characteristics (field type, > stored or not, analyzer, ...). > - *PropertyBridges* can be applied to properties, can be > parameterized, they each have a dedicated annotation > (@MyCustomPropertyBridge for instance). Their implementations are supposed > to use specific APIs to access both the property values and the index > fields, so that Hibernate Search is aware of the necessary input data > (useful for dirty checking) and of the index fields created by the bridge, > along with their characteristics (field type, stored or not, analyzer, ...). > > The expectation is that most users will only need to implement > ValueBridge, which is the simpler one. Users with more advanced needs will > be able to implement TypeBridge/PropertyBridge, which are more complex but > are also much more powerful. > > Some aspects of the bridge API are still in the works, so don't be alarmed > to not see them: > > - Access to the type/property data in TypeBridge and PropertyBridge is > still a bit rough, missing in particular support for container types (List, > Map, ...). > - During projections, transforming the projected data using bridges is > not supported yet. > > The showcase contains a few simple bridge implementations. > > - org.hibernate.search.v6poc.integrationtest.showcase.library.bridge. > *ISBNBridge* is a ValueBridge. Hibernate Search is able to detect from > its class metadata that it can only be applied to ISBN values, and > generates a String field. > The bridge is applied using a @Field annotation > on org.hibernate.search.v6poc.integrationtest.showcase.library.model.Book#isbn. > You can find an equivalent use of the bridge in the programmatic > mapping > in org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor. > - Another value bridge is applied > to org.hibernate.search.v6poc.integrationtest.showcase.library.model.Library#services > and is implicitly applied to every value of the list. > - org.hibernate.search.v6poc.integrationtest.showcase.library.bridge. > *MultiKeywordStringBridge* is a PropertyBridge which turns a > comma-separated string into multiple field values. It is admittedly a very > simple PropertyBridge, but it has the advantage of showing pretty clearly > how a custom bridge is declared and implemented. > The bridge is applied using its custom "@MultiKeywordStringBridge" > annotation > on org.hibernate.search.v6poc.integrationtest.showcase.library.model.Document#tags. > You can find an equivalent use of the bridge in the programmatic > mapping in > org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor: > look for the line where "MultiKeywordStringBridge.Builder" is used. > - org.hibernate.search.v6poc.entity.pojo.bridge.builtin.spatial. > *GeoPointBridge* is a more representative example of what an advanced > bridge could be. It's a built-in bridge, but it could definitely be > implemented by a third-party: no internal APIs are used in its > implementation. Note that one characteristic of this field is that it can > be used both as a TypeBridge or as a PropertyBridge, just as the @Spatial > annotation in Search 5. > The bridge is applied using its dedicated "@GeoPointBridge" annotation > to > type org.hibernate.search.v6poc.integrationtest.showcase.library.model.Library, > with "@Latitude" and "@Longitude" annotations on the relevant properties of > this type. > You can find an equivalent use of the bridge in the programmatic > mapping in > org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor: > look for the line where "GeoPointBridge.Builder" is used, and the lines > where "LatitudeMarker.Builder" and "LongitudeMarker.Builder" are used. > > So, with those few examples of bridges... WDYT? > > -- > Yoann Rodiere > yoann at hibernate.org / yrodiere at redhat.com > Software Engineer > Hibernate NoORM team > -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From emmanuel at hibernate.org Tue Mar 20 06:50:47 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 20 Mar 2018 11:50:47 +0100 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: References: Message-ID: <20180320105047.GI74353@hibernate.org> I think treating the client side HSearch input and transparently push it down is a recipe for disaster. Looks cool on paper until you have divergence between HSearch proper and Infinispan's or whatever Infinispan exposes. So yes we could have GridDialect specific metadata information around indexing but I would not reuse Hibernate Search annotations for that. Treat Infinispan like any of the other GridDialect providers. As for the way to express FTQ, then Infinispan needs to make Ickle more powerful. Emmanuel On Wed 18-03-14 11:52, Sanne Grinovero wrote: >Hi all, > >this one is a very desirable feature, yet tricky as there's high >chances of ambiguity and confusion for end users. > > ># Infinispan Remote indexing > >Infinispan embeds the Hibernate Search engine, and uses it to index >data being inserted in any cache having indexing enabled. As you know >Infinispan can be used to store Java POJOs, which get serialized using >JBoss Marshalling - or encoded into Protobuf entries using Infinispan >Protostream as helper layer. > >Hibernate OGM supports both modes, one meant for "Infinispan Embedded" >and one for "Infinispan Remote" as that's what each encoding strategy >is suited for. > > ># Protobuf & indexing > >Protobuf is a well defined format with plenty of documentation which >focuses on a "schema" of the encoding; Hibernate OGM is able to >generate such schemas dynamically and will generate encoders and >decoders which follow the encoding guidelines for Java objects. > >The meta schema of protobuf is not super flexible, yet there's the >option of annotating the Protobuf schema elements using "annotations" >in comments. >Protostream allows inserting Hibernate Search annotations directly in >these comments and will use them to generate the server side indexing >configuration, implicitly also allowing such properties to be queried >using indexed. > >For example you might have this string literally within the comments: > "@Field(store = Store.YES, analyze = Analyze.YES)" > >A full example of schema can be found here [1]. >(The Infinispan documentation is a bit sparse on this as they >encourage people to use another code gen tool, best refer to tests as >examples when working for OGM) > > ># What should OGM users experience? > >A naive solution would be to allow people to use the Hibernate Search >annotations on their JPA entities, and we have OGM copy these into the >generated schema; there's a number of problems with that: > - not all such annotations "translate" equally well [2] > - there's a mismatch between JPA properties and underlying encoding fields > - if I run a FullTextQuery do I expect it to work remotely? > - what if I want to use Hibernate Search locally as well or instead? > - references to local classes obviously won't work (custom >fieldbridges, analyzers, etc..) > >An alternative is to look at these as "indexes" of the underlying >store, so we'd use them to hint the Infinispan server about user >provided hints such as those generated by `javax.persistence.Index`. >I do think this is the cleaner approach, yet has two drawbacks: > A- I guess ORM might implicitly generate some indexes in its metadata >which the user might not have explicitly asked; e.g. accelerate unique >constraints and foreign keys; it's possible these might not be as >useful as expected in the Infinispan case. > B- we won't be able to leverage the awesome full-text capabilities :-( > >I believe A is something we could ignore for now and revisit if >there's actual demand. > >B is also not urgent, yet disappointing limitation as this capability >is a distinguishing feature of this NoSQL. Would we agree that >exposing such full-text capabilities would best be let to an ad-hoc >backend in Hibernate Search 6? > > >Thanks, >Sanne > >1 - http://blog.infinispan.org/2018/02/restful-queries-coming-to-infinispan-92.html >2 - https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/impl/indexing/IndexingMetadataCreator.java#L31 >_______________________________________________ >hibernate-dev mailing list >hibernate-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Tue Mar 20 06:54:42 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 20 Mar 2018 11:54:42 +0100 Subject: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider() In-Reply-To: References: Message-ID: <20180320105442.GJ74353@hibernate.org> Can't you a priori apply your optimization and have a if ( perInstance != perFactory ) backdoor? Meaning I don't really get why you cannot apply your optimization by default and fall back to a slow codepath when the value is overridden. Emmanuel On Mon 18-03-19 17:47, Guillaume Smet wrote: >Hi, > >So I know we like to have API compatibility discussions these days, so >let's start a new one. > >FWIW, this discussions doesn't come out of the blue, it's based on >discussions we had for one of Marko's PRs. > >In HV, you can set the parameter name provider at the VF level and you can >also override it on a per Validator basis using >HibernateValidatorContext#parameterNameProvider(). > >To be honest, I'm a bit skeptical about the usefulness of overriding this >setting at the Validator level: it really seems to be a global setting, >especially because it has an influence on what could be considered a >metadata and metadata are considered static in HV. > >At the moment, the parameter name is resolved at runtime each time it's >required due to this feature. > >I would like to deprecate the feature for now and possibly remove it in a >future version (I thought about maybe keeping the method for a while but >logging a warning stating it's not doing anything anymore?). > >We expect some runtime performance enhancement (this is not the reason of >this post) but it seems we could also get rid of storing the Executable in >the metadata and reduce our memory footprint for executables, which would >be nice. > >Thoughts? > >-- >Guillaume >_______________________________________________ >hibernate-dev mailing list >hibernate-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Tue Mar 20 07:01:17 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 20 Mar 2018 12:01:17 +0100 Subject: [hibernate-dev] Async JDBC proposal Message-ID: <20180320110117.GK74353@hibernate.org> Nothing really new for people at the edge of news but a nice presentation showing how async JDBC will likely work https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw Emmanuel From rvansa at redhat.com Tue Mar 20 07:13:41 2018 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 20 Mar 2018 12:13:41 +0100 Subject: [hibernate-dev] Async JDBC proposal In-Reply-To: <20180320110117.GK74353@hibernate.org> References: <20180320110117.GK74353@hibernate.org> Message-ID: <70835f6d-03ca-2e71-b1a7-49e87b007c2c@redhat.com> Emmanuel, is this a correct link? That one is ORM 5.1 vs. 5.3 binary compatibility analysis... I have seen [1] posted earlier today on; is this what you have in mind? I am very happy that JDBC will have an async variant; we have some plans for asynchronous persistence in Infinispan so this might would be definitely useful to our JDBC stores. I only wish there'd be an async thread-independent JTA next, too. Radim [1] https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database On 03/20/2018 12:01 PM, Emmanuel Bernard wrote: > Nothing really new for people at the edge of news but a nice > presentation showing how async JDBC will likely work > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa JBoss Performance Team From andrea at hibernate.org Tue Mar 20 07:34:33 2018 From: andrea at hibernate.org (andrea boriero) Date: Tue, 20 Mar 2018 11:34:33 +0000 Subject: [hibernate-dev] Cannot build documentation in 5.1 branch In-Reply-To: References: Message-ID: Hi Gail, I have tried and I'm facing the same failure what I noticed is that changing to seems solving the issue. On 20 March 2018 at 05:16, Gail Badner wrote: > I'm in the process of releasing 5.1.13, and I'm not able to build Hibernate > Integrations Guide. I was able to build it for 5.1.12 without any problem. > > The task that fails is assembleDocumentation and is the error is below. [1] > > There have not been any changes to that guide for 5.1.13, so I'm not sure > why this would be failing. > > I even tried executing the same task using 5.1.12 source, and it fails with > the same error. > > I need to tag the release tonight. I'll have to get this resolved somehow > tomorrow so I can build the distributions for the release. > > Does anyone know how to fix this? > > Thanks, > Gail > > [1] > rendering Book(integrationsGuide) en-US/html > Extending script classloader with the jdocbookXsl dependencies > redirecting console output to file > [/home/gbadner/git/hibernate-orm-5.1.13/documentation/target/docbook/work/ > integrationsGuide/log/console-en-US-html.log] > Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd: > Error reported by XML parser: The markup declarations contained or > pointed to by the document type declaration must be well-formed. > Resetting console output > :documentation:renderDocBook_integrationsGuide_en-US_html FAILED > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Tue Mar 20 07:36:53 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 20 Mar 2018 11:36:53 +0000 Subject: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider() In-Reply-To: References: Message-ID: Let's hypotethically assume that some scenario needs this. I'm thinking of an application which as different compilation units, so some module might have been compiled with different conventions and need different name resolvers. Would you enforce such a use case to use different, independently configured ValidatorContext instances? Would that be viable && practical? On 19 March 2018 at 16:47, Guillaume Smet wrote: > Hi, > > So I know we like to have API compatibility discussions these days, so > let's start a new one. > > FWIW, this discussions doesn't come out of the blue, it's based on > discussions we had for one of Marko's PRs. > > In HV, you can set the parameter name provider at the VF level and you can > also override it on a per Validator basis using > HibernateValidatorContext#parameterNameProvider(). > > To be honest, I'm a bit skeptical about the usefulness of overriding this > setting at the Validator level: it really seems to be a global setting, > especially because it has an influence on what could be considered a > metadata and metadata are considered static in HV. > > At the moment, the parameter name is resolved at runtime each time it's > required due to this feature. > > I would like to deprecate the feature for now and possibly remove it in a > future version (I thought about maybe keeping the method for a while but > logging a warning stating it's not doing anything anymore?). > > We expect some runtime performance enhancement (this is not the reason of > this post) but it seems we could also get rid of storing the Executable in > the metadata and reduce our memory footprint for executables, which would > be nice. > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Tue Mar 20 07:41:14 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 20 Mar 2018 11:41:14 +0000 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: <20180320105047.GI74353@hibernate.org> References: <20180320105047.GI74353@hibernate.org> Message-ID: On 20 March 2018 at 10:50, Emmanuel Bernard wrote: > I think treating the client side HSearch input and transparently push it > down is a recipe for disaster. Looks cool on paper until you have > divergence between HSearch proper and Infinispan's or whatever > Infinispan exposes. > ?Looks like we agree on the premise, but you didn't comment on the proposal?? Thanks > > So yes we could have GridDialect specific metadata information around > indexing but I would not reuse Hibernate Search annotations for that. > Treat Infinispan like any of the other GridDialect providers. > > As for the way to express FTQ, then Infinispan needs to make Ickle more > powerful. > > Emmanuel > > > On Wed 18-03-14 11:52, Sanne Grinovero wrote: > >> Hi all, >> >> this one is a very desirable feature, yet tricky as there's high >> chances of ambiguity and confusion for end users. >> >> >> # Infinispan Remote indexing >> >> Infinispan embeds the Hibernate Search engine, and uses it to index >> data being inserted in any cache having indexing enabled. As you know >> Infinispan can be used to store Java POJOs, which get serialized using >> JBoss Marshalling - or encoded into Protobuf entries using Infinispan >> Protostream as helper layer. >> >> Hibernate OGM supports both modes, one meant for "Infinispan Embedded" >> and one for "Infinispan Remote" as that's what each encoding strategy >> is suited for. >> >> >> # Protobuf & indexing >> >> Protobuf is a well defined format with plenty of documentation which >> focuses on a "schema" of the encoding; Hibernate OGM is able to >> generate such schemas dynamically and will generate encoders and >> decoders which follow the encoding guidelines for Java objects. >> >> The meta schema of protobuf is not super flexible, yet there's the >> option of annotating the Protobuf schema elements using "annotations" >> in comments. >> Protostream allows inserting Hibernate Search annotations directly in >> these comments and will use them to generate the server side indexing >> configuration, implicitly also allowing such properties to be queried >> using indexed. >> >> For example you might have this string literally within the comments: >> "@Field(store = Store.YES, analyze = Analyze.YES)" >> >> A full example of schema can be found here [1]. >> (The Infinispan documentation is a bit sparse on this as they >> encourage people to use another code gen tool, best refer to tests as >> examples when working for OGM) >> >> >> # What should OGM users experience? >> >> A naive solution would be to allow people to use the Hibernate Search >> annotations on their JPA entities, and we have OGM copy these into the >> generated schema; there's a number of problems with that: >> - not all such annotations "translate" equally well [2] >> - there's a mismatch between JPA properties and underlying encoding fields >> - if I run a FullTextQuery do I expect it to work remotely? >> - what if I want to use Hibernate Search locally as well or instead? >> - references to local classes obviously won't work (custom >> fieldbridges, analyzers, etc..) >> >> An alternative is to look at these as "indexes" of the underlying >> store, so we'd use them to hint the Infinispan server about user >> provided hints such as those generated by `javax.persistence.Index`. >> I do think this is the cleaner approach, yet has two drawbacks: >> A- I guess ORM might implicitly generate some indexes in its metadata >> which the user might not have explicitly asked; e.g. accelerate unique >> constraints and foreign keys; it's possible these might not be as >> useful as expected in the Infinispan case. >> B- we won't be able to leverage the awesome full-text capabilities :-( >> >> I believe A is something we could ignore for now and revisit if >> there's actual demand. >> >> B is also not urgent, yet disappointing limitation as this capability >> is a distinguishing feature of this NoSQL. Would we agree that >> exposing such full-text capabilities would best be let to an ad-hoc >> backend in Hibernate Search 6? >> >> >> Thanks, >> Sanne >> >> 1 - http://blog.infinispan.org/2018/02/restful-queries-coming- >> to-infinispan-92.html >> 2 - https://github.com/infinispan/infinispan/blob/master/remote- >> query/remote-query-server/src/main/java/org/infinispan/query >> /remote/impl/indexing/IndexingMetadataCreator.java#L31 >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From gunnar at hibernate.org Tue Mar 20 08:06:10 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 20 Mar 2018 13:06:10 +0100 Subject: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider() In-Reply-To: References: Message-ID: This is a spec-level API, defined in ValidatorContext: https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main/java/javax/validation/ValidatorContext.java#L77 So unless we change the rules (there might be some leeway now when formalizing compat rules for Jakarta EE), we cannot really deprecate this feature. 2018-03-19 17:47 GMT+01:00 Guillaume Smet : > Hi, > > So I know we like to have API compatibility discussions these days, so > let's start a new one. > > FWIW, this discussions doesn't come out of the blue, it's based on > discussions we had for one of Marko's PRs. > > In HV, you can set the parameter name provider at the VF level and you can > also override it on a per Validator basis using > HibernateValidatorContext#parameterNameProvider(). > > To be honest, I'm a bit skeptical about the usefulness of overriding this > setting at the Validator level: it really seems to be a global setting, > especially because it has an influence on what could be considered a > metadata and metadata are considered static in HV. > > At the moment, the parameter name is resolved at runtime each time it's > required due to this feature. > > I would like to deprecate the feature for now and possibly remove it in a > future version (I thought about maybe keeping the method for a while but > logging a warning stating it's not doing anything anymore?). > > We expect some runtime performance enhancement (this is not the reason of > this post) but it seems we could also get rid of storing the Executable in > the metadata and reduce our memory footprint for executables, which would > be nice. > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Mar 20 08:24:29 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 20 Mar 2018 13:24:29 +0100 Subject: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider() In-Reply-To: References: Message-ID: On Tue, Mar 20, 2018 at 1:06 PM, Gunnar Morling wrote: > This is a spec-level API, defined in ValidatorContext: > > https://github.com/beanvalidation/beanvalidation- > api/blob/master/src/main/java/javax/validation/ValidatorContext.java#L77 > > So unless we change the rules (there might be some leeway now when > formalizing compat rules for Jakarta EE), we cannot really deprecate this > feature. > Raaah, totally missed it at a quick glance as it's overridden in HibernateValidatorContext for chaining. @Emmanuel unfortunately we would still need to keep the Executable handy in case the parameter name provider is overridden at some point. The idea was to completely get rid of it. Maybe we could have some gain by avoiding the parameter name generation in most cases but I'm not sure it's worth making the code less readable. Let's forget about it. -- Guillaume From sanne at hibernate.org Tue Mar 20 08:27:16 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 20 Mar 2018 12:27:16 +0000 Subject: [hibernate-dev] Cannot build documentation in 5.1 branch In-Reply-To: References: Message-ID: Hi Gail, I was also hoping this would be included in the next 5.1, it was flagged to get your attention: - https://github.com/hibernate/hibernate-orm/pull/2151 On 20 March 2018 at 11:34, andrea boriero wrote: > Hi Gail, > > I have tried and I'm facing the same failure what I noticed is that > changing > > to https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd" ..> > seems solving the issue. > > > On 20 March 2018 at 05:16, Gail Badner wrote: > > > I'm in the process of releasing 5.1.13, and I'm not able to build > Hibernate > > Integrations Guide. I was able to build it for 5.1.12 without any > problem. > > > > The task that fails is assembleDocumentation and is the error is below. > [1] > > > > There have not been any changes to that guide for 5.1.13, so I'm not sure > > why this would be failing. > > > > I even tried executing the same task using 5.1.12 source, and it fails > with > > the same error. > > > > I need to tag the release tonight. I'll have to get this resolved somehow > > tomorrow so I can build the distributions for the release. > > > > Does anyone know how to fix this? > > > > Thanks, > > Gail > > > > [1] > > rendering Book(integrationsGuide) en-US/html > > Extending script classloader with the jdocbookXsl dependencies > > redirecting console output to file > > [/home/gbadner/git/hibernate-orm-5.1.13/documentation/ > target/docbook/work/ > > integrationsGuide/log/console-en-US-html.log] > > Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd: > > Error reported by XML parser: The markup declarations contained or > > pointed to by the document type declaration must be well-formed. > > Resetting console output > > :documentation:renderDocBook_integrationsGuide_en-US_html FAILED > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Mar 20 08:58:00 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 20 Mar 2018 13:58:00 +0100 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages Message-ID: Hi, It's been bugging me for a while and I took some time this morning to do some changes to the post list pages of the blog. We currently display the whole articles whereas I thought it would be better to only display a summary of them and get people to the full article with a button. I pushed the changes on http://staging.in.relation.to/ . It's based on the Asciidoctor preamble (most of the time) so it takes the paragraphs that are before the first title. It's not perfect but it works pretty well for most of the posts. We should probably try to write our posts so that the summary looks good. Thoughts? -- Guillaume From yoann at hibernate.org Tue Mar 20 09:23:39 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Tue, 20 Mar 2018 13:23:39 +0000 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: It's definitely better. There are a few drawbacks, such as the summary not displaying for older, non-asciidoctor posts, but the list was barely usable without your change, so I think it's still an improvement. +1 to merge, thanks for working on this! One improvement we could work on is to add an ellipsis when the summary is too long, to handle those few posts where there isn't any title. Say we would only keep the first 500 characters, something like that, and add "(...)" at the end if we had to truncate the summary. We may be able to hack something in CSS (I'm not sure, but maybe), but in this case I'd rather try to something in Ruby, if possible. Do you think it would be possible? On Tue, 20 Mar 2018 at 14:02 Guillaume Smet wrote: > Hi, > > It's been bugging me for a while and I took some time this morning to do > some changes to the post list pages of the blog. > > We currently display the whole articles whereas I thought it would be > better to only display a summary of them and get people to the full article > with a button. > > I pushed the changes on http://staging.in.relation.to/ . > > It's based on the Asciidoctor preamble (most of the time) so it takes the > paragraphs that are before the first title. It's not perfect but it works > pretty well for most of the posts. We should probably try to write our > posts so that the summary looks good. > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From guillaume.smet at gmail.com Tue Mar 20 11:02:28 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 20 Mar 2018 16:02:28 +0100 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: On Tue, Mar 20, 2018 at 2:23 PM, Yoann Rodiere wrote: > It's definitely better. There are a few drawbacks, such as the summary not > displaying for older, non-asciidoctor posts, but the list was barely usable > without your change, so I think it's still an improvement. > I improved the extraction routine for the older posts. It extracts the very first paragraph when it can. > +1 to merge, thanks for working on this! > > One improvement we could work on is to add an ellipsis when the summary is > too long, to handle those few posts where there isn't any title. Say we > would only keep the first 500 characters, something like that, and add > "(...)" at the end if we had to truncate the summary. > We may be able to hack something in CSS (I'm not sure, but maybe), but in > this case I'd rather try to something in Ruby, if possible. Do you think it > would be possible? > My position on this is that we should take it into account when writing our blog posts. But from now on, if the preamble is longer than 5 paragraphs, I now extract the first 3. It fixes the issue with Gunnar's post on the front page. -- Guillaume From gunnar at hibernate.org Tue Mar 20 11:21:57 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 20 Mar 2018 16:21:57 +0100 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: Great initiative, always wanted to have this! Can you send a PR for debezium.github.io, too ;) 2018-03-20 16:02 GMT+01:00 Guillaume Smet : > On Tue, Mar 20, 2018 at 2:23 PM, Yoann Rodiere > wrote: > > > It's definitely better. There are a few drawbacks, such as the summary > not > > displaying for older, non-asciidoctor posts, but the list was barely > usable > > without your change, so I think it's still an improvement. > > > > I improved the extraction routine for the older posts. It extracts the very > first paragraph when it can. > > > > +1 to merge, thanks for working on this! > > > > One improvement we could work on is to add an ellipsis when the summary > is > > too long, to handle those few posts where there isn't any title. Say we > > would only keep the first 500 characters, something like that, and add > > "(...)" at the end if we had to truncate the summary. > > We may be able to hack something in CSS (I'm not sure, but maybe), but in > > this case I'd rather try to something in Ruby, if possible. Do you think > it > > would be possible? > > > > > My position on this is that we should take it into account when writing our > blog posts. > > But from now on, if the preamble is longer than 5 paragraphs, I now extract > the first 3. It fixes the issue with Gunnar's post on the front page. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Tue Mar 20 12:57:42 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 20 Mar 2018 09:57:42 -0700 Subject: [hibernate-dev] Cannot build documentation in 5.1 branch In-Reply-To: References: Message-ID: Sorry, I missed that PR somehow. It will get into 5.1.14 for sure. On Tue, Mar 20, 2018 at 5:27 AM, Sanne Grinovero wrote: > Hi Gail, > > I was also hoping this would be included in the next 5.1, it was flagged > to get your attention: > - https://github.com/hibernate/hibernate-orm/pull/2151 > > On 20 March 2018 at 11:34, andrea boriero wrote: > >> Hi Gail, >> >> I have tried and I'm facing the same failure what I noticed is that >> changing >> >> to > https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd" ..> >> seems solving the issue. >> >> >> On 20 March 2018 at 05:16, Gail Badner wrote: >> >> > I'm in the process of releasing 5.1.13, and I'm not able to build >> Hibernate >> > Integrations Guide. I was able to build it for 5.1.12 without any >> problem. >> > >> > The task that fails is assembleDocumentation and is the error is below. >> [1] >> > >> > There have not been any changes to that guide for 5.1.13, so I'm not >> sure >> > why this would be failing. >> > >> > I even tried executing the same task using 5.1.12 source, and it fails >> with >> > the same error. >> > >> > I need to tag the release tonight. I'll have to get this resolved >> somehow >> > tomorrow so I can build the distributions for the release. >> > >> > Does anyone know how to fix this? >> > >> > Thanks, >> > Gail >> > >> > [1] >> > rendering Book(integrationsGuide) en-US/html >> > Extending script classloader with the jdocbookXsl dependencies >> > redirecting console output to file >> > [/home/gbadner/git/hibernate-orm-5.1.13/documentation/target >> /docbook/work/ >> > integrationsGuide/log/console-en-US-html.log] >> > Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd: >> > Error reported by XML parser: The markup declarations contained or >> > pointed to by the document type declaration must be well-formed. >> > Resetting console output >> > :documentation:renderDocBook_integrationsGuide_en-US_html FAILED >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From sanne at hibernate.org Tue Mar 20 13:18:15 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 20 Mar 2018 17:18:15 +0000 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: Very nice! This should also mitigate some of the SEO problems. I see e.g. Emmanuel tends to have long unstructured starts - http://staging.in.relation.to/emmanuel-bernard/index.html Maybe you could improve it by forcing a "cut" before images, code snippets and such? Thanks, Sanne On 20 March 2018 at 15:02, Guillaume Smet wrote: > On Tue, Mar 20, 2018 at 2:23 PM, Yoann Rodiere > wrote: > > > It's definitely better. There are a few drawbacks, such as the summary > not > > displaying for older, non-asciidoctor posts, but the list was barely > usable > > without your change, so I think it's still an improvement. > > > > I improved the extraction routine for the older posts. It extracts the very > first paragraph when it can. > > > > +1 to merge, thanks for working on this! > > > > One improvement we could work on is to add an ellipsis when the summary > is > > too long, to handle those few posts where there isn't any title. Say we > > would only keep the first 500 characters, something like that, and add > > "(...)" at the end if we had to truncate the summary. > > We may be able to hack something in CSS (I'm not sure, but maybe), but in > > this case I'd rather try to something in Ruby, if possible. Do you think > it > > would be possible? > > > > > My position on this is that we should take it into account when writing our > blog posts. > > But from now on, if the preamble is longer than 5 paragraphs, I now extract > the first 3. It fixes the issue with Gunnar's post on the front page. > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at gmail.com Tue Mar 20 14:08:29 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 20 Mar 2018 19:08:29 +0100 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero wrote: > Maybe you could improve it by forcing a "cut" before images, code snippets > and such > Made the extraction routine more Emmanuel compliant. There's still this weird post by Vlad on the front page but I prefer to keep the logic as it is as it makes more sense for all the other posts. And it's not that shocking. Just pushed it, we can refine the logic later if there are any more gripes. Thanks all for taking a look. -- Guillaume From mark at lawinegevaar.nl Tue Mar 20 14:09:57 2018 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 20 Mar 2018 19:09:57 +0100 Subject: [hibernate-dev] Async JDBC proposal In-Reply-To: <20180320110117.GK74353@hibernate.org> References: <20180320110117.GK74353@hibernate.org> Message-ID: <128e1b561fc97ac94caaf36a5a2ce5c8@lawinegevaar.nl> Minor nitpick, the proposed asynchronous database API (ADBA) is not part of JDBC, nor does it rely on or use JDBC (or at least implementations doing that wouldn't be truely async). Mark PS Could you send the actual link? On 2018-03-20 12:01, Emmanuel Bernard wrote: > Nothing really new for people at the edge of news but a nice > presentation showing how async JDBC will likely work > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Tue Mar 20 16:23:10 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 20 Mar 2018 21:23:10 +0100 Subject: [hibernate-dev] Async JDBC proposal In-Reply-To: <128e1b561fc97ac94caaf36a5a2ce5c8@lawinegevaar.nl> References: <20180320110117.GK74353@hibernate.org> <128e1b561fc97ac94caaf36a5a2ce5c8@lawinegevaar.nl> Message-ID: I don't know whether that's the resource Emmanuel meant to link to, but it's the most recent presentation on the topic I'm aware of: https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database --Gunnar 2018-03-20 19:09 GMT+01:00 Mark Rotteveel : > Minor nitpick, the proposed asynchronous database API (ADBA) is not part > of JDBC, nor does it rely on or use JDBC (or at least implementations > doing that wouldn't be truely async). > > Mark > > PS Could you send the actual link? > > On 2018-03-20 12:01, Emmanuel Bernard wrote: > > Nothing really new for people at the edge of news but a nice > > presentation showing how async JDBC will likely work > > https://docs.google.com/document/d/1jH0znbYwgvGKHC- > 110zcjRaXLllBsvRKw-pdHrMzRzw > > > > Emmanuel > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mark at lawinegevaar.nl Tue Mar 20 17:17:13 2018 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Tue, 20 Mar 2018 22:17:13 +0100 Subject: [hibernate-dev] Async JDBC proposal In-Reply-To: References: <20180320110117.GK74353@hibernate.org> <128e1b561fc97ac94caaf36a5a2ce5c8@lawinegevaar.nl> Message-ID: <4255fed4e0664f68d68f6d794ce0ed84@lawinegevaar.nl> The slides shown are from last year. Somehow that blog still promotes that ADBA is somehow a replacement of JDBC, instead of a separate API that will exist next to JDBC. Mark On 2018-03-20 21:23, Gunnar Morling wrote: > I don't know whether that's the resource Emmanuel meant to link to, > but it's the most recent presentation on the topic I'm aware of: > > > https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database > > --Gunnar > > 2018-03-20 19:09 GMT+01:00 Mark Rotteveel : > >> Minor nitpick, the proposed asynchronous database API (ADBA) is not >> part >> of JDBC, nor does it rely on or use JDBC (or at least >> implementations >> doing that wouldn't be truely async). >> >> Mark >> >> PS Could you send the actual link? >> >> On 2018-03-20 12:01, Emmanuel Bernard wrote: >>> Nothing really new for people at the edge of news but a nice >>> presentation showing how async JDBC will likely work >>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >> [1] >>> >>> Emmanuel >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev [2] >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev [2] > > > > Links: > ------ > [1] > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > [2] https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Tue Mar 20 23:57:49 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 20 Mar 2018 20:57:49 -0700 Subject: [hibernate-dev] Cannot build documentation in 5.1 branch In-Reply-To: References: Message-ID: Andrea, Your suggestion to use " https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd" worked great. Thanks! Gail On Tue, Mar 20, 2018 at 9:57 AM, Gail Badner wrote: > Sorry, I missed that PR somehow. It will get into 5.1.14 for sure. > > On Tue, Mar 20, 2018 at 5:27 AM, Sanne Grinovero > wrote: > >> Hi Gail, >> >> I was also hoping this would be included in the next 5.1, it was flagged >> to get your attention: >> - https://github.com/hibernate/hibernate-orm/pull/2151 >> >> On 20 March 2018 at 11:34, andrea boriero wrote: >> >>> Hi Gail, >>> >>> I have tried and I'm facing the same failure what I noticed is that >>> changing >>> >>> to >> https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd" ..> >>> seems solving the issue. >>> >>> >>> On 20 March 2018 at 05:16, Gail Badner wrote: >>> >>> > I'm in the process of releasing 5.1.13, and I'm not able to build >>> Hibernate >>> > Integrations Guide. I was able to build it for 5.1.12 without any >>> problem. >>> > >>> > The task that fails is assembleDocumentation and is the error is >>> below. [1] >>> > >>> > There have not been any changes to that guide for 5.1.13, so I'm not >>> sure >>> > why this would be failing. >>> > >>> > I even tried executing the same task using 5.1.12 source, and it fails >>> with >>> > the same error. >>> > >>> > I need to tag the release tonight. I'll have to get this resolved >>> somehow >>> > tomorrow so I can build the distributions for the release. >>> > >>> > Does anyone know how to fix this? >>> > >>> > Thanks, >>> > Gail >>> > >>> > [1] >>> > rendering Book(integrationsGuide) en-US/html >>> > Extending script classloader with the jdocbookXsl dependencies >>> > redirecting console output to file >>> > [/home/gbadner/git/hibernate-orm-5.1.13/documentation/target >>> /docbook/work/ >>> > integrationsGuide/log/console-en-US-html.log] >>> > Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd >>> : >>> > Error reported by XML parser: The markup declarations contained or >>> > pointed to by the document type declaration must be well-formed. >>> > Resetting console output >>> > :documentation:renderDocBook_integrationsGuide_en-US_html FAILED >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > From gbadner at redhat.com Wed Mar 21 00:20:40 2018 From: gbadner at redhat.com (Gail Badner) Date: Tue, 20 Mar 2018 21:20:40 -0700 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final Message-ID: I am able to build the documentation using Andrea's suggestion and now I'm struggling with gradle. I released the staging repository on nexus last night to make a deadline. I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was probably a mistake. Today I went back to build the distributions. The problem is that after setting the version back to 5.1.13.Final in build.gradle, gradle automatically recompiles and rebuilds the jars. That is (obviously) a problem because they won't be the same as what was uploaded to nexus. I've been trying some things out on a copy of the directory so I still have the original jars intact. I've tried --no-rebuild, but it doesn't seem to work. Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but I really don't want to do that. Any suggestions? Thanks! Gail From paranoiabla at gmail.com Wed Mar 21 02:35:10 2018 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Wed, 21 Mar 2018 08:35:10 +0200 Subject: [hibernate-dev] JPA Events In-Reply-To: References: Message-ID: Hi guys, any idea how to overcome this? Like I said, when I create my JPA listener with the following: @Override public void onPreUpdateCollection(PreCollectionUpdateEvent event) { super.touchForUpdate(event.getAffectedOwnerOrNull()); updateCollectionOwner(event); } private void updateCollectionOwner(AbstractCollectionEvent event) { AbstractEntityDefinition aem = (AbstractEntityDefinition) event.getAffectedOwnerOrNull(); if (aem != null) { EntityManagerFactory emf = ApplicationContextProvider.getApplicationContext().getBean("entityManagerFactory", EntityManagerFactory.class); EntityManager em = EntityManagerFactoryUtils.getTransactionalEntityManager(emf); try { LOG.debug("Updating lastModifiedDate of: {}", aem.getEntityName()); String hql = "UPDATE " + aem.getEntityName() + " SET " + LAST_MODIFIED_ATTRIBUTE + " = :attr WHERE id = :id"; Query updateQuery = em.createQuery(hql); updateQuery.setParameter("attr", aem.getLastModifiedDate()); updateQuery.setParameter("id", aem.getId()); int result = updateQuery.executeUpdate(); LOG.debug(String.valueOf(result)); } catch (Exception ex) { LOG.error(ex.getMessage(), ex); } } } Then I get stackoverflow, because when updateQuery.executeUpdate(); is called, then another PreCollectionUpdateEvent is raised (even though as you can see in my query I am only updating the LAST_MODIFIED_ATTRIBUTE and no other field). Is this a bug? Why is PrecollectionUpdateEvent fired when I am only updating one field of type LocalDateTime? 2018-03-19 20:01 GMT+02:00 Petar Tahchiev : > Hi Steve, > > thank you for your reply. I really appreciate it. Here's my situation: my > client asked me to get the dirty Products. Now the Product has a > List manufacturers so to me it is obvious that when the > manufacturers are changed then the Product is dirty, and this is exactly > what I try to achieve. > Unfortunately I can't do this - neither with JPA, nor with Hibernate > directly. > > - JPA has only @PreUpdate and @PrePersist which are not invoked if the > List manufacturers are changed. > > - Hibernate however has several more listeners ( > PreCollectionUpdateEventListener, PreCollectionRemoveEventListener, > PreCollectionRecreateEventListener). So I created my own EventListeners > and implement those interfaces. Now when the Collection is > modified, I set the Product.isDirty flag to TRUE and try to save the > Product. Unfortunately the moment I do that then another > PreCollectionUpdate is fired so I get a StackOverflow error. I was thinking > to update the product directly with JDBC and bypass Hibernate, but > unfortunately my client has requested the solution to be database agnostic > and so using plain JDBC will bring me a lot of troubles. > > I can, however, implement my requirements with EclipseLink, as noted in > this comment: > > https://github.com/javaee/jpa-spec/issues/167#issuecomment-374254412 > > But I really like Hibernate and I don't want to migrate all my code to > EclipseLink :( > > What does the rest of the Hibernate team think? I know it's a matter of > interpretation of the spec, but is it really going to be a big change if > PreUpdate events were fired when a List or a Map > attributes are changed? > > > 2018-03-19 17:32 GMT+02:00 Steve Ebersole : > >> It is actually very unclear. Look at the wording... "...update >> operations to *entity* data...". So clearly it boils down to your >> definition of "entity data" and what is being updated, as Oliver mentions >> as well. We take the interpretation that since we are not updating the >> entity table here, we do not fire the event (unless the entity is >> versioned, in which case the change in the collection would cause a version >> increment and the entity table to be updated as well). >> >> In Hibernate, this would translate to a collection event - but of course >> JPA has no such notion. And the distinction is actually quite important >> for supporting things like Envers, so it would need to be a VERY compelling >> reason to change this behavior in Hibernate. >> >> On Mon, Mar 19, 2018 at 9:55 AM Petar Tahchiev >> wrote: >> >>> Hi guys, >>> >>> I opened an issue in the JPA spec here yesterday: >>> >>> https://github.com/javaee/jpa-spec/issues/167 >>> >>> because @PreUpdate and @PrePersist events are not fired when I save a >>> collection on the owner. Since then, a discussion with Oliver Gierke from >>> the SpringDATA team started and I wanted to know your opinion on this. >>> >>> Basically the question is: if you have Product with a Collection >>> attribute and you update the collection, shall @PreUpdate event be fired. >>> >>> As Oliver mentioned the JPA spec says: >>> ------- >>> The PreUpdate and PostUpdate callbacks occur before and after the >>> database >>> update operations to entity data respectively. >>> ------- >>> >>> so to me it is obvious that when an attribute of the Product is changed >>> then this means that @PreUpdate event for the Product must be fired. >>> >>> What do you think? Should I open a bug in Hibernate? >>> >>> -- >>> Regards, Petar! >>> Karlovo, Bulgaria. >>> --- >>> Public PGP Key at: >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > > > -- > Regards, Petar! > Karlovo, Bulgaria. > --- > Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search= > 0x19658550C3110611 > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 > -- Regards, Petar! Karlovo, Bulgaria. --- Public PGP Key at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 From gbadner at redhat.com Wed Mar 21 03:41:47 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 21 Mar 2018 00:41:47 -0700 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: I suppose another alternative is to make the distributions manually. On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner wrote: > I am able to build the documentation using Andrea's suggestion and now I'm > struggling with gradle. > > I released the staging repository on nexus last night to make a deadline. > > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was > probably a mistake. > > Today I went back to build the distributions. The problem is that after > setting the version back to 5.1.13.Final in build.gradle, gradle > automatically recompiles and rebuilds the jars. > > That is (obviously) a problem because they won't be the same as what was > uploaded to nexus. > > I've been trying some things out on a copy of the directory so I still > have the original jars intact. > > I've tried --no-rebuild, but it doesn't seem to work. > > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but I > really don't want to do that. > > Any suggestions? > > Thanks! > Gail > From guillaume.smet at gmail.com Wed Mar 21 06:15:26 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 21 Mar 2018 11:15:26 +0100 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: As per Gunnar's request, you can now use the ++++++ marker to explicitly mark the end of the preamble (same as in Hugo). For an example: posts/Gunnar/2018-02-26-putting-bean-validation-constraints-to-multimaps.adoc -- Guillaume On Tue, Mar 20, 2018 at 7:08 PM, Guillaume Smet wrote: > On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero > wrote: > >> Maybe you could improve it by forcing a "cut" before images, code >> snippets and such >> > > Made the extraction routine more Emmanuel compliant. > > There's still this weird post by Vlad on the front page but I prefer to > keep the logic as it is as it makes more sense for all the other posts. And > it's not that shocking. > > Just pushed it, we can refine the logic later if there are any more gripes. > > Thanks all for taking a look. > > -- > Guillaume > From sanne at hibernate.org Wed Mar 21 06:30:34 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 21 Mar 2018 10:30:34 +0000 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: Great, thanks again Guillaume! On 21 March 2018 at 10:15, Guillaume Smet wrote: > As per Gunnar's request, you can now use the ++++++ marker to > explicitly mark the end of the preamble (same as in Hugo). > > For an example: posts/Gunnar/2018-02-26-putting-bean-validation- > constraints-to-multimaps.adoc > > -- > Guillaume > > On Tue, Mar 20, 2018 at 7:08 PM, Guillaume Smet > wrote: > >> On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero >> wrote: >> >>> Maybe you could improve it by forcing a "cut" before images, code >>> snippets and such >>> >> >> Made the extraction routine more Emmanuel compliant. >> >> There's still this weird post by Vlad on the front page but I prefer to >> keep the logic as it is as it makes more sense for all the other posts. And >> it's not that shocking. >> >> Just pushed it, we can refine the logic later if there are any more >> gripes. >> >> Thanks all for taking a look. >> >> -- >> Guillaume >> > > From rory.odonnell at oracle.com Wed Mar 21 07:08:44 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 21 Mar 2018 11:08:44 +0000 Subject: [hibernate-dev] Release Announcement: General Availability of JDK 10 Message-ID: Hi Sanne, A number of items to share with you today : *1) JDK 10 General Availability * JDK 10, the first release produced under the six-month rapid-cadence release model [1][2], is now Generally Available. We've identified no P1 bugs since we promoted build 46 almost two weeks ago, so that is the official GA release, ready for production use. GPL'd binaries from Oracle are available here: http://jdk.java.net/10 This release includes twelve features: * 286: Local-Variable Type Inference * 296: Consolidate the JDK Forest into a Single Repository * 304: Garbage-Collector Interface * 307: Parallel Full GC for G1 * 310: Application Class-Data Sharing * 312: Thread-Local Handshakes * 313: Remove the Native-Header Generation Tool (javah) * 314: Additional Unicode Language-Tag Extensions * 316: Heap Allocation on Alternative Memory Devices * 317: Experimental Java-Based JIT Compiler * 319: Root Certificates * 322: Time-Based Release Versioning *2) JDK 11 EA build 5, under both the GPL and Oracle EA licenses, are now available at **http://jdk.java.net/11**.* * Schedule, status & features o http://openjdk.java.net/projects/jdk/11/ * Release Notes: o http://jdk.java.net/11/release-notes * Summary of changes o https://download.java.net/java/early_access/jdk11/5/jdk-11+5.html *3) The Z Garbage Collector Project, early access builds available : * The first EA binary from from The Z Garbage Collector Project, also known as ZGC, is now available. ZGC is a scalable low latency garbage collector. For information on how to enable and use ZGC, please see the project wiki. * Project page: http://openjdk.java.net/projects/zgc/ * Wiki: https://wiki.openjdk.java.net/display/zgc/Main *4) Quality Outreach Report for **March 2018 **is available * * https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2018 *5) **Java Client Roadmap Update * * We posted a blog [3] and related white paper [4] detailing our plans for the Java Client. Rgds,Rory [1] https://mreinhold.org/blog/forward-faster [2] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3] Blog: https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates [4] Whitepaper: http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From gunnar at hibernate.org Wed Mar 21 07:58:54 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 21 Mar 2018 12:58:54 +0100 Subject: [hibernate-dev] [in.relation.to] Only display post summary in list pages In-Reply-To: References: Message-ID: Excellent, very nice! Thanks, Guilllaume! 2018-03-21 11:15 GMT+01:00 Guillaume Smet : > As per Gunnar's request, you can now use the ++++++ marker to > explicitly mark the end of the preamble (same as in Hugo). > > For an example: > posts/Gunnar/2018-02-26-putting-bean-validation- > constraints-to-multimaps.adoc > > -- > Guillaume > > On Tue, Mar 20, 2018 at 7:08 PM, Guillaume Smet > wrote: > > > On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero > > wrote: > > > >> Maybe you could improve it by forcing a "cut" before images, code > >> snippets and such > >> > > > > Made the extraction routine more Emmanuel compliant. > > > > There's still this weird post by Vlad on the front page but I prefer to > > keep the logic as it is as it makes more sense for all the other posts. > And > > it's not that shocking. > > > > Just pushed it, we can refine the logic later if there are any more > gripes. > > > > Thanks all for taking a look. > > > > -- > > Guillaume > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Wed Mar 21 08:43:08 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Mar 2018 12:43:08 +0000 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: You could have avoided that up front by disabling the up-to-date checks. But now your original local jars are gone... That said, it really does not matter if the jars are the *same* (as in ==) - it just matters that they are functionally the same. Checking out the tag/ref, changing the version and running the build should be good enough. On Wed, Mar 21, 2018, 2:42 AM Gail Badner wrote: > I suppose another alternative is to make the distributions manually. > > On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner wrote: > > > I am able to build the documentation using Andrea's suggestion and now > I'm > > struggling with gradle. > > > > I released the staging repository on nexus last night to make a deadline. > > > > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was > > probably a mistake. > > > > Today I went back to build the distributions. The problem is that after > > setting the version back to 5.1.13.Final in build.gradle, gradle > > automatically recompiles and rebuilds the jars. > > > > That is (obviously) a problem because they won't be the same as what was > > uploaded to nexus. > > > > I've been trying some things out on a copy of the directory so I still > > have the original jars intact. > > > > I've tried --no-rebuild, but it doesn't seem to work. > > > > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but > I > > really don't want to do that. > > > > Any suggestions? > > > > Thanks! > > Gail > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Wed Mar 21 13:42:55 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 21 Mar 2018 10:42:55 -0700 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: I still have the original jars. I was experimenting on a copy. How do I disable the up-to-date checks? On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole wrote: > You could have avoided that up front by disabling the up-to-date checks. > But now your original local jars are gone... > > That said, it really does not matter if the jars are the *same* (as in ==) > - it just matters that they are functionally the same. Checking out the > tag/ref, changing the version and running the build should be good enough. > > > On Wed, Mar 21, 2018, 2:42 AM Gail Badner wrote: > >> I suppose another alternative is to make the distributions manually. >> >> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner wrote: >> >> > I am able to build the documentation using Andrea's suggestion and now >> I'm >> > struggling with gradle. >> > >> > I released the staging repository on nexus last night to make a >> deadline. >> > >> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was >> > probably a mistake. >> > >> > Today I went back to build the distributions. The problem is that after >> > setting the version back to 5.1.13.Final in build.gradle, gradle >> > automatically recompiles and rebuilds the jars. >> > >> > That is (obviously) a problem because they won't be the same as what was >> > uploaded to nexus. >> > >> > I've been trying some things out on a copy of the directory so I still >> > have the original jars intact. >> > >> > I've tried --no-rebuild, but it doesn't seem to work. >> > >> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, >> but I >> > really don't want to do that. >> > >> > Any suggestions? >> > >> > Thanks! >> > Gail >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From steve at hibernate.org Wed Mar 21 13:50:21 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Mar 2018 17:50:21 +0000 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: The easiest is to just skip the jar tasks using -x. And aggregated javadocs task. Unfortunately I think you would nee to list them all individually On Wed, Mar 21, 2018 at 12:42 PM Gail Badner wrote: > I still have the original jars. I was experimenting on a copy. > > How do I disable the up-to-date checks? > > On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole > wrote: > >> You could have avoided that up front by disabling the up-to-date checks. >> But now your original local jars are gone... >> >> That said, it really does not matter if the jars are the *same* (as in >> ==) - it just matters that they are functionally the same. Checking out >> the tag/ref, changing the version and running the build should be good >> enough. >> >> >> On Wed, Mar 21, 2018, 2:42 AM Gail Badner wrote: >> >>> I suppose another alternative is to make the distributions manually. >>> >>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner wrote: >>> >>> > I am able to build the documentation using Andrea's suggestion and now >>> I'm >>> > struggling with gradle. >>> > >>> > I released the staging repository on nexus last night to make a >>> deadline. >>> > >>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which >>> was >>> > probably a mistake. >>> > >>> > Today I went back to build the distributions. The problem is that after >>> > setting the version back to 5.1.13.Final in build.gradle, gradle >>> > automatically recompiles and rebuilds the jars. >>> > >>> > That is (obviously) a problem because they won't be the same as what >>> was >>> > uploaded to nexus. >>> > >>> > I've been trying some things out on a copy of the directory so I still >>> > have the original jars intact. >>> > >>> > I've tried --no-rebuild, but it doesn't seem to work. >>> > >>> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, >>> but I >>> > really don't want to do that. >>> > >>> > Any suggestions? >>> > >>> > Thanks! >>> > Gail >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From gbadner at redhat.com Wed Mar 21 14:07:49 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 21 Mar 2018 11:07:49 -0700 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: OK, I'll give it a try. Thanks! On Wed, Mar 21, 2018 at 10:50 AM, Steve Ebersole wrote: > The easiest is to just skip the jar tasks using -x. And aggregated > javadocs task. Unfortunately I think you would nee to list them all > individually > > On Wed, Mar 21, 2018 at 12:42 PM Gail Badner wrote: > >> I still have the original jars. I was experimenting on a copy. >> >> How do I disable the up-to-date checks? >> >> On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole >> wrote: >> >>> You could have avoided that up front by disabling the up-to-date >>> checks. But now your original local jars are gone... >>> >>> That said, it really does not matter if the jars are the *same* (as in >>> ==) - it just matters that they are functionally the same. Checking out >>> the tag/ref, changing the version and running the build should be good >>> enough. >>> >>> >>> On Wed, Mar 21, 2018, 2:42 AM Gail Badner wrote: >>> >>>> I suppose another alternative is to make the distributions manually. >>>> >>>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner >>>> wrote: >>>> >>>> > I am able to build the documentation using Andrea's suggestion and >>>> now I'm >>>> > struggling with gradle. >>>> > >>>> > I released the staging repository on nexus last night to make a >>>> deadline. >>>> > >>>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which >>>> was >>>> > probably a mistake. >>>> > >>>> > Today I went back to build the distributions. The problem is that >>>> after >>>> > setting the version back to 5.1.13.Final in build.gradle, gradle >>>> > automatically recompiles and rebuilds the jars. >>>> > >>>> > That is (obviously) a problem because they won't be the same as what >>>> was >>>> > uploaded to nexus. >>>> > >>>> > I've been trying some things out on a copy of the directory so I still >>>> > have the original jars intact. >>>> > >>>> > I've tried --no-rebuild, but it doesn't seem to work. >>>> > >>>> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, >>>> but I >>>> > really don't want to do that. >>>> > >>>> > Any suggestions? >>>> > >>>> > Thanks! >>>> > Gail >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >> From steve at hibernate.org Wed Mar 21 14:42:59 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Mar 2018 18:42:59 +0000 Subject: [hibernate-dev] Defaultable service strategies Message-ID: Thoughts on allowing certain services to be defaulted to the single implementor registered with the `StrategySelector` service when there is just one? For example, when resolving the RegionFactory unless both (a) `hibernate.cache.region.factory_class` and (b) one of `hibernate.cache.use_second_level_cache` or `hibernate.cache.use_query_cache` are defined caching support will be disabled. What I am proposing would kick in in this case and check to see if there is just a single RegionFactory registered with the StrategySelector and if so use that one. It would allow Hibernate to more seamlessly operate as a JPA provider too, as currently to use caching with JPA and Hibernate users have to do the normal JPA stuff and then also define these Hibernate settings. It would be nicer if they could just do the JPA stuff. From mihalcea.vlad at gmail.com Wed Mar 21 15:15:16 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 21 Mar 2018 19:15:16 +0000 Subject: [hibernate-dev] Defaultable service strategies In-Reply-To: References: Message-ID: Sounds good to me. Vlad On Wed, 21 Mar 2018, 20:48 Steve Ebersole, wrote: > Thoughts on allowing certain services to be defaulted to the single > implementor registered with the `StrategySelector` service when there is > just one? > > For example, when resolving the RegionFactory unless both (a) > `hibernate.cache.region.factory_class` and (b) one of > `hibernate.cache.use_second_level_cache` or > `hibernate.cache.use_query_cache` are defined caching support will be > disabled. What I am proposing would kick in in this case and check to see > if there is just a single RegionFactory registered with the > StrategySelector and if so use that one. > > It would allow Hibernate to more seamlessly operate as a JPA provider too, > as currently to use caching with JPA and Hibernate users have to do the > normal JPA stuff and then also define these Hibernate settings. It would > be nicer if they could just do the JPA stuff. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Wed Mar 21 15:35:50 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 21 Mar 2018 19:35:50 +0000 Subject: [hibernate-dev] Defaultable service strategies In-Reply-To: References: Message-ID: On 21 March 2018 at 19:15, Vlad Mihalcea wrote: > > Sounds good to me. +1 nice From gbadner at redhat.com Wed Mar 21 19:21:15 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 21 Mar 2018 16:21:15 -0700 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: Worked like a charm. Thanks! On Wed, Mar 21, 2018 at 11:07 AM, Gail Badner wrote: > OK, I'll give it a try. Thanks! > > On Wed, Mar 21, 2018 at 10:50 AM, Steve Ebersole > wrote: > >> The easiest is to just skip the jar tasks using -x. And aggregated >> javadocs task. Unfortunately I think you would nee to list them all >> individually >> >> On Wed, Mar 21, 2018 at 12:42 PM Gail Badner wrote: >> >>> I still have the original jars. I was experimenting on a copy. >>> >>> How do I disable the up-to-date checks? >>> >>> On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole >>> wrote: >>> >>>> You could have avoided that up front by disabling the up-to-date >>>> checks. But now your original local jars are gone... >>>> >>>> That said, it really does not matter if the jars are the *same* (as in >>>> ==) - it just matters that they are functionally the same. Checking out >>>> the tag/ref, changing the version and running the build should be good >>>> enough. >>>> >>>> >>>> On Wed, Mar 21, 2018, 2:42 AM Gail Badner wrote: >>>> >>>>> I suppose another alternative is to make the distributions manually. >>>>> >>>>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner >>>>> wrote: >>>>> >>>>> > I am able to build the documentation using Andrea's suggestion and >>>>> now I'm >>>>> > struggling with gradle. >>>>> > >>>>> > I released the staging repository on nexus last night to make a >>>>> deadline. >>>>> > >>>>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which >>>>> was >>>>> > probably a mistake. >>>>> > >>>>> > Today I went back to build the distributions. The problem is that >>>>> after >>>>> > setting the version back to 5.1.13.Final in build.gradle, gradle >>>>> > automatically recompiles and rebuilds the jars. >>>>> > >>>>> > That is (obviously) a problem because they won't be the same as what >>>>> was >>>>> > uploaded to nexus. >>>>> > >>>>> > I've been trying some things out on a copy of the directory so I >>>>> still >>>>> > have the original jars intact. >>>>> > >>>>> > I've tried --no-rebuild, but it doesn't seem to work. >>>>> > >>>>> > Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, >>>>> but I >>>>> > really don't want to do that. >>>>> > >>>>> > Any suggestions? >>>>> > >>>>> > Thanks! >>>>> > Gail >>>>> > >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>> >>> > From steve at hibernate.org Wed Mar 21 19:26:59 2018 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 21 Mar 2018 23:26:59 +0000 Subject: [hibernate-dev] Problem with releasing 5.1.13.Final In-Reply-To: References: Message-ID: Great! On Wed, Mar 21, 2018 at 6:21 PM Gail Badner wrote: > Worked like a charm. > Thanks! > > On Wed, Mar 21, 2018 at 11:07 AM, Gail Badner wrote: > >> OK, I'll give it a try. Thanks! >> >> On Wed, Mar 21, 2018 at 10:50 AM, Steve Ebersole >> wrote: >> >>> The easiest is to just skip the jar tasks using -x. And aggregated >>> javadocs task. Unfortunately I think you would nee to list them all >>> individually >>> >>> On Wed, Mar 21, 2018 at 12:42 PM Gail Badner wrote: >>> >>>> I still have the original jars. I was experimenting on a copy. >>>> >>>> How do I disable the up-to-date checks? >>>> >>>> On Wed, Mar 21, 2018 at 5:43 AM, Steve Ebersole >>>> wrote: >>>> >>>>> You could have avoided that up front by disabling the up-to-date >>>>> checks. But now your original local jars are gone... >>>>> >>>>> That said, it really does not matter if the jars are the *same* (as in >>>>> ==) - it just matters that they are functionally the same. Checking out >>>>> the tag/ref, changing the version and running the build should be good >>>>> enough. >>>>> >>>>> >>>>> On Wed, Mar 21, 2018, 2:42 AM Gail Badner wrote: >>>>> >>>>>> I suppose another alternative is to make the distributions manually. >>>>>> >>>>>> On Tue, Mar 20, 2018 at 9:20 PM, Gail Badner >>>>>> wrote: >>>>>> >>>>>> > I am able to build the documentation using Andrea's suggestion and >>>>>> now I'm >>>>>> > struggling with gradle. >>>>>> > >>>>>> > I released the staging repository on nexus last night to make a >>>>>> deadline. >>>>>> > >>>>>> > I also updated the version in build.gradle to 5.1.14-SNAPSHOT, >>>>>> which was >>>>>> > probably a mistake. >>>>>> > >>>>>> > Today I went back to build the distributions. The problem is that >>>>>> after >>>>>> > setting the version back to 5.1.13.Final in build.gradle, gradle >>>>>> > automatically recompiles and rebuilds the jars. >>>>>> > >>>>>> > That is (obviously) a problem because they won't be the same as >>>>>> what was >>>>>> > uploaded to nexus. >>>>>> > >>>>>> > I've been trying some things out on a copy of the directory so I >>>>>> still >>>>>> > have the original jars intact. >>>>>> > >>>>>> > I've tried --no-rebuild, but it doesn't seem to work. >>>>>> > >>>>>> > Worst case, I suppose I can re-release as 5.1.14.Final on >>>>>> Wednesday, but I >>>>>> > really don't want to do that. >>>>>> > >>>>>> > Any suggestions? >>>>>> > >>>>>> > Thanks! >>>>>> > Gail >>>>>> > >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> >>>> >> > From gbadner at redhat.com Wed Mar 21 20:21:13 2018 From: gbadner at redhat.com (Gail Badner) Date: Wed, 21 Mar 2018 17:21:13 -0700 Subject: [hibernate-dev] Hibernate ORM 5.1.13.Final Released Message-ID: http://in.relation.to/2018/03/19/hibernate-orm-5113-final-release/ From emmanuel at hibernate.org Thu Mar 22 03:30:23 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 22 Mar 2018 08:30:23 +0100 Subject: [hibernate-dev] Async JDBC proposal In-Reply-To: <70835f6d-03ca-2e71-b1a7-49e87b007c2c@redhat.com> References: <20180320110117.GK74353@hibernate.org> <70835f6d-03ca-2e71-b1a7-49e87b007c2c@redhat.com> Message-ID: <00084B8A-7F2C-4428-8588-C97D5235296F@hibernate.org> Yep correct link, sorry about that :/ https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database > On 20 Mar 2018, at 12:13, Radim Vansa wrote: > > Emmanuel, is this a correct link? That one is ORM 5.1 vs. 5.3 binary > compatibility analysis... > > I have seen [1] posted earlier today on; is this what you have in mind? > > I am very happy that JDBC will have an async variant; we have some plans > for asynchronous persistence in Infinispan so this might would be > definitely useful to our JDBC stores. I only wish there'd be an async > thread-independent JTA next, too. > > Radim > > [1] > https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database > > On 03/20/2018 12:01 PM, Emmanuel Bernard wrote: >> Nothing really new for people at the edge of news but a nice >> presentation showing how async JDBC will likely work >> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Thu Mar 22 03:32:25 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 22 Mar 2018 08:32:25 +0100 Subject: [hibernate-dev] Async JDBC proposal In-Reply-To: <4255fed4e0664f68d68f6d794ce0ed84@lawinegevaar.nl> References: <20180320110117.GK74353@hibernate.org> <128e1b561fc97ac94caaf36a5a2ce5c8@lawinegevaar.nl> <4255fed4e0664f68d68f6d794ce0ed84@lawinegevaar.nl> Message-ID: <5377FDFC-D8EE-4040-B816-8959D90E1DD1@hibernate.org> Slides 8 explicitly says that it is not built on JDBC, is not a replacement but will live alongside. > On 20 Mar 2018, at 22:17, Mark Rotteveel wrote: > > The slides shown are from last year. Somehow that blog still promotes > that ADBA is somehow a replacement of JDBC, instead of a separate API > that will exist next to JDBC. > > Mark > > On 2018-03-20 21:23, Gunnar Morling wrote: >> I don't know whether that's the resource Emmanuel meant to link to, >> but it's the most recent presentation on the topic I'm aware of: >> >> >> https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database >> >> --Gunnar >> >> 2018-03-20 19:09 GMT+01:00 Mark Rotteveel : >> >>> Minor nitpick, the proposed asynchronous database API (ADBA) is not >>> part >>> of JDBC, nor does it rely on or use JDBC (or at least >>> implementations >>> doing that wouldn't be truely async). >>> >>> Mark >>> >>> PS Could you send the actual link? >>> >>> On 2018-03-20 12:01, Emmanuel Bernard wrote: >>>> Nothing really new for people at the edge of news but a nice >>>> presentation showing how async JDBC will likely work >>>> >>> >> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >>> [1] >>>> >>>> Emmanuel >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev [2] >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev [2] >> >> >> >> Links: >> ------ >> [1] >> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >> [2] https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Thu Mar 22 03:38:31 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 22 Mar 2018 08:38:31 +0100 Subject: [hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider() In-Reply-To: References: Message-ID: > On 20 Mar 2018, at 13:24, Guillaume Smet wrote: > > Maybe we could have some gain by avoiding the parameter name generation in > most cases but I'm not sure it's worth making the code less readable. Readability is the root of all evil. I read that somewhere on the internet From emmanuel at hibernate.org Thu Mar 22 03:41:24 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 22 Mar 2018 08:41:24 +0100 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: References: <20180320105047.GI74353@hibernate.org> Message-ID: <36E786C2-285E-47A3-882A-1057AEBC2668@hibernate.org> > On 20 Mar 2018, at 12:41, Sanne Grinovero wrote: > > > > On 20 March 2018 at 10:50, Emmanuel Bernard > wrote: > I think treating the client side HSearch input and transparently push it > down is a recipe for disaster. Looks cool on paper until you have > divergence between HSearch proper and Infinispan's or whatever > Infinispan exposes. > > ?Looks like we agree on the premise, but you didn't comment on the proposal?? > > I did, it?s right below :) Granted that?s an option C. > > > > So yes we could have GridDialect specific metadata information around > indexing but I would not reuse Hibernate Search annotations for that. > Treat Infinispan like any of the other GridDialect providers. > > As for the way to express FTQ, then Infinispan needs to make Ickle more > powerful. > > Emmanuel > > > On Wed 18-03-14 11:52, Sanne Grinovero wrote: > Hi all, > > this one is a very desirable feature, yet tricky as there's high > chances of ambiguity and confusion for end users. > > > # Infinispan Remote indexing > > Infinispan embeds the Hibernate Search engine, and uses it to index > data being inserted in any cache having indexing enabled. As you know > Infinispan can be used to store Java POJOs, which get serialized using > JBoss Marshalling - or encoded into Protobuf entries using Infinispan > Protostream as helper layer. > > Hibernate OGM supports both modes, one meant for "Infinispan Embedded" > and one for "Infinispan Remote" as that's what each encoding strategy > is suited for. > > > # Protobuf & indexing > > Protobuf is a well defined format with plenty of documentation which > focuses on a "schema" of the encoding; Hibernate OGM is able to > generate such schemas dynamically and will generate encoders and > decoders which follow the encoding guidelines for Java objects. > > The meta schema of protobuf is not super flexible, yet there's the > option of annotating the Protobuf schema elements using "annotations" > in comments. > Protostream allows inserting Hibernate Search annotations directly in > these comments and will use them to generate the server side indexing > configuration, implicitly also allowing such properties to be queried > using indexed. > > For example you might have this string literally within the comments: > "@Field(store = Store.YES, analyze = Analyze.YES)" > > A full example of schema can be found here [1]. > (The Infinispan documentation is a bit sparse on this as they > encourage people to use another code gen tool, best refer to tests as > examples when working for OGM) > > > # What should OGM users experience? > > A naive solution would be to allow people to use the Hibernate Search > annotations on their JPA entities, and we have OGM copy these into the > generated schema; there's a number of problems with that: > - not all such annotations "translate" equally well [2] > - there's a mismatch between JPA properties and underlying encoding fields > - if I run a FullTextQuery do I expect it to work remotely? > - what if I want to use Hibernate Search locally as well or instead? > - references to local classes obviously won't work (custom > fieldbridges, analyzers, etc..) > > An alternative is to look at these as "indexes" of the underlying > store, so we'd use them to hint the Infinispan server about user > provided hints such as those generated by `javax.persistence.Index`. > I do think this is the cleaner approach, yet has two drawbacks: > A- I guess ORM might implicitly generate some indexes in its metadata > which the user might not have explicitly asked; e.g. accelerate unique > constraints and foreign keys; it's possible these might not be as > useful as expected in the Infinispan case. > B- we won't be able to leverage the awesome full-text capabilities :-( > > I believe A is something we could ignore for now and revisit if > there's actual demand. > > B is also not urgent, yet disappointing limitation as this capability > is a distinguishing feature of this NoSQL. Would we agree that > exposing such full-text capabilities would best be let to an ad-hoc > backend in Hibernate Search 6? > > > Thanks, > Sanne > > 1 - http://blog.infinispan.org/2018/02/restful-queries-coming-to-infinispan-92.html > 2 - https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/impl/indexing/IndexingMetadataCreator.java#L31 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Thu Mar 22 04:23:02 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 22 Mar 2018 09:23:02 +0100 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? Message-ID: Hi, While talking to a few bloggers from the Java ecosphere at JavaLand last week, the question came up why we have the date in the URL of blog posts. Arguably, it doesn't add value there (we show the date on the actual posts themselves), and makes the URLs slightly worse to read. In particular, we don't allow for browsing posts by year or month (e.g. http://in.relation.to/2018/), so it's even a bit misleading. Omitting the date would also make the original idea of the URL fly again ("in relation to xyz"). Anyone with thoughts whether we should change the scheme (keeping existing ones of course)? That all said, I've no idea whether the date in there is good to have or not in terms of SEO. I suppose it doesn't matter. --Gunnar From sanne at hibernate.org Thu Mar 22 05:46:31 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 09:46:31 +0000 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: <36E786C2-285E-47A3-882A-1057AEBC2668@hibernate.org> References: <20180320105047.GI74353@hibernate.org> <36E786C2-285E-47A3-882A-1057AEBC2668@hibernate.org> Message-ID: On 22 March 2018 at 07:41, Emmanuel Bernard wrote: > > On 20 Mar 2018, at 12:41, Sanne Grinovero wrote: > > > > On 20 March 2018 at 10:50, Emmanuel Bernard wrote: >> >> I think treating the client side HSearch input and transparently push it >> down is a recipe for disaster. Looks cool on paper until you have >> divergence between HSearch proper and Infinispan's or whatever >> Infinispan exposes. > > > Looks like we agree on the premise, but you didn't comment on the proposal? > > > > I did, it?s right below :) Granted that?s an option C. /The/ proposal in my first email is to have an Hibernate Search 6 "backend" to support Infinispan Remote. I see no comments on that, but it's ok since it looks like we agree on the problems I had already listed. Thanks, Sanne > > >> >> >> So yes we could have GridDialect specific metadata information around >> indexing but I would not reuse Hibernate Search annotations for that. >> Treat Infinispan like any of the other GridDialect providers. >> >> As for the way to express FTQ, then Infinispan needs to make Ickle more >> powerful. >> >> Emmanuel >> >> >> On Wed 18-03-14 11:52, Sanne Grinovero wrote: >>> >>> Hi all, >>> >>> this one is a very desirable feature, yet tricky as there's high >>> chances of ambiguity and confusion for end users. >>> >>> >>> # Infinispan Remote indexing >>> >>> Infinispan embeds the Hibernate Search engine, and uses it to index >>> data being inserted in any cache having indexing enabled. As you know >>> Infinispan can be used to store Java POJOs, which get serialized using >>> JBoss Marshalling - or encoded into Protobuf entries using Infinispan >>> Protostream as helper layer. >>> >>> Hibernate OGM supports both modes, one meant for "Infinispan Embedded" >>> and one for "Infinispan Remote" as that's what each encoding strategy >>> is suited for. >>> >>> >>> # Protobuf & indexing >>> >>> Protobuf is a well defined format with plenty of documentation which >>> focuses on a "schema" of the encoding; Hibernate OGM is able to >>> generate such schemas dynamically and will generate encoders and >>> decoders which follow the encoding guidelines for Java objects. >>> >>> The meta schema of protobuf is not super flexible, yet there's the >>> option of annotating the Protobuf schema elements using "annotations" >>> in comments. >>> Protostream allows inserting Hibernate Search annotations directly in >>> these comments and will use them to generate the server side indexing >>> configuration, implicitly also allowing such properties to be queried >>> using indexed. >>> >>> For example you might have this string literally within the comments: >>> "@Field(store = Store.YES, analyze = Analyze.YES)" >>> >>> A full example of schema can be found here [1]. >>> (The Infinispan documentation is a bit sparse on this as they >>> encourage people to use another code gen tool, best refer to tests as >>> examples when working for OGM) >>> >>> >>> # What should OGM users experience? >>> >>> A naive solution would be to allow people to use the Hibernate Search >>> annotations on their JPA entities, and we have OGM copy these into the >>> generated schema; there's a number of problems with that: >>> - not all such annotations "translate" equally well [2] >>> - there's a mismatch between JPA properties and underlying encoding >>> fields >>> - if I run a FullTextQuery do I expect it to work remotely? >>> - what if I want to use Hibernate Search locally as well or instead? >>> - references to local classes obviously won't work (custom >>> fieldbridges, analyzers, etc..) >>> >>> An alternative is to look at these as "indexes" of the underlying >>> store, so we'd use them to hint the Infinispan server about user >>> provided hints such as those generated by `javax.persistence.Index`. >>> I do think this is the cleaner approach, yet has two drawbacks: >>> A- I guess ORM might implicitly generate some indexes in its metadata >>> which the user might not have explicitly asked; e.g. accelerate unique >>> constraints and foreign keys; it's possible these might not be as >>> useful as expected in the Infinispan case. >>> B- we won't be able to leverage the awesome full-text capabilities :-( >>> >>> I believe A is something we could ignore for now and revisit if >>> there's actual demand. >>> >>> B is also not urgent, yet disappointing limitation as this capability >>> is a distinguishing feature of this NoSQL. Would we agree that >>> exposing such full-text capabilities would best be let to an ad-hoc >>> backend in Hibernate Search 6? >>> >>> >>> Thanks, >>> Sanne >>> >>> 1 - >>> http://blog.infinispan.org/2018/02/restful-queries-coming-to-infinispan-92.html >>> 2 - >>> https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/impl/indexing/IndexingMetadataCreator.java#L31 >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From mihalcea.vlad at gmail.com Thu Mar 22 06:49:56 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 22 Mar 2018 12:49:56 +0200 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: Hi, The data in the post slug only makes sense for news sites where posts are highly associated to a given date. In our case, the data works against us as people might think an article is outdated by just inspecting the slug and thinking that a 3 year-old article might not be relevant anymore. It's better if we use simple slug names that capture the article focus keywords and remove the date altogether. Vlad On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling wrote: > Hi, > > While talking to a few bloggers from the Java ecosphere at JavaLand last > week, the question came up why we have the date in the URL of blog posts. > > Arguably, it doesn't add value there (we show the date on the actual posts > themselves), and makes the URLs slightly worse to read. In particular, we > don't allow for browsing posts by year or month (e.g. > http://in.relation.to/2018/), so it's even a bit misleading. Omitting the > date would also make the original idea of the URL fly again ("in relation > to xyz"). > > Anyone with thoughts whether we should change the scheme (keeping existing > ones of course)? > > That all said, I've no idea whether the date in there is good to have or > not in terms of SEO. I suppose it doesn't matter. > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From andrea at hibernate.org Thu Mar 22 07:03:40 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 22 Mar 2018 11:03:40 +0000 Subject: [hibernate-dev] Starting 5.2.16 release Message-ID: *Please do not push anything to 5.2 branch.Thanks,Andrea* From coladict at gmail.com Thu Mar 22 07:25:32 2018 From: coladict at gmail.com (Jordan Gigov) Date: Thu, 22 Mar 2018 13:25:32 +0200 Subject: [hibernate-dev] Starting 5.2.16 release In-Reply-To: References: Message-ID: I was thinking to propose this part of the release process gets changed a bit, so that the commit of a "Final" version never goes into "master", but remains on a tag. Something like this: # detach head git checkout # edit file and change hibernateVersion editor gradle/base-information.gradle # commit while in detached state git add . && git commit # add tag to current untracked HEAD git tag 5.whatever # push the tag git push origin refs/tags/5.whatever This way the release versions do not pollute the branches, but grow besides them, and you don't need to issue "do not push" warnings. On 22 March 2018 at 13:03, andrea boriero wrote: > *Please do not push anything to 5.2 branch.Thanks,Andrea* > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Mar 22 07:47:18 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 11:47:18 +0000 Subject: [hibernate-dev] Starting 5.2.16 release In-Reply-To: References: Message-ID: That's an interesting idea, especially as these messages like "please don't push" are highlighting the current process is fragile. Personally I quite like the fact that I can see the previous tags in my history during development but I guess it's just a habit. What do others think? On 22 March 2018 at 11:25, Jordan Gigov wrote: > I was thinking to propose this part of the release process gets changed a > bit, so that the commit of a "Final" version never goes into "master", but > remains on a tag. > > Something like this: > # detach head > git checkout > # edit file and change hibernateVersion > editor gradle/base-information.gradle > # commit while in detached state > git add . && git commit > # add tag to current untracked HEAD > git tag 5.whatever > # push the tag > git push origin refs/tags/5.whatever > > > This way the release versions do not pollute the branches, but grow besides > them, and you don't need to issue "do not push" warnings. > > On 22 March 2018 at 13:03, andrea boriero wrote: > >> *Please do not push anything to 5.2 branch.Thanks,Andrea* >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Thu Mar 22 08:16:55 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 12:16:55 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? Message-ID: Steve, all, would it be possible to tag a CR2 as soon as the Caching SPI changes are complete? That would help the Infinispan team so they can get started immediately on their side of things. Thanks, Sanne From steve at hibernate.org Thu Mar 22 08:18:58 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 12:18:58 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: There is already a branch that contains these changes that they can work with... no need to wait for a CR. I still want to let Andrea finish the work on TypeConfiguration and BootstrapContext before we cut CR2. On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero wrote: > Steve, all, > > would it be possible to tag a CR2 as soon as the Caching SPI changes > are complete? > > That would help the Infinispan team so they can get started > immediately on their side of things. > > Thanks, > Sanne > From sanne at hibernate.org Thu Mar 22 08:22:21 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 12:22:21 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: On 22 March 2018 at 12:18, Steve Ebersole wrote: > There is already a branch that contains these changes that they can work > with... no need to wait for a CR. I still want to let Andrea finish the > work on TypeConfiguration and BootstrapContext before we cut CR2. It would help to have a tagged release which can be consumed from Maven. Could we not tag this as CR2 and whatever else is coming will be another CRx ? I can do this release if that helps. Thanks, Sanne > > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero wrote: >> >> Steve, all, >> >> would it be possible to tag a CR2 as soon as the Caching SPI changes >> are complete? >> >> That would help the Infinispan team so they can get started >> immediately on their side of things. >> >> Thanks, >> Sanne From yoann at hibernate.org Thu Mar 22 08:24:55 2018 From: yoann at hibernate.org (Yoann Rodiere) Date: Thu, 22 Mar 2018 12:24:55 +0000 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: > The data in the post slug only makes sense for news sites where posts are highly associated to a given date. A lot of our posts are. Release announcements and weekly newsletters in particular. I personally don't see the problem with dates in URLs. I don't see any problem with not having them, either. But I do see a problem with changing the URL scheme: potential dead links, SEO nightmare... We would need a damn good reason to do it, and I'm not sure those you mentioned are enough... On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea wrote: > Hi, > > The data in the post slug only makes sense for news sites where posts are > highly associated to a given date. > > In our case, the data works against us as people might think an article is > outdated by just inspecting the slug and thinking that > a 3 year-old article might not be relevant anymore. > > It's better if we use simple slug names that capture the article focus > keywords and remove the date altogether. > > Vlad > > On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling > wrote: > > > Hi, > > > > While talking to a few bloggers from the Java ecosphere at JavaLand last > > week, the question came up why we have the date in the URL of blog posts. > > > > Arguably, it doesn't add value there (we show the date on the actual > posts > > themselves), and makes the URLs slightly worse to read. In particular, we > > don't allow for browsing posts by year or month (e.g. > > http://in.relation.to/2018/), so it's even a bit misleading. Omitting > the > > date would also make the original idea of the URL fly again ("in relation > > to xyz"). > > > > Anyone with thoughts whether we should change the scheme (keeping > existing > > ones of course)? > > > > That all said, I've no idea whether the date in there is good to have or > > not in terms of SEO. I suppose it doesn't matter. > > > > --Gunnar > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Yoann Rodiere yoann at hibernate.org / yrodiere at redhat.com Software Engineer Hibernate NoORM team From mihalcea.vlad at gmail.com Thu Mar 22 08:29:06 2018 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 22 Mar 2018 14:29:06 +0200 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: I also switched my blog from dates to simple slugs at the beginning of the year. As long as you add the proper Redirection rules in .htaccess_posts, it shouldn't be any problem. Google does not penalize 301 redirects, so you don't lose any SEO ranking if you use 301 redirects. We can also change the slug names for new articles only while leaving the old ones as-is. Vlad On Thu, Mar 22, 2018 at 2:24 PM, Yoann Rodiere wrote: > > The data in the post slug only makes sense for news sites where posts are > highly associated to a given date. > > A lot of our posts are. Release announcements and weekly newsletters in > particular. > > I personally don't see the problem with dates in URLs. I don't see any > problem with not having them, either. But I do see a problem with changing > the URL scheme: potential dead links, SEO nightmare... We would need a damn > good reason to do it, and I'm not sure those you mentioned are enough... > > On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea > wrote: > >> Hi, >> >> The data in the post slug only makes sense for news sites where posts are >> highly associated to a given date. >> >> In our case, the data works against us as people might think an article is >> outdated by just inspecting the slug and thinking that >> a 3 year-old article might not be relevant anymore. >> >> It's better if we use simple slug names that capture the article focus >> keywords and remove the date altogether. >> >> Vlad >> >> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling >> wrote: >> >> > Hi, >> > >> > While talking to a few bloggers from the Java ecosphere at JavaLand last >> > week, the question came up why we have the date in the URL of blog >> posts. >> > >> > Arguably, it doesn't add value there (we show the date on the actual >> posts >> > themselves), and makes the URLs slightly worse to read. In particular, >> we >> > don't allow for browsing posts by year or month (e.g. >> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting >> the >> > date would also make the original idea of the URL fly again ("in >> relation >> > to xyz"). >> > >> > Anyone with thoughts whether we should change the scheme (keeping >> existing >> > ones of course)? >> > >> > That all said, I've no idea whether the date in there is good to have or >> > not in terms of SEO. I suppose it doesn't matter. >> > >> > --Gunnar >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- > Yoann Rodiere > yoann at hibernate.org / yrodiere at redhat.com > Software Engineer > Hibernate NoORM team > From andrea at hibernate.org Thu Mar 22 08:49:40 2018 From: andrea at hibernate.org (andrea boriero) Date: Thu, 22 Mar 2018 12:49:40 +0000 Subject: [hibernate-dev] Hibernate ORM 5.2.16.Final has been released Message-ID: *For details:http://in.relation.to/2018/03/22/hibernate-orm-5216-final-release * From crancran at gmail.com Thu Mar 22 08:56:56 2018 From: crancran at gmail.com (Chris Cranford) Date: Thu, 22 Mar 2018 08:56:56 -0400 Subject: [hibernate-dev] Defaultable service strategies In-Reply-To: References: Message-ID: +1 Makes sense to me. On 03/21/2018 02:42 PM, Steve Ebersole wrote: > Thoughts on allowing certain services to be defaulted to the single > implementor registered with the `StrategySelector` service when there is > just one? > > For example, when resolving the RegionFactory unless both (a) > `hibernate.cache.region.factory_class` and (b) one of > `hibernate.cache.use_second_level_cache` or > `hibernate.cache.use_query_cache` are defined caching support will be > disabled. What I am proposing would kick in in this case and check to see > if there is just a single RegionFactory registered with the > StrategySelector and if so use that one. > > It would allow Hibernate to more seamlessly operate as a JPA provider too, > as currently to use caching with JPA and Hibernate users have to do the > normal JPA stuff and then also define these Hibernate settings. It would > be nicer if they could just do the JPA stuff. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From daltodavide at gmail.com Thu Mar 22 09:14:22 2018 From: daltodavide at gmail.com (Davide D'Alto) Date: Thu, 22 Mar 2018 13:14:22 +0000 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: > I personally don't see the problem with dates in URLs. I don't see any > problem with not having them, either. But I do see a problem with changing > the URL scheme: potential dead links, SEO nightmare... We would need a damn > good reason to do it, and I'm not sure those you mentioned are enough... +1 > In our case, the data works against us as people might think an article is > outdated by just inspecting the slug and thinking that > a 3 year-old article might not be relevant anymore. Even if you remove it from the URL, you still have the published date on every article. The user can still see when the article has been written. This makes sense because we are talking about blog posts. And this argument can also be used in favor of dates: without the date, you might give the impression that the article is always up-to-date and I don't think that's realistic. I'm not against changing it, but, unless we have some real reasons related to SEO or similar, I wouldn't worry too much. Most users are probably more interested to know when the article has been updated anyway (and not when has been published). Davide On Thu, Mar 22, 2018 at 12:24 PM, Yoann Rodiere wrote: >> The data in the post slug only makes sense for news sites where posts are > highly associated to a given date. > > A lot of our posts are. Release announcements and weekly newsletters in > particular. > > I personally don't see the problem with dates in URLs. I don't see any > problem with not having them, either. But I do see a problem with changing > the URL scheme: potential dead links, SEO nightmare... We would need a damn > good reason to do it, and I'm not sure those you mentioned are enough... > > On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea wrote: > >> Hi, >> >> The data in the post slug only makes sense for news sites where posts are >> highly associated to a given date. >> >> In our case, the data works against us as people might think an article is >> outdated by just inspecting the slug and thinking that >> a 3 year-old article might not be relevant anymore. >> >> It's better if we use simple slug names that capture the article focus >> keywords and remove the date altogether. >> >> Vlad >> >> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling >> wrote: >> >> > Hi, >> > >> > While talking to a few bloggers from the Java ecosphere at JavaLand last >> > week, the question came up why we have the date in the URL of blog posts. >> > >> > Arguably, it doesn't add value there (we show the date on the actual >> posts >> > themselves), and makes the URLs slightly worse to read. In particular, we >> > don't allow for browsing posts by year or month (e.g. >> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting >> the >> > date would also make the original idea of the URL fly again ("in relation >> > to xyz"). >> > >> > Anyone with thoughts whether we should change the scheme (keeping >> existing >> > ones of course)? >> > >> > That all said, I've no idea whether the date in there is good to have or >> > not in terms of SEO. I suppose it doesn't matter. >> > >> > --Gunnar >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- > Yoann Rodiere > yoann at hibernate.org / yrodiere at redhat.com > Software Engineer > Hibernate NoORM team > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From daltodavide at gmail.com Thu Mar 22 09:16:44 2018 From: daltodavide at gmail.com (Davide D'Alto) Date: Thu, 22 Mar 2018 13:16:44 +0000 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: By the way, if some articles are more technical and we put some effort in keeping them up-to-date, we could put them in a separate section and just post in the blog about their existence and updates. Davide On Thu, Mar 22, 2018 at 1:14 PM, Davide D'Alto wrote: >> I personally don't see the problem with dates in URLs. I don't see any >> problem with not having them, either. But I do see a problem with changing >> the URL scheme: potential dead links, SEO nightmare... We would need a damn >> good reason to do it, and I'm not sure those you mentioned are enough... > > +1 > >> In our case, the data works against us as people might think an article is >> outdated by just inspecting the slug and thinking that >> a 3 year-old article might not be relevant anymore. > > Even if you remove it from the URL, you still have the published date > on every article. The user can still see when the article has been > written. > This makes sense because we are talking about blog posts. > > And this argument can also be used in favor of dates: > without the date, you might give the impression that the article is > always up-to-date and I don't think that's realistic. > > I'm not against changing it, but, unless we have some real reasons > related to SEO or similar, > I wouldn't worry too much. Most users are probably more interested to > know when the article has been updated anyway (and not when has been > published). > > Davide > > On Thu, Mar 22, 2018 at 12:24 PM, Yoann Rodiere wrote: >>> The data in the post slug only makes sense for news sites where posts are >> highly associated to a given date. >> >> A lot of our posts are. Release announcements and weekly newsletters in >> particular. >> >> I personally don't see the problem with dates in URLs. I don't see any >> problem with not having them, either. But I do see a problem with changing >> the URL scheme: potential dead links, SEO nightmare... We would need a damn >> good reason to do it, and I'm not sure those you mentioned are enough... >> >> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea wrote: >> >>> Hi, >>> >>> The data in the post slug only makes sense for news sites where posts are >>> highly associated to a given date. >>> >>> In our case, the data works against us as people might think an article is >>> outdated by just inspecting the slug and thinking that >>> a 3 year-old article might not be relevant anymore. >>> >>> It's better if we use simple slug names that capture the article focus >>> keywords and remove the date altogether. >>> >>> Vlad >>> >>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling >>> wrote: >>> >>> > Hi, >>> > >>> > While talking to a few bloggers from the Java ecosphere at JavaLand last >>> > week, the question came up why we have the date in the URL of blog posts. >>> > >>> > Arguably, it doesn't add value there (we show the date on the actual >>> posts >>> > themselves), and makes the URLs slightly worse to read. In particular, we >>> > don't allow for browsing posts by year or month (e.g. >>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting >>> the >>> > date would also make the original idea of the URL fly again ("in relation >>> > to xyz"). >>> > >>> > Anyone with thoughts whether we should change the scheme (keeping >>> existing >>> > ones of course)? >>> > >>> > That all said, I've no idea whether the date in there is good to have or >>> > not in terms of SEO. I suppose it doesn't matter. >>> > >>> > --Gunnar >>> > _______________________________________________ >>> > hibernate-dev mailing list >>> > hibernate-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> -- >> Yoann Rodiere >> yoann at hibernate.org / yrodiere at redhat.com >> Software Engineer >> Hibernate NoORM team >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Mar 22 09:17:32 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 13:17:32 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: Like a snapshot? On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero wrote: > On 22 March 2018 at 12:18, Steve Ebersole wrote: > > There is already a branch that contains these changes that they can work > > with... no need to wait for a CR. I still want to let Andrea finish the > > work on TypeConfiguration and BootstrapContext before we cut CR2. > > It would help to have a tagged release which can be consumed from Maven. > > Could we not tag this as CR2 and whatever else is coming will be another > CRx ? > > I can do this release if that helps. > > Thanks, > Sanne > > > > > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero > wrote: > >> > >> Steve, all, > >> > >> would it be possible to tag a CR2 as soon as the Caching SPI changes > >> are complete? > >> > >> That would help the Infinispan team so they can get started > >> immediately on their side of things. > >> > >> Thanks, > >> Sanne > From steve at hibernate.org Thu Mar 22 09:18:08 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 13:18:08 +0000 Subject: [hibernate-dev] Defaultable service strategies In-Reply-To: References: Message-ID: This is part of my cashing change branch if you all wanted to take a look On Thu, Mar 22, 2018, 7:57 AM Chris Cranford wrote: > +1 > > Makes sense to me. > > > On 03/21/2018 02:42 PM, Steve Ebersole wrote: > > Thoughts on allowing certain services to be defaulted to the single > implementor registered with the `StrategySelector` service when there is > just one? > > For example, when resolving the RegionFactory unless both (a) > `hibernate.cache.region.factory_class` and (b) one of > `hibernate.cache.use_second_level_cache` or > `hibernate.cache.use_query_ > > cache` are defined caching support will be > disabled. What I am proposing would kick in in this case and check to see > if there is just a single RegionFactory registered with the > StrategySelector and if so use that one. > > It would allow Hibernate to more seamlessly operate as a JPA provider too, > as currently to use caching with JPA and Hibernate users have to do the > normal JPA stuff and then also define these Hibernate settings. It would > be nicer if they could just do the JPA stuff. > _______________________________________________ > hibernate-dev mailing listhibernate-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev > > > From sanne at hibernate.org Thu Mar 22 09:34:10 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 13:34:10 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: No, snapshots are confusing when you need multiple people to collaborate on a POC. It's not clear if a patch will work the same to others and it's unpractical to match to a specific source commit. Why would we ever publish CRs if SNAPSHOTS are the same. On Thu, 22 Mar 2018, 13:17 Steve Ebersole, wrote: > Like a snapshot? > > On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero wrote: > >> On 22 March 2018 at 12:18, Steve Ebersole wrote: >> > There is already a branch that contains these changes that they can work >> > with... no need to wait for a CR. I still want to let Andrea finish the >> > work on TypeConfiguration and BootstrapContext before we cut CR2. >> >> It would help to have a tagged release which can be consumed from Maven. >> >> Could we not tag this as CR2 and whatever else is coming will be another >> CRx ? >> >> I can do this release if that helps. >> >> Thanks, >> Sanne >> >> > >> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero >> wrote: >> >> >> >> Steve, all, >> >> >> >> would it be possible to tag a CR2 as soon as the Caching SPI changes >> >> are complete? >> >> >> >> That would help the Infinispan team so they can get started >> >> immediately on their side of things. >> >> >> >> Thanks, >> >> Sanne >> > From gunnar at hibernate.org Thu Mar 22 09:39:10 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 22 Mar 2018 14:39:10 +0100 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: Note I'm not suggesting to change any existing URLs. Rather my question is, should we go to the date-less schema for new posts going forward. 2018-03-22 13:24 GMT+01:00 Yoann Rodiere : > > The data in the post slug only makes sense for news sites where posts are > highly associated to a given date. > > A lot of our posts are. Release announcements and weekly newsletters in > particular. > > I personally don't see the problem with dates in URLs. I don't see any > problem with not having them, either. But I do see a problem with changing > the URL scheme: potential dead links, SEO nightmare... We would need a damn > good reason to do it, and I'm not sure those you mentioned are enough... > > On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea > wrote: > >> Hi, >> >> The data in the post slug only makes sense for news sites where posts are >> highly associated to a given date. >> >> In our case, the data works against us as people might think an article is >> outdated by just inspecting the slug and thinking that >> a 3 year-old article might not be relevant anymore. >> >> It's better if we use simple slug names that capture the article focus >> keywords and remove the date altogether. >> >> Vlad >> >> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling >> wrote: >> >> > Hi, >> > >> > While talking to a few bloggers from the Java ecosphere at JavaLand last >> > week, the question came up why we have the date in the URL of blog >> posts. >> > >> > Arguably, it doesn't add value there (we show the date on the actual >> posts >> > themselves), and makes the URLs slightly worse to read. In particular, >> we >> > don't allow for browsing posts by year or month (e.g. >> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting >> the >> > date would also make the original idea of the URL fly again ("in >> relation >> > to xyz"). >> > >> > Anyone with thoughts whether we should change the scheme (keeping >> existing >> > ones of course)? >> > >> > That all said, I've no idea whether the date in there is good to have or >> > not in terms of SEO. I suppose it doesn't matter. >> > >> > --Gunnar >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- > Yoann Rodiere > yoann at hibernate.org / yrodiere at redhat.com > Software Engineer > Hibernate NoORM team > From steve at hibernate.org Thu Mar 22 09:39:25 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 13:39:25 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: Then you'll have to wait. Seems like snapshot is better than waiting but of course your opinion seems just waiting is better... On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero wrote: > > No, snapshots are confusing when you need multiple people to collaborate > on a POC. > > It's not clear if a patch will work the same to others and it's > unpractical to match to a specific source commit. > > Why would we ever publish CRs if SNAPSHOTS are the same. > > On Thu, 22 Mar 2018, 13:17 Steve Ebersole, wrote: > >> Like a snapshot? >> >> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero >> wrote: >> >>> On 22 March 2018 at 12:18, Steve Ebersole wrote: >>> > There is already a branch that contains these changes that they can >>> work >>> > with... no need to wait for a CR. I still want to let Andrea finish >>> the >>> > work on TypeConfiguration and BootstrapContext before we cut CR2. >>> >>> It would help to have a tagged release which can be consumed from Maven. >>> >>> Could we not tag this as CR2 and whatever else is coming will be another >>> CRx ? >>> >>> I can do this release if that helps. >>> >>> Thanks, >>> Sanne >>> >>> > >>> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero >>> wrote: >>> >> >>> >> Steve, all, >>> >> >>> >> would it be possible to tag a CR2 as soon as the Caching SPI changes >>> >> are complete? >>> >> >>> >> That would help the Infinispan team so they can get started >>> >> immediately on their side of things. >>> >> >>> >> Thanks, >>> >> Sanne >>> >> From sanne at hibernate.org Thu Mar 22 09:53:52 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 13:53:52 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: Could you help us understand. None of the SPI changes have been merged in master yet? On 22 March 2018 at 13:39, Steve Ebersole wrote: > Then you'll have to wait. Seems like snapshot is better than waiting but of > course your opinion seems just waiting is better... > > On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero wrote: >> >> >> No, snapshots are confusing when you need multiple people to collaborate >> on a POC. >> >> It's not clear if a patch will work the same to others and it's >> unpractical to match to a specific source commit. >> >> Why would we ever publish CRs if SNAPSHOTS are the same. >> >> On Thu, 22 Mar 2018, 13:17 Steve Ebersole, wrote: >>> >>> Like a snapshot? >>> >>> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero >>> wrote: >>>> >>>> On 22 March 2018 at 12:18, Steve Ebersole wrote: >>>> > There is already a branch that contains these changes that they can >>>> > work >>>> > with... no need to wait for a CR. I still want to let Andrea finish >>>> > the >>>> > work on TypeConfiguration and BootstrapContext before we cut CR2. >>>> >>>> It would help to have a tagged release which can be consumed from Maven. >>>> >>>> Could we not tag this as CR2 and whatever else is coming will be another >>>> CRx ? >>>> >>>> I can do this release if that helps. >>>> >>>> Thanks, >>>> Sanne >>>> >>>> > >>>> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero >>>> > wrote: >>>> >> >>>> >> Steve, all, >>>> >> >>>> >> would it be possible to tag a CR2 as soon as the Caching SPI changes >>>> >> are complete? >>>> >> >>>> >> That would help the Infinispan team so they can get started >>>> >> immediately on their side of things. >>>> >> >>>> >> Thanks, >>>> >> Sanne From steve at hibernate.org Thu Mar 22 10:15:50 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 14:15:50 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: Still waiting for feedback on the PR or Jira. I will integrate upstream today if I don't hear replies needing changes But regardless, this is not the only change CR2 is waiting on as I mentioned before On Thu, Mar 22, 2018, 8:54 AM Sanne Grinovero wrote: > Could you help us understand. None of the SPI changes have been merged > in master yet? > > On 22 March 2018 at 13:39, Steve Ebersole wrote: > > Then you'll have to wait. Seems like snapshot is better than waiting > but of > > course your opinion seems just waiting is better... > > > > On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero > wrote: > >> > >> > >> No, snapshots are confusing when you need multiple people to collaborate > >> on a POC. > >> > >> It's not clear if a patch will work the same to others and it's > >> unpractical to match to a specific source commit. > >> > >> Why would we ever publish CRs if SNAPSHOTS are the same. > >> > >> On Thu, 22 Mar 2018, 13:17 Steve Ebersole, wrote: > >>> > >>> Like a snapshot? > >>> > >>> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero > >>> wrote: > >>>> > >>>> On 22 March 2018 at 12:18, Steve Ebersole > wrote: > >>>> > There is already a branch that contains these changes that they can > >>>> > work > >>>> > with... no need to wait for a CR. I still want to let Andrea finish > >>>> > the > >>>> > work on TypeConfiguration and BootstrapContext before we cut CR2. > >>>> > >>>> It would help to have a tagged release which can be consumed from > Maven. > >>>> > >>>> Could we not tag this as CR2 and whatever else is coming will be > another > >>>> CRx ? > >>>> > >>>> I can do this release if that helps. > >>>> > >>>> Thanks, > >>>> Sanne > >>>> > >>>> > > >>>> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero < > sanne at hibernate.org> > >>>> > wrote: > >>>> >> > >>>> >> Steve, all, > >>>> >> > >>>> >> would it be possible to tag a CR2 as soon as the Caching SPI > changes > >>>> >> are complete? > >>>> >> > >>>> >> That would help the Infinispan team so they can get started > >>>> >> immediately on their side of things. > >>>> >> > >>>> >> Thanks, > >>>> >> Sanne > From guillaume.smet at gmail.com Thu Mar 22 10:18:59 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 22 Mar 2018 15:18:59 +0100 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 2:39 PM, Gunnar Morling wrote: > Note I'm not suggesting to change any existing URLs. Rather my question is, > should we go to the date-less schema for new posts going forward. > Personally I like having the date information in the URL but I won't fight for it. The only thing is I want to keep the on disk format as it is i.e. with the dates at the start of the file names. It's really easier to find the posts this way. Apart from that, I don't really care. By the way, this is me not volunteering to do the work :). -- Guillaume From steve at hibernate.org Thu Mar 22 10:22:42 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 14:22:42 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: Yes there were "lots of differences" but a vast majority of them are false-positives, not just those listed in the already massive "false positives" section. I've been going through the non-"false positive" section and "resolving" specific items (via strike-through) with either (1) link to Jira fixing it or (2) comment as to the reason I believe it is a false-positive. I did not bother striking through the "false positives" section. At this point there are very few unresolved items in this list. Those items require more discussion On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero wrote: > Thanks Gail, great job! > I fixed a trivial one, just a thousand to go ;) > > On 16 March 2018 at 23:09, Gail Badner wrote: > > I've moved the document to > > > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > > . > > > > Please let me know if you need an invite to view the document. > > > > The attachments are still at https://developer.jboss.org/wiki/ > > HibernateORMBinaryCompatibilityBetween51And53. > > > > Regards, > > Gail > > > > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner > wrote: > > > >> Hi, > >> > >> There were lots of differences in the compatibility report, so as a > first > >> step, I've excluded packages/classes that I considered SPI, internal, or > >> "grey area". This reduced the the differences to a more manageable > amount. > >> > >> You can see a summary of the incompatibilities along with suggested > >> mitigation at [1]. > >> > >> The report is attached to [1], along with a zip with instructions for > >> running the report. > >> > >> I believe there are some "false positives" in the report, and I have > >> documented them in the section, "False Positives?". > >> > >> Feel free to comment on the article. > >> > >> Thanks, > >> Gail > >> > >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit > >> yBetween51And53 > >> > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From dreborier at gmail.com Thu Mar 22 10:52:25 2018 From: dreborier at gmail.com (andrea boriero) Date: Thu, 22 Mar 2018 14:52:25 +0000 Subject: [hibernate-dev] Hibernate ORM 5.3 CR2 ? In-Reply-To: References: Message-ID: Related with the TypeConfiguration and BootstrapContext work, I have just made a PR targeting your last comments, but I need to know if the work done it's fine and especially if it is enough to be considered done and then integrated. On 22 March 2018 at 14:15, Steve Ebersole wrote: > Still waiting for feedback on the PR or Jira. I will integrate upstream > today if I don't hear replies needing changes > > But regardless, this is not the only change CR2 is waiting on as I > mentioned before > > > On Thu, Mar 22, 2018, 8:54 AM Sanne Grinovero wrote: > > > Could you help us understand. None of the SPI changes have been merged > > in master yet? > > > > On 22 March 2018 at 13:39, Steve Ebersole wrote: > > > Then you'll have to wait. Seems like snapshot is better than waiting > > but of > > > course your opinion seems just waiting is better... > > > > > > On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero > > wrote: > > >> > > >> > > >> No, snapshots are confusing when you need multiple people to > collaborate > > >> on a POC. > > >> > > >> It's not clear if a patch will work the same to others and it's > > >> unpractical to match to a specific source commit. > > >> > > >> Why would we ever publish CRs if SNAPSHOTS are the same. > > >> > > >> On Thu, 22 Mar 2018, 13:17 Steve Ebersole, > wrote: > > >>> > > >>> Like a snapshot? > > >>> > > >>> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero > > >>> wrote: > > >>>> > > >>>> On 22 March 2018 at 12:18, Steve Ebersole > > wrote: > > >>>> > There is already a branch that contains these changes that they > can > > >>>> > work > > >>>> > with... no need to wait for a CR. I still want to let Andrea > finish > > >>>> > the > > >>>> > work on TypeConfiguration and BootstrapContext before we cut CR2. > > >>>> > > >>>> It would help to have a tagged release which can be consumed from > > Maven. > > >>>> > > >>>> Could we not tag this as CR2 and whatever else is coming will be > > another > > >>>> CRx ? > > >>>> > > >>>> I can do this release if that helps. > > >>>> > > >>>> Thanks, > > >>>> Sanne > > >>>> > > >>>> > > > >>>> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero < > > sanne at hibernate.org> > > >>>> > wrote: > > >>>> >> > > >>>> >> Steve, all, > > >>>> >> > > >>>> >> would it be possible to tag a CR2 as soon as the Caching SPI > > changes > > >>>> >> are complete? > > >>>> >> > > >>>> >> That would help the Infinispan team so they can get started > > >>>> >> immediately on their side of things. > > >>>> >> > > >>>> >> Thanks, > > >>>> >> Sanne > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Mar 22 11:20:57 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 15:20:57 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: To make sure all the noise form "false positives" won't get us to miss something, someone knows an alternative tool which can do better? Thanks, Sanne On 22 March 2018 at 14:22, Steve Ebersole wrote: > Yes there were "lots of differences" but a vast majority of them are > false-positives, not just those listed in the already massive "false > positives" section. I've been going through the non-"false positive" > section and "resolving" specific items (via strike-through) with either (1) > link to Jira fixing it or (2) comment as to the reason I believe it is a > false-positive. > > I did not bother striking through the "false positives" section. > > At this point there are very few unresolved items in this list. Those items > require more discussion > > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero wrote: >> >> Thanks Gail, great job! >> I fixed a trivial one, just a thousand to go ;) >> >> On 16 March 2018 at 23:09, Gail Badner wrote: >> > I've moved the document to >> > >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >> > . >> > >> > Please let me know if you need an invite to view the document. >> > >> > The attachments are still at https://developer.jboss.org/wiki/ >> > HibernateORMBinaryCompatibilityBetween51And53. >> > >> > Regards, >> > Gail >> > >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner >> > wrote: >> > >> >> Hi, >> >> >> >> There were lots of differences in the compatibility report, so as a >> >> first >> >> step, I've excluded packages/classes that I considered SPI, internal, >> >> or >> >> "grey area". This reduced the the differences to a more manageable >> >> amount. >> >> >> >> You can see a summary of the incompatibilities along with suggested >> >> mitigation at [1]. >> >> >> >> The report is attached to [1], along with a zip with instructions for >> >> running the report. >> >> >> >> I believe there are some "false positives" in the report, and I have >> >> documented them in the section, "False Positives?". >> >> >> >> Feel free to comment on the article. >> >> >> >> Thanks, >> >> Gail >> >> >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit >> >> yBetween51And53 >> >> >> >> >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Thu Mar 22 11:37:04 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 15:37:04 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: Not sure. animal-sniffer is the other one I know, but not sure it would be better. On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero wrote: > To make sure all the noise form "false positives" won't get us to miss > something, someone knows an alternative tool which can do better? > > Thanks, > Sanne > > > On 22 March 2018 at 14:22, Steve Ebersole wrote: > > Yes there were "lots of differences" but a vast majority of them are > > false-positives, not just those listed in the already massive "false > > positives" section. I've been going through the non-"false positive" > > section and "resolving" specific items (via strike-through) with either > (1) > > link to Jira fixing it or (2) comment as to the reason I believe it is a > > false-positive. > > > > I did not bother striking through the "false positives" section. > > > > At this point there are very few unresolved items in this list. Those > items > > require more discussion > > > > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero > wrote: > >> > >> Thanks Gail, great job! > >> I fixed a trivial one, just a thousand to go ;) > >> > >> On 16 March 2018 at 23:09, Gail Badner wrote: > >> > I've moved the document to > >> > > >> > > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > >> > . > >> > > >> > Please let me know if you need an invite to view the document. > >> > > >> > The attachments are still at https://developer.jboss.org/wiki/ > >> > HibernateORMBinaryCompatibilityBetween51And53. > >> > > >> > Regards, > >> > Gail > >> > > >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner > >> > wrote: > >> > > >> >> Hi, > >> >> > >> >> There were lots of differences in the compatibility report, so as a > >> >> first > >> >> step, I've excluded packages/classes that I considered SPI, internal, > >> >> or > >> >> "grey area". This reduced the the differences to a more manageable > >> >> amount. > >> >> > >> >> You can see a summary of the incompatibilities along with suggested > >> >> mitigation at [1]. > >> >> > >> >> The report is attached to [1], along with a zip with instructions for > >> >> running the report. > >> >> > >> >> I believe there are some "false positives" in the report, and I have > >> >> documented them in the section, "False Positives?". > >> >> > >> >> Feel free to comment on the article. > >> >> > >> >> Thanks, > >> >> Gail > >> >> > >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit > >> >> yBetween51And53 > >> >> > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From emmanuel at hibernate.org Thu Mar 22 11:36:36 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 22 Mar 2018 16:36:36 +0100 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: References: <20180320105047.GI74353@hibernate.org> <36E786C2-285E-47A3-882A-1057AEBC2668@hibernate.org> Message-ID: As we discussed on the phone, I am skeptical of the custom HSearch backend for it: - it would be the only database doing that - it?s a lot of work that would probably be best spent improving the Infinispan remote query FT APIs - once there it will be a maintenance burden. Emmanuel > On 22 Mar 2018, at 10:46, Sanne Grinovero wrote: > > On 22 March 2018 at 07:41, Emmanuel Bernard > wrote: >> >> On 20 Mar 2018, at 12:41, Sanne Grinovero wrote: >> >> >> >> On 20 March 2018 at 10:50, Emmanuel Bernard wrote: >>> >>> I think treating the client side HSearch input and transparently push it >>> down is a recipe for disaster. Looks cool on paper until you have >>> divergence between HSearch proper and Infinispan's or whatever >>> Infinispan exposes. >> >> >> Looks like we agree on the premise, but you didn't comment on the proposal? >> >> >> >> I did, it?s right below :) Granted that?s an option C. > > /The/ proposal in my first email is to have an Hibernate Search 6 > "backend" to support Infinispan Remote. > > I see no comments on that, but it's ok since it looks like we agree on > the problems I had already listed. > > Thanks, > Sanne > >> >> >>> >>> >>> So yes we could have GridDialect specific metadata information around >>> indexing but I would not reuse Hibernate Search annotations for that. >>> Treat Infinispan like any of the other GridDialect providers. >>> >>> As for the way to express FTQ, then Infinispan needs to make Ickle more >>> powerful. >>> >>> Emmanuel >>> >>> >>> On Wed 18-03-14 11:52, Sanne Grinovero wrote: >>>> >>>> Hi all, >>>> >>>> this one is a very desirable feature, yet tricky as there's high >>>> chances of ambiguity and confusion for end users. >>>> >>>> >>>> # Infinispan Remote indexing >>>> >>>> Infinispan embeds the Hibernate Search engine, and uses it to index >>>> data being inserted in any cache having indexing enabled. As you know >>>> Infinispan can be used to store Java POJOs, which get serialized using >>>> JBoss Marshalling - or encoded into Protobuf entries using Infinispan >>>> Protostream as helper layer. >>>> >>>> Hibernate OGM supports both modes, one meant for "Infinispan Embedded" >>>> and one for "Infinispan Remote" as that's what each encoding strategy >>>> is suited for. >>>> >>>> >>>> # Protobuf & indexing >>>> >>>> Protobuf is a well defined format with plenty of documentation which >>>> focuses on a "schema" of the encoding; Hibernate OGM is able to >>>> generate such schemas dynamically and will generate encoders and >>>> decoders which follow the encoding guidelines for Java objects. >>>> >>>> The meta schema of protobuf is not super flexible, yet there's the >>>> option of annotating the Protobuf schema elements using "annotations" >>>> in comments. >>>> Protostream allows inserting Hibernate Search annotations directly in >>>> these comments and will use them to generate the server side indexing >>>> configuration, implicitly also allowing such properties to be queried >>>> using indexed. >>>> >>>> For example you might have this string literally within the comments: >>>> "@Field(store = Store.YES, analyze = Analyze.YES)" >>>> >>>> A full example of schema can be found here [1]. >>>> (The Infinispan documentation is a bit sparse on this as they >>>> encourage people to use another code gen tool, best refer to tests as >>>> examples when working for OGM) >>>> >>>> >>>> # What should OGM users experience? >>>> >>>> A naive solution would be to allow people to use the Hibernate Search >>>> annotations on their JPA entities, and we have OGM copy these into the >>>> generated schema; there's a number of problems with that: >>>> - not all such annotations "translate" equally well [2] >>>> - there's a mismatch between JPA properties and underlying encoding >>>> fields >>>> - if I run a FullTextQuery do I expect it to work remotely? >>>> - what if I want to use Hibernate Search locally as well or instead? >>>> - references to local classes obviously won't work (custom >>>> fieldbridges, analyzers, etc..) >>>> >>>> An alternative is to look at these as "indexes" of the underlying >>>> store, so we'd use them to hint the Infinispan server about user >>>> provided hints such as those generated by `javax.persistence.Index`. >>>> I do think this is the cleaner approach, yet has two drawbacks: >>>> A- I guess ORM might implicitly generate some indexes in its metadata >>>> which the user might not have explicitly asked; e.g. accelerate unique >>>> constraints and foreign keys; it's possible these might not be as >>>> useful as expected in the Infinispan case. >>>> B- we won't be able to leverage the awesome full-text capabilities :-( >>>> >>>> I believe A is something we could ignore for now and revisit if >>>> there's actual demand. >>>> >>>> B is also not urgent, yet disappointing limitation as this capability >>>> is a distinguishing feature of this NoSQL. Would we agree that >>>> exposing such full-text capabilities would best be let to an ad-hoc >>>> backend in Hibernate Search 6? >>>> >>>> >>>> Thanks, >>>> Sanne >>>> >>>> 1 - >>>> http://blog.infinispan.org/2018/02/restful-queries-coming-to-infinispan-92.html >>>> 2 - >>>> https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/impl/indexing/IndexingMetadataCreator.java#L31 >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Thu Mar 22 11:39:53 2018 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Thu, 22 Mar 2018 16:39:53 +0100 Subject: [hibernate-dev] Why do we have the date in the URL of blog posts? In-Reply-To: References: Message-ID: <5DC3B97A-81B3-481B-B698-ABF46FD3410E@hibernate.org> I don?t think spending the n hours on outweighs the explained benefits so I would keep it that way. The reason I had the dates were because blogs are time sensitive (like any content really), and it avoids or reduces the risk of slug collision for which we would need to implement a workaround for. > On 22 Mar 2018, at 15:18, Guillaume Smet wrote: > > On Thu, Mar 22, 2018 at 2:39 PM, Gunnar Morling > wrote: > >> Note I'm not suggesting to change any existing URLs. Rather my question is, >> should we go to the date-less schema for new posts going forward. >> > > Personally I like having the date information in the URL but I won't fight > for it. > > The only thing is I want to keep the on disk format as it is i.e. with the > dates at the start of the file names. It's really easier to find the posts > this way. > > Apart from that, I don't really care. > > By the way, this is me not volunteering to do the work :). > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From david.lloyd at redhat.com Thu Mar 22 11:55:16 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 22 Mar 2018 10:55:16 -0500 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: This tool is usually pretty good; in fact I think it likely that it's the best of its kind. The false positives are really a fairly recent development AFAIK; I don't recall hitting any when I ran it for our EJB changes a year or two ago. It might be a good idea to contribute a fix for the problem upstream; it might even be relatively easy to do. Or it could already be fixed. On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole wrote: > Not sure. animal-sniffer is the other one I know, but not sure it would be > better. > > On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero > wrote: >> >> To make sure all the noise form "false positives" won't get us to miss >> something, someone knows an alternative tool which can do better? >> >> Thanks, >> Sanne >> >> >> On 22 March 2018 at 14:22, Steve Ebersole wrote: >> > Yes there were "lots of differences" but a vast majority of them are >> > false-positives, not just those listed in the already massive "false >> > positives" section. I've been going through the non-"false positive" >> > section and "resolving" specific items (via strike-through) with either >> > (1) >> > link to Jira fixing it or (2) comment as to the reason I believe it is a >> > false-positive. >> > >> > I did not bother striking through the "false positives" section. >> > >> > At this point there are very few unresolved items in this list. Those >> > items >> > require more discussion >> > >> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero >> > wrote: >> >> >> >> Thanks Gail, great job! >> >> I fixed a trivial one, just a thousand to go ;) >> >> >> >> On 16 March 2018 at 23:09, Gail Badner wrote: >> >> > I've moved the document to >> >> > >> >> > >> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >> >> > . >> >> > >> >> > Please let me know if you need an invite to view the document. >> >> > >> >> > The attachments are still at https://developer.jboss.org/wiki/ >> >> > HibernateORMBinaryCompatibilityBetween51And53. >> >> > >> >> > Regards, >> >> > Gail >> >> > >> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> >> >> >> There were lots of differences in the compatibility report, so as a >> >> >> first >> >> >> step, I've excluded packages/classes that I considered SPI, >> >> >> internal, >> >> >> or >> >> >> "grey area". This reduced the the differences to a more manageable >> >> >> amount. >> >> >> >> >> >> You can see a summary of the incompatibilities along with suggested >> >> >> mitigation at [1]. >> >> >> >> >> >> The report is attached to [1], along with a zip with instructions >> >> >> for >> >> >> running the report. >> >> >> >> >> >> I believe there are some "false positives" in the report, and I have >> >> >> documented them in the section, "False Positives?". >> >> >> >> >> >> Feel free to comment on the article. >> >> >> >> >> >> Thanks, >> >> >> Gail >> >> >> >> >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit >> >> >> yBetween51And53 >> >> >> >> >> >> >> >> > _______________________________________________ >> >> > hibernate-dev mailing list >> >> > hibernate-dev at lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> >> hibernate-dev mailing list >> >> hibernate-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev -- - DML From sanne at hibernate.org Thu Mar 22 11:58:21 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 15:58:21 +0000 Subject: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote In-Reply-To: References: <20180320105047.GI74353@hibernate.org> <36E786C2-285E-47A3-882A-1057AEBC2668@hibernate.org> Message-ID: On 22 March 2018 at 15:36, Emmanuel Bernard wrote: > As we discussed on the phone, I am skeptical of the custom HSearch backend > for it: > - it would be the only database doing that > - it?s a lot of work that would probably be best spent improving the > Infinispan remote query FT APIs > - once there it will be a maintenance burden. Thanks for clarifying. Then we won't create that in Search 6, at least not until we have a better proposal. The take away from this thread is that we don't want to map Hibernate Search annotations from the domain model directly on the protobuf. We can explore other ways to expose Infinispan's capabilities which are less confusing. Sanne > > Emmanuel > > On 22 Mar 2018, at 10:46, Sanne Grinovero wrote: > > On 22 March 2018 at 07:41, Emmanuel Bernard wrote: > > > On 20 Mar 2018, at 12:41, Sanne Grinovero wrote: > > > > On 20 March 2018 at 10:50, Emmanuel Bernard wrote: > > > I think treating the client side HSearch input and transparently push it > down is a recipe for disaster. Looks cool on paper until you have > divergence between HSearch proper and Infinispan's or whatever > Infinispan exposes. > > > > Looks like we agree on the premise, but you didn't comment on the proposal? > > > > I did, it?s right below :) Granted that?s an option C. > > > /The/ proposal in my first email is to have an Hibernate Search 6 > "backend" to support Infinispan Remote. > > I see no comments on that, but it's ok since it looks like we agree on > the problems I had already listed. > > Thanks, > Sanne > > > > > > So yes we could have GridDialect specific metadata information around > indexing but I would not reuse Hibernate Search annotations for that. > Treat Infinispan like any of the other GridDialect providers. > > As for the way to express FTQ, then Infinispan needs to make Ickle more > powerful. > > Emmanuel > > > On Wed 18-03-14 11:52, Sanne Grinovero wrote: > > > Hi all, > > this one is a very desirable feature, yet tricky as there's high > chances of ambiguity and confusion for end users. > > > # Infinispan Remote indexing > > Infinispan embeds the Hibernate Search engine, and uses it to index > data being inserted in any cache having indexing enabled. As you know > Infinispan can be used to store Java POJOs, which get serialized using > JBoss Marshalling - or encoded into Protobuf entries using Infinispan > Protostream as helper layer. > > Hibernate OGM supports both modes, one meant for "Infinispan Embedded" > and one for "Infinispan Remote" as that's what each encoding strategy > is suited for. > > > # Protobuf & indexing > > Protobuf is a well defined format with plenty of documentation which > focuses on a "schema" of the encoding; Hibernate OGM is able to > generate such schemas dynamically and will generate encoders and > decoders which follow the encoding guidelines for Java objects. > > The meta schema of protobuf is not super flexible, yet there's the > option of annotating the Protobuf schema elements using "annotations" > in comments. > Protostream allows inserting Hibernate Search annotations directly in > these comments and will use them to generate the server side indexing > configuration, implicitly also allowing such properties to be queried > using indexed. > > For example you might have this string literally within the comments: > "@Field(store = Store.YES, analyze = Analyze.YES)" > > A full example of schema can be found here [1]. > (The Infinispan documentation is a bit sparse on this as they > encourage people to use another code gen tool, best refer to tests as > examples when working for OGM) > > > # What should OGM users experience? > > A naive solution would be to allow people to use the Hibernate Search > annotations on their JPA entities, and we have OGM copy these into the > generated schema; there's a number of problems with that: > - not all such annotations "translate" equally well [2] > - there's a mismatch between JPA properties and underlying encoding > fields > - if I run a FullTextQuery do I expect it to work remotely? > - what if I want to use Hibernate Search locally as well or instead? > - references to local classes obviously won't work (custom > fieldbridges, analyzers, etc..) > > An alternative is to look at these as "indexes" of the underlying > store, so we'd use them to hint the Infinispan server about user > provided hints such as those generated by `javax.persistence.Index`. > I do think this is the cleaner approach, yet has two drawbacks: > A- I guess ORM might implicitly generate some indexes in its metadata > which the user might not have explicitly asked; e.g. accelerate unique > constraints and foreign keys; it's possible these might not be as > useful as expected in the Infinispan case. > B- we won't be able to leverage the awesome full-text capabilities :-( > > I believe A is something we could ignore for now and revisit if > there's actual demand. > > B is also not urgent, yet disappointing limitation as this capability > is a distinguishing feature of this NoSQL. Would we agree that > exposing such full-text capabilities would best be let to an ad-hoc > backend in Hibernate Search 6? > > > Thanks, > Sanne > > 1 - > http://blog.infinispan.org/2018/02/restful-queries-coming-to-infinispan-92.html > 2 - > https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-server/src/main/java/org/infinispan/query/remote/impl/indexing/IndexingMetadataCreator.java#L31 > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From sanne at hibernate.org Thu Mar 22 11:59:44 2018 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 22 Mar 2018 15:59:44 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: On 22 March 2018 at 15:55, David Lloyd wrote: > This tool is usually pretty good; in fact I think it likely that it's > the best of its kind. The false positives are really a fairly recent > development AFAIK; I don't recall hitting any when I ran it for our > EJB changes a year or two ago. It might be a good idea to contribute > a fix for the problem upstream; it might even be relatively easy to > do. Or it could already be fixed. Good to know, thanks. I might explore that next week. Sanne > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole wrote: >> Not sure. animal-sniffer is the other one I know, but not sure it would be >> better. >> >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero >> wrote: >>> >>> To make sure all the noise form "false positives" won't get us to miss >>> something, someone knows an alternative tool which can do better? >>> >>> Thanks, >>> Sanne >>> >>> >>> On 22 March 2018 at 14:22, Steve Ebersole wrote: >>> > Yes there were "lots of differences" but a vast majority of them are >>> > false-positives, not just those listed in the already massive "false >>> > positives" section. I've been going through the non-"false positive" >>> > section and "resolving" specific items (via strike-through) with either >>> > (1) >>> > link to Jira fixing it or (2) comment as to the reason I believe it is a >>> > false-positive. >>> > >>> > I did not bother striking through the "false positives" section. >>> > >>> > At this point there are very few unresolved items in this list. Those >>> > items >>> > require more discussion >>> > >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero >>> > wrote: >>> >> >>> >> Thanks Gail, great job! >>> >> I fixed a trivial one, just a thousand to go ;) >>> >> >>> >> On 16 March 2018 at 23:09, Gail Badner wrote: >>> >> > I've moved the document to >>> >> > >>> >> > >>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw >>> >> > . >>> >> > >>> >> > Please let me know if you need an invite to view the document. >>> >> > >>> >> > The attachments are still at https://developer.jboss.org/wiki/ >>> >> > HibernateORMBinaryCompatibilityBetween51And53. >>> >> > >>> >> > Regards, >>> >> > Gail >>> >> > >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner >>> >> > wrote: >>> >> > >>> >> >> Hi, >>> >> >> >>> >> >> There were lots of differences in the compatibility report, so as a >>> >> >> first >>> >> >> step, I've excluded packages/classes that I considered SPI, >>> >> >> internal, >>> >> >> or >>> >> >> "grey area". This reduced the the differences to a more manageable >>> >> >> amount. >>> >> >> >>> >> >> You can see a summary of the incompatibilities along with suggested >>> >> >> mitigation at [1]. >>> >> >> >>> >> >> The report is attached to [1], along with a zip with instructions >>> >> >> for >>> >> >> running the report. >>> >> >> >>> >> >> I believe there are some "false positives" in the report, and I have >>> >> >> documented them in the section, "False Positives?". >>> >> >> >>> >> >> Feel free to comment on the article. >>> >> >> >>> >> >> Thanks, >>> >> >> Gail >>> >> >> >>> >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit >>> >> >> yBetween51And53 >>> >> >> >>> >> >> >>> >> > _______________________________________________ >>> >> > hibernate-dev mailing list >>> >> > hibernate-dev at lists.jboss.org >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> _______________________________________________ >>> >> hibernate-dev mailing list >>> >> hibernate-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > -- > - DML From steve at hibernate.org Thu Mar 22 13:37:45 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 17:37:45 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: I just pushed the first round of fixes for this upstream. On Thu, Mar 22, 2018 at 11:00 AM Sanne Grinovero wrote: > On 22 March 2018 at 15:55, David Lloyd wrote: > > This tool is usually pretty good; in fact I think it likely that it's > > the best of its kind. The false positives are really a fairly recent > > development AFAIK; I don't recall hitting any when I ran it for our > > EJB changes a year or two ago. It might be a good idea to contribute > > a fix for the problem upstream; it might even be relatively easy to > > do. Or it could already be fixed. > > Good to know, thanks. I might explore that next week. > > Sanne > > > > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole > wrote: > >> Not sure. animal-sniffer is the other one I know, but not sure it > would be > >> better. > >> > >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero > >> wrote: > >>> > >>> To make sure all the noise form "false positives" won't get us to miss > >>> something, someone knows an alternative tool which can do better? > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> On 22 March 2018 at 14:22, Steve Ebersole wrote: > >>> > Yes there were "lots of differences" but a vast majority of them are > >>> > false-positives, not just those listed in the already massive "false > >>> > positives" section. I've been going through the non-"false positive" > >>> > section and "resolving" specific items (via strike-through) with > either > >>> > (1) > >>> > link to Jira fixing it or (2) comment as to the reason I believe it > is a > >>> > false-positive. > >>> > > >>> > I did not bother striking through the "false positives" section. > >>> > > >>> > At this point there are very few unresolved items in this list. > Those > >>> > items > >>> > require more discussion > >>> > > >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero > > >>> > wrote: > >>> >> > >>> >> Thanks Gail, great job! > >>> >> I fixed a trivial one, just a thousand to go ;) > >>> >> > >>> >> On 16 March 2018 at 23:09, Gail Badner wrote: > >>> >> > I've moved the document to > >>> >> > > >>> >> > > >>> >> > > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw > >>> >> > . > >>> >> > > >>> >> > Please let me know if you need an invite to view the document. > >>> >> > > >>> >> > The attachments are still at https://developer.jboss.org/wiki/ > >>> >> > HibernateORMBinaryCompatibilityBetween51And53. > >>> >> > > >>> >> > Regards, > >>> >> > Gail > >>> >> > > >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner > > >>> >> > wrote: > >>> >> > > >>> >> >> Hi, > >>> >> >> > >>> >> >> There were lots of differences in the compatibility report, so > as a > >>> >> >> first > >>> >> >> step, I've excluded packages/classes that I considered SPI, > >>> >> >> internal, > >>> >> >> or > >>> >> >> "grey area". This reduced the the differences to a more > manageable > >>> >> >> amount. > >>> >> >> > >>> >> >> You can see a summary of the incompatibilities along with > suggested > >>> >> >> mitigation at [1]. > >>> >> >> > >>> >> >> The report is attached to [1], along with a zip with instructions > >>> >> >> for > >>> >> >> running the report. > >>> >> >> > >>> >> >> I believe there are some "false positives" in the report, and I > have > >>> >> >> documented them in the section, "False Positives?". > >>> >> >> > >>> >> >> Feel free to comment on the article. > >>> >> >> > >>> >> >> Thanks, > >>> >> >> Gail > >>> >> >> > >>> >> >> [1] > https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit > >>> >> >> yBetween51And53 > >>> >> >> > >>> >> >> > >>> >> > _______________________________________________ > >>> >> > hibernate-dev mailing list > >>> >> > hibernate-dev at lists.jboss.org > >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> >> _______________________________________________ > >>> >> hibernate-dev mailing list > >>> >> hibernate-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > -- > > - DML > From guillaume.smet at gmail.com Thu Mar 22 13:46:48 2018 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 22 Mar 2018 18:46:48 +0100 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: On Thu, Mar 22, 2018 at 4:20 PM, Sanne Grinovero wrote: > To make sure all the noise form "false positives" won't get us to miss > something, someone knows an alternative tool which can do better? > We use this one for HV https://github.com/siom79/japicmp . Not sure it's better though. If not, I'd say the best way to rule out the false positives would be to open issues on the projects and get the fixes integrated there. Of course, it will require some additional effort from us. -- Guillaume From gunnar at hibernate.org Thu Mar 22 13:55:26 2018 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 22 Mar 2018 18:55:26 +0100 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: I've mostly used Japicmp recently http://siom79.github.io/japicmp/). Works pretty well, but it lacks a way to distinguish between API and SPI, so you'll likely also see "false positives". In fact I thought it's the one you'd be using, but it doesn't seem so from looking at the report attached to that wiki page. 2018-03-22 16:59 GMT+01:00 Sanne Grinovero : > On 22 March 2018 at 15:55, David Lloyd wrote: > > This tool is usually pretty good; in fact I think it likely that it's > > the best of its kind. The false positives are really a fairly recent > > development AFAIK; I don't recall hitting any when I ran it for our > > EJB changes a year or two ago. It might be a good idea to contribute > > a fix for the problem upstream; it might even be relatively easy to > > do. Or it could already be fixed. > > Good to know, thanks. I might explore that next week. > > Sanne > > > > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole > wrote: > >> Not sure. animal-sniffer is the other one I know, but not sure it > would be > >> better. > >> > >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero > >> wrote: > >>> > >>> To make sure all the noise form "false positives" won't get us to miss > >>> something, someone knows an alternative tool which can do better? > >>> > >>> Thanks, > >>> Sanne > >>> > >>> > >>> On 22 March 2018 at 14:22, Steve Ebersole wrote: > >>> > Yes there were "lots of differences" but a vast majority of them are > >>> > false-positives, not just those listed in the already massive "false > >>> > positives" section. I've been going through the non-"false positive" > >>> > section and "resolving" specific items (via strike-through) with > either > >>> > (1) > >>> > link to Jira fixing it or (2) comment as to the reason I believe it > is a > >>> > false-positive. > >>> > > >>> > I did not bother striking through the "false positives" section. > >>> > > >>> > At this point there are very few unresolved items in this list. > Those > >>> > items > >>> > require more discussion > >>> > > >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero > > >>> > wrote: > >>> >> > >>> >> Thanks Gail, great job! > >>> >> I fixed a trivial one, just a thousand to go ;) > >>> >> > >>> >> On 16 March 2018 at 23:09, Gail Badner wrote: > >>> >> > I've moved the document to > >>> >> > > >>> >> > > >>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC- > 110zcjRaXLllBsvRKw-pdHrMzRzw > >>> >> > . > >>> >> > > >>> >> > Please let me know if you need an invite to view the document. > >>> >> > > >>> >> > The attachments are still at https://developer.jboss.org/wiki/ > >>> >> > HibernateORMBinaryCompatibilityBetween51And53. > >>> >> > > >>> >> > Regards, > >>> >> > Gail > >>> >> > > >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner > > >>> >> > wrote: > >>> >> > > >>> >> >> Hi, > >>> >> >> > >>> >> >> There were lots of differences in the compatibility report, so > as a > >>> >> >> first > >>> >> >> step, I've excluded packages/classes that I considered SPI, > >>> >> >> internal, > >>> >> >> or > >>> >> >> "grey area". This reduced the the differences to a more > manageable > >>> >> >> amount. > >>> >> >> > >>> >> >> You can see a summary of the incompatibilities along with > suggested > >>> >> >> mitigation at [1]. > >>> >> >> > >>> >> >> The report is attached to [1], along with a zip with instructions > >>> >> >> for > >>> >> >> running the report. > >>> >> >> > >>> >> >> I believe there are some "false positives" in the report, and I > have > >>> >> >> documented them in the section, "False Positives?". > >>> >> >> > >>> >> >> Feel free to comment on the article. > >>> >> >> > >>> >> >> Thanks, > >>> >> >> Gail > >>> >> >> > >>> >> >> [1] https://developer.jboss.org/wiki/ > HibernateORMBinaryCompatibilit > >>> >> >> yBetween51And53 > >>> >> >> > >>> >> >> > >>> >> > _______________________________________________ > >>> >> > hibernate-dev mailing list > >>> >> > hibernate-dev at lists.jboss.org > >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> >> _______________________________________________ > >>> >> hibernate-dev mailing list > >>> >> hibernate-dev at lists.jboss.org > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > -- > > - DML > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gbadner at redhat.com Thu Mar 22 16:17:10 2018 From: gbadner at redhat.com (Gail Badner) Date: Thu, 22 Mar 2018 13:17:10 -0700 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: I'm happy to see all the progress on this while I've been occupied with 5.1.13 and some other urgent issues. I hope to have time to get caught up on things later today or tomorrow. On Thu, Mar 22, 2018 at 10:55 AM, Gunnar Morling wrote: > I've mostly used Japicmp recently http://siom79.github.io/japicmp/). Works > pretty well, but it lacks a way to distinguish between API and SPI, so > you'll likely also see "false positives". In fact I thought it's the one > you'd be using, but it doesn't seem so from looking at the report attached > to that wiki page. > > 2018-03-22 16:59 GMT+01:00 Sanne Grinovero : > > > On 22 March 2018 at 15:55, David Lloyd wrote: > > > This tool is usually pretty good; in fact I think it likely that it's > > > the best of its kind. The false positives are really a fairly recent > > > development AFAIK; I don't recall hitting any when I ran it for our > > > EJB changes a year or two ago. It might be a good idea to contribute > > > a fix for the problem upstream; it might even be relatively easy to > > > do. Or it could already be fixed. > > > > Good to know, thanks. I might explore that next week. > > > > Sanne > > > > > > > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole > > wrote: > > >> Not sure. animal-sniffer is the other one I know, but not sure it > > would be > > >> better. > > >> > > >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero > > > >> wrote: > > >>> > > >>> To make sure all the noise form "false positives" won't get us to > miss > > >>> something, someone knows an alternative tool which can do better? > > >>> > > >>> Thanks, > > >>> Sanne > > >>> > > >>> > > >>> On 22 March 2018 at 14:22, Steve Ebersole > wrote: > > >>> > Yes there were "lots of differences" but a vast majority of them > are > > >>> > false-positives, not just those listed in the already massive > "false > > >>> > positives" section. I've been going through the non-"false > positive" > > >>> > section and "resolving" specific items (via strike-through) with > > either > > >>> > (1) > > >>> > link to Jira fixing it or (2) comment as to the reason I believe it > > is a > > >>> > false-positive. > > >>> > > > >>> > I did not bother striking through the "false positives" section. > > >>> > > > >>> > At this point there are very few unresolved items in this list. > > Those > > >>> > items > > >>> > require more discussion > > >>> > > > >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero < > sanne at hibernate.org > > > > > >>> > wrote: > > >>> >> > > >>> >> Thanks Gail, great job! > > >>> >> I fixed a trivial one, just a thousand to go ;) > > >>> >> > > >>> >> On 16 March 2018 at 23:09, Gail Badner > wrote: > > >>> >> > I've moved the document to > > >>> >> > > > >>> >> > > > >>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC- > > 110zcjRaXLllBsvRKw-pdHrMzRzw > > >>> >> > . > > >>> >> > > > >>> >> > Please let me know if you need an invite to view the document. > > >>> >> > > > >>> >> > The attachments are still at https://developer.jboss.org/wiki/ > > >>> >> > HibernateORMBinaryCompatibilityBetween51And53. > > >>> >> > > > >>> >> > Regards, > > >>> >> > Gail > > >>> >> > > > >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner < > gbadner at redhat.com > > > > > >>> >> > wrote: > > >>> >> > > > >>> >> >> Hi, > > >>> >> >> > > >>> >> >> There were lots of differences in the compatibility report, so > > as a > > >>> >> >> first > > >>> >> >> step, I've excluded packages/classes that I considered SPI, > > >>> >> >> internal, > > >>> >> >> or > > >>> >> >> "grey area". This reduced the the differences to a more > > manageable > > >>> >> >> amount. > > >>> >> >> > > >>> >> >> You can see a summary of the incompatibilities along with > > suggested > > >>> >> >> mitigation at [1]. > > >>> >> >> > > >>> >> >> The report is attached to [1], along with a zip with > instructions > > >>> >> >> for > > >>> >> >> running the report. > > >>> >> >> > > >>> >> >> I believe there are some "false positives" in the report, and I > > have > > >>> >> >> documented them in the section, "False Positives?". > > >>> >> >> > > >>> >> >> Feel free to comment on the article. > > >>> >> >> > > >>> >> >> Thanks, > > >>> >> >> Gail > > >>> >> >> > > >>> >> >> [1] https://developer.jboss.org/wiki/ > > HibernateORMBinaryCompatibilit > > >>> >> >> yBetween51And53 > > >>> >> >> > > >>> >> >> > > >>> >> > _______________________________________________ > > >>> >> > hibernate-dev mailing list > > >>> >> > hibernate-dev at lists.jboss.org > > >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >>> >> _______________________________________________ > > >>> >> hibernate-dev mailing list > > >>> >> hibernate-dev at lists.jboss.org > > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > > > > -- > > > - DML > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Mar 22 19:57:40 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 22 Mar 2018 23:57:40 +0000 Subject: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3 In-Reply-To: References: Message-ID: Definitely. Thanks for doing this On Thu, Mar 22, 2018, 3:25 PM Gail Badner wrote: > I'm happy to see all the progress on this while I've been occupied with > 5.1.13 and some other urgent issues. > > I hope to have time to get caught up on things later today or tomorrow. > > On Thu, Mar 22, 2018 at 10:55 AM, Gunnar Morling > wrote: > > > I've mostly used Japicmp recently http://siom79.github.io/japicmp/). > Works > > pretty well, but it lacks a way to distinguish between API and SPI, so > > you'll likely also see "false positives". In fact I thought it's the one > > you'd be using, but it doesn't seem so from looking at the report > attached > > to that wiki page. > > > > 2018-03-22 16:59 GMT+01:00 Sanne Grinovero : > > > > > On 22 March 2018 at 15:55, David Lloyd wrote: > > > > This tool is usually pretty good; in fact I think it likely that it's > > > > the best of its kind. The false positives are really a fairly recent > > > > development AFAIK; I don't recall hitting any when I ran it for our > > > > EJB changes a year or two ago. It might be a good idea to contribute > > > > a fix for the problem upstream; it might even be relatively easy to > > > > do. Or it could already be fixed. > > > > > > Good to know, thanks. I might explore that next week. > > > > > > Sanne > > > > > > > > > > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole < > steve at hibernate.org> > > > wrote: > > > >> Not sure. animal-sniffer is the other one I know, but not sure it > > > would be > > > >> better. > > > >> > > > >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero < > sanne at hibernate.org > > > > > > >> wrote: > > > >>> > > > >>> To make sure all the noise form "false positives" won't get us to > > miss > > > >>> something, someone knows an alternative tool which can do better? > > > >>> > > > >>> Thanks, > > > >>> Sanne > > > >>> > > > >>> > > > >>> On 22 March 2018 at 14:22, Steve Ebersole > > wrote: > > > >>> > Yes there were "lots of differences" but a vast majority of them > > are > > > >>> > false-positives, not just those listed in the already massive > > "false > > > >>> > positives" section. I've been going through the non-"false > > positive" > > > >>> > section and "resolving" specific items (via strike-through) with > > > either > > > >>> > (1) > > > >>> > link to Jira fixing it or (2) comment as to the reason I believe > it > > > is a > > > >>> > false-positive. > > > >>> > > > > >>> > I did not bother striking through the "false positives" section. > > > >>> > > > > >>> > At this point there are very few unresolved items in this list. > > > Those > > > >>> > items > > > >>> > require more discussion > > > >>> > > > > >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero < > > sanne at hibernate.org > > > > > > > >>> > wrote: > > > >>> >> > > > >>> >> Thanks Gail, great job! > > > >>> >> I fixed a trivial one, just a thousand to go ;) > > > >>> >> > > > >>> >> On 16 March 2018 at 23:09, Gail Badner > > wrote: > > > >>> >> > I've moved the document to > > > >>> >> > > > > >>> >> > > > > >>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC- > > > 110zcjRaXLllBsvRKw-pdHrMzRzw > > > >>> >> > . > > > >>> >> > > > > >>> >> > Please let me know if you need an invite to view the document. > > > >>> >> > > > > >>> >> > The attachments are still at > https://developer.jboss.org/wiki/ > > > >>> >> > HibernateORMBinaryCompatibilityBetween51And53. > > > >>> >> > > > > >>> >> > Regards, > > > >>> >> > Gail > > > >>> >> > > > > >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner < > > gbadner at redhat.com > > > > > > > >>> >> > wrote: > > > >>> >> > > > > >>> >> >> Hi, > > > >>> >> >> > > > >>> >> >> There were lots of differences in the compatibility report, > so > > > as a > > > >>> >> >> first > > > >>> >> >> step, I've excluded packages/classes that I considered SPI, > > > >>> >> >> internal, > > > >>> >> >> or > > > >>> >> >> "grey area". This reduced the the differences to a more > > > manageable > > > >>> >> >> amount. > > > >>> >> >> > > > >>> >> >> You can see a summary of the incompatibilities along with > > > suggested > > > >>> >> >> mitigation at [1]. > > > >>> >> >> > > > >>> >> >> The report is attached to [1], along with a zip with > > instructions > > > >>> >> >> for > > > >>> >> >> running the report. > > > >>> >> >> > > > >>> >> >> I believe there are some "false positives" in the report, > and I > > > have > > > >>> >> >> documented them in the section, "False Positives?". > > > >>> >> >> > > > >>> >> >> Feel free to comment on the article. > > > >>> >> >> > > > >>> >> >> Thanks, > > > >>> >> >> Gail > > > >>> >> >> > > > >>> >> >> [1] https://developer.jboss.org/wiki/ > > > HibernateORMBinaryCompatibilit > > > >>> >> >> yBetween51And53 > > > >>> >> >> > > > >>> >> >> > > > >>> >> > _______________________________________________ > > > >>> >> > hibernate-dev mailing list > > > >>> >> > hibernate-dev at lists.jboss.org > > > >>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > >>> >> _______________________________________________ > > > >>> >> hibernate-dev mailing list > > > >>> >> hibernate-dev at lists.jboss.org > > > >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > > > > > > > > -- > > > > - DML > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From guillaume.smet at hibernate.org Tue Mar 27 09:56:53 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 27 Mar 2018 15:56:53 +0200 Subject: [hibernate-dev] Minutes of the NoORM IRC meeting Message-ID: Hi, Here are the minutes of our biweekly NoORM IRC meeting: 15:52 < jbott> Meeting ended Tue Mar 27 13:51:48 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 15:52 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-03-27-13.01.html 15:52 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-03-27-13.01.txt 15:52 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2018/hibernate-dev.2018-03-27-13.01.log.html Cheers, -- Guillaume From guillaume.smet at hibernate.org Tue Mar 27 10:45:32 2018 From: guillaume.smet at hibernate.org (Guillaume Smet) Date: Tue, 27 Mar 2018 16:45:32 +0200 Subject: [hibernate-dev] Hibernate Validator 6.0.9.Final released Message-ID: Hi, Today, we released the 6.0.9.Final version of Hibernate Validator. It comes with some nice performance improvements, some changes to the new constraint validator payload feature and a couple bugfixes. Time to upgrade! More info here: http://in.relation.to/2018/03/27/hibernate-validator-609-final-out/ Have a nice day. -- Guillaume From rvansa at redhat.com Thu Mar 29 04:03:09 2018 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 29 Mar 2018 10:03:09 +0200 Subject: [hibernate-dev] Why hibernate-jcache is not enough (for Infinispan) Message-ID: <39e8c62e-12f2-5a0c-de06-3a907eace91f@redhat.com> Hi Steve, on HipChat you've asked why hibernate-jcache + Infinispan's implementation of JCache is not enough. It ultimately boils down to 1. performance 2. correctness where (2) can be fine with some providers but then (1) suffers. Infinispan offers transactional mode, but it's not serializable (gosh, sometimes it's even read_uncommitted) and has its quirks. The performance can't be as good as with non-tx mode, too. That's why the native transactional caches support will be dropped in 5.3 and we'll just emit a warning to update their configuration (and continue with non-tx config). As a demonstration of this we can use the putFromLoad. If you implement this as a (ideal serializable) transactional cache putIfAbsent, the provider must either a) lock the key (pessimistic approach) - but we don't want to block other nodes removing data from the cache (on write) or putFromLoading (on read!) b) resolve conflicts when the transaction is committing: you figure out that there are two concurrent updates and rollback one of the transactions - that's not acceptable to us either, as any failure in cache should not affect DB transaction. And there's a risk of blocking between the 2 phases of commit, too. Theoretically you could just wipe any modified data on conflict - I don't know if anyone does that, 'drop everything and proceed with commit' is not something I'd expect from a general-purpose (NoSQL) DB. I recall Alex's JCache implementation (for 5.2) storing some 'lock' objects in the cache, and you probably don't want to wipe those. Interaction with evictAll/removeAll could be also problematic: not sure about the other providers but Infinispan's clear() operation is non-transactional even on tx cache (since Infinispan 7 or so) because it's impractical to resolve all conflicts. I don't know details how others provide that operation but there may be a hidden problem. Last but not least, you assume that the provider is transactional and it provides JCache interface. JCache does not define interaction with JTA, because it was hard to get agreement on non-tx behaviour (why did it take 13 years to complete the JSR?) and it would be even harder for JTA. So what you expect is just your extrapolation or wishful thinking, and it's up to integrators to verify that the unwritten contract is fulfilled within the scope of hibernate-jcache module use. Not that SPI implementors would be in a better position, but at least we are aware that (for us) it's not enough to implement those 3 classes and job's done. Of course the correctness aspect may be ignored with 'it's just a cache' implying 'users expect stale/uncommitted data' as Sanne (who is much closer to the customers than me) keeps repeating. However this is not what 2LC promises as I understand it: the same results as DB would do. I am really grateful that in 5.3 you've provided the CacheTransactionSynchronization that will help us boost (1) even further by allowing us to execute all operations in parallel. And it's good that you've made the SPI more expressive with the intent; there'll be a bunch of TODOs in the 5.3 implementation to cover use cases that were not handled in previous versions but now are obvious. Cheers Radim -- Radim Vansa JBoss Performance Team From steve at hibernate.org Thu Mar 29 08:11:45 2018 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 29 Mar 2018 12:11:45 +0000 Subject: [hibernate-dev] Why hibernate-jcache is not enough (for Infinispan) In-Reply-To: <39e8c62e-12f2-5a0c-de06-3a907eace91f@redhat.com> References: <39e8c62e-12f2-5a0c-de06-3a907eace91f@redhat.com> Message-ID: Thanks for the thoughts Radim. But I think that there is a misunderstanding.. Today (pre-5.3) Hibernate has a hibernate-infinispan module that integrates Infinispan into Hibernate ORM as a second-level cache. In fact it provides 2 integrations: `InfinispanRegionFactory` and `JndiInfinispanRegionFactory`. And then inside WildFly there is (at least) a third one specific to running inside WildFly. Inside WildFly is irrelevant... I say that because inside WildFly we are going to use whatever the Infinispan team develops as infinispan-hibernate-cache. Which leaves the other 2. The only thing (I believe) that `InfinispanRegionFactory` and `JndiInfinispanRegionFactory` provide over (and actually in any way different from) hibernate-jcache is transactional access support, which you even say is going away. I understand about not being able to fully leverage `CacheTransactionSynchronization` if hibernate-jcache is used. IMO it is the single drawback to using hibernate-jcache for Infinispan. All of the other things you mentioned are IMO implementation details. Well that and missing out on the new `DomainDataRegionConfig` stuff. And keep in mind that even hibernate-jcache offers some integration points (thanks to Alex)... you can supply your own `javax.cache.spi.CachingProvider` or `javax.cache.CacheManager` directly to the RegionFactory for JCache. So you have total control still over how caches are built (sans access to `DomainDataRegionConfig`). So all-in-all I am still not understanding why `hibernate-jcache` + `infinispan` is not enough for most cases. Yes you miss out on some possible performance improvements (leveraging `CacheTransactionSynchronization` and `DomainDataRegionConfig` being the 2 I can think of). However, that's why there is the possibility of a custom cache provider - to leverage those things. But again, taking a step back and looking at the big picture... 1) We need to be able to run outside of WildFly. The 2 legacy `hibernate-infinispan` providers were intended for that. 2) We need to be able to run inside of WildFly. The provider supplied with WildFly (Jipijapa) itself was intended for that. So how do we do that moving to 5.3? As I mentioned above, I think we can ignore "run inside of WildFly" for this discussion - that will happen however Jipijapa says it will happen; if/when there is a specific Infinispan-based 5.3 cache provider, Jipijapa will use that. It's more the "run outside of WildFly" case that I am talking about. So what are the things that we want to cover in Hibernate/Infinispan caching combo? AFAIK: 1. Transactional access support 2. Cluster support (distributed versus replicated versus invalidated) 3. Anything I am missing? So let's look at those 1-1: 1. You just said that you plan to drop transactional acccess support anyway, so nothing to see here... 2. I may be wrong here, but I do not think that hibernate-infinispan supported clustering (or at least very well) out-of-the-box. At least not based on the top google hits I saw for "hibernate infinispan cluster". Given these points and the fact that Infinispan can (and would already have to) implement JCache's `CachingProvider` / `CacheManager`, I simply do not buy that `hibernate-jcache` + `infinispan` is any less capable than the support we have today for Infinispan as a second level cache. Now, if you say that you want to develop a 5.3 provider to actually make cluster setup easier, leverage `CacheTransactionSynchronization` and/or other specific reasons.... great, that is completely your prerogative and the reason this is all still pluggable. P.S. JTA is a spec. JTA components are accessible from a "well known location" (aka, easily accessible by anyone). So I really just do not get your argument that `hibernate-jcache` + `infinispan` somehow loses the ability to leverage JTA. And btw this was absolutely not the intent with `CacheTransactionSynchronization`, which was instead intended to allow unified processing of "cache events" at the "end of a transaction" (as known to Hibernate) regardless of whether JTA or straight JDBC transactions are used. P.S.S. I totally agree with Sanne. The cache should be as correct as possible, however it is *always* possible to simply evict a piece of data from the cache to avoid conflicts. The database is *always* the "truth of the system". This in in fact exactly the principle that the collection cache works - any changes to that collection simply invalidate (evict) the data from the cache. On Thu, Mar 29, 2018 at 3:03 AM Radim Vansa wrote: > Hi Steve, > > on HipChat you've asked why hibernate-jcache + Infinispan's > implementation of JCache is not enough. It ultimately boils down to > > 1. performance > 2. correctness > > where (2) can be fine with some providers but then (1) suffers. > Infinispan offers transactional mode, but it's not serializable (gosh, > sometimes it's even read_uncommitted) and has its quirks. The > performance can't be as good as with non-tx mode, too. That's why the > native transactional caches support will be dropped in 5.3 and we'll > just emit a warning to update their configuration (and continue with > non-tx config). > > As a demonstration of this we can use the putFromLoad. If you implement > this as a (ideal serializable) transactional cache putIfAbsent, the > provider must either > a) lock the key (pessimistic approach) - but we don't want to block > other nodes removing data from the cache (on write) or putFromLoading > (on read!) > b) resolve conflicts when the transaction is committing: you figure out > that there are two concurrent updates and rollback one of the > transactions - that's not acceptable to us either, as any failure in > cache should not affect DB transaction. And there's a risk of blocking > between the 2 phases of commit, too. > > Theoretically you could just wipe any modified data on conflict - I > don't know if anyone does that, 'drop everything and proceed with > commit' is not something I'd expect from a general-purpose (NoSQL) DB. I > recall Alex's JCache implementation (for 5.2) storing some 'lock' > objects in the cache, and you probably don't want to wipe those. > > Interaction with evictAll/removeAll could be also problematic: not sure > about the other providers but Infinispan's clear() operation is > non-transactional even on tx cache (since Infinispan 7 or so) because > it's impractical to resolve all conflicts. I don't know details how > others provide that operation but there may be a hidden problem. > > Last but not least, you assume that the provider is transactional and it > provides JCache interface. JCache does not define interaction with JTA, > because it was hard to get agreement on non-tx behaviour (why did it > take 13 years to complete the JSR?) and it would be even harder for JTA. > So what you expect is just your extrapolation or wishful thinking, and > it's up to integrators to verify that the unwritten contract is > fulfilled within the scope of hibernate-jcache module use. Not that SPI > implementors would be in a better position, but at least we are aware > that (for us) it's not enough to implement those 3 classes and job's done. > > Of course the correctness aspect may be ignored with 'it's just a cache' > implying 'users expect stale/uncommitted data' as Sanne (who is much > closer to the customers than me) keeps repeating. However this is not > what 2LC promises as I understand it: the same results as DB would do. > > I am really grateful that in 5.3 you've provided the > CacheTransactionSynchronization that will help us boost (1) even further > by allowing us to execute all operations in parallel. And it's good that > you've made the SPI more expressive with the intent; there'll be a bunch > of TODOs in the 5.3 implementation to cover use cases that were not > handled in previous versions but now are obvious. > > Cheers > > Radim > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From fercoli at redhat.com Thu Mar 29 09:32:42 2018 From: fercoli at redhat.com (Fabio Massimo Ercoli) Date: Thu, 29 Mar 2018 15:32:42 +0200 Subject: [hibernate-dev] Hibernate OGM 5.3.1.Final released Message-ID: Hibernate OGM 5.3.1.Final is ready! This is a maintenance release fixing issues related to native queries pagination and projection. All the details in the blog post: *http://in.relation.to/2018/03/29/hibernate-ogm-5-3-1-Final-released/ * Thanks, ?Fabio -- FABIO MASSIMO ERCOLI Senior Software Engineer - Hibernate & Data Platform Red Hat fabio.ercoli at redhat.com M: (+39)-329.8681441