From sanne at hibernate.org Fri Apr 1 05:44:19 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 1 Apr 2016 10:44:19 +0100 Subject: [hibernate-dev] [OGM] Reduce the integrationtest directiry size In-Reply-To: References: <59FBCCD3-8628-4301-945D-8D273D1E4962@hibernate.org> Message-ID: I just merged Davide's work. Make sure you cleanup the old directories, as git will leave the stale files from previous builds. Thanks Davide! Sanne On 24 March 2016 at 10:30, Davide D'Alto wrote: > Yes, I'll have a look at this > > Davide > > On Thu, Mar 24, 2016 at 7:38 AM, Gunnar Morling > wrote: > >> 2016-03-24 8:24 GMT+01:00 Emmanuel Bernard : >> >> > I noticed that for each integration test module we do download a full >> > Wildfly distribution. Since we are having more and more integration test >> > module it adds up significantly. On top of that the integrationtest >> module >> > itself also downloads Wildfly. The current size is of integrationtest is >> > 1.3 GB with most of it attributed to Wildfly. Could we share the same >> > download somehow ? >> > >> >> There is the idea to move all the integration tests into a single module >> for the sake of reducing overall test runtime: Currently the server is >> started/stopped once for each of the integration test modules. >> >> This would be reduced to one such cycle, as a side-effect only one download >> would be needed, too. I thought there is an issue for that, but can't find >> it right now. >> >> @Davide, maybe you could check out this one if you need a break from the >> Neo4j work? >> >> >> > >> > On a side note, what are the ORM >> > target/test-results/binary/test/output.bin? In my quest for more space I >> > stumbled upon them. >> > >> > 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 >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Apr 1 07:32:28 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 01 Apr 2016 11:32:28 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: <20160331122254.GA11245@nineveh.local> References: <20160331122254.GA11245@nineveh.local> Message-ID: My initial goals and foreseeable decision-points in consolidating hibernate-core and hibernate-entitymanager are: 1. SessionFactory extends EntityManagerFactory (+ HibernateEntityManagerFactory methods) 2. Session extends EntityManager 3. Managing event-listener differences is the biggest thing we need to watch for. Initially I plan on having both sets of listener impls available and picking one or the other based on whether we were bootstrap via JPA bootstrapping or not. I'll have to see how that plays out. 4. Speaking of bootstrapping... since SessionFactory extends EntityManagerFactory, the bootstrapping APIs introduced in 5.0 is capable of building an EntityManagerFactory. I'd additionally like to develop an extended persistence.xml XSD, adding Hibernate specifics and allow JPA and Hibernate-native bootstrapping to read it. 5. Another big question is exceptions. JPA is very specific about the exceptions types that should be thrown in most cases. Ideally we can blend these 2 exception type hierarchies, but I think there will be times we have to chose one or the other. On Thu, Mar 31, 2016 at 7:23 AM Hardy Ferentschik wrote: > Hi, > > > 3. Baseline on Java 8 > > I did not vote on the other thread, so I do it here +1 :-) > > > Another one I'd like to discuss is the consolidation of the > hibernate-core > > and hibernate-entitymanager modules into a single module > > +1 I would love to see this finally happening. There were several > discussions > over time on whether and when it should be done. I think there was a > general agreement > that it makes sense to merge the modules, but afair there were always some > technicalities > which were preventing us to do it. ORM 6 seems to be a good point in time > to just do it. > > > --Hardy > From steve at hibernate.org Fri Apr 1 15:07:16 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 01 Apr 2016 19:07:16 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: I can look with you right after I finish with the hibernate-entitymanager consolidation into hibernate-core. Next week sometime, hopefully early... I'll follow up on your other email thread. On Thu, Mar 31, 2016 at 3:06 PM Gail Badner wrote: > I'm not sure what you mean by "ready". My POC is ready for discussion. > > On Thu, Mar 31, 2016 at 12:51 PM, Steve Ebersole > wrote: > >> Is it ready? >> >> On Thu, Mar 31, 2016, 2:28 PM Gail Badner wrote: >> >>> I would like to see OperationContext introduced. >>> >>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole >>> wrote: >>> >>>> Oh... One other change I want to propose is better incorporate >>>> MappedSuperclass into the org.hibernate.mapping hierarchy. Koen, this >>>> will >>>> affect tooling the most as it would mean changes to those contracts. >>>> >>>> If we are making disruptive changes there, I guess the next logical >>>> question is whether we use that opportunity to make other disruptive >>>> changes that we have been putting off due to disruption. Mainly I am >>>> thinking of modeling the org.hibernate.mapping representation of the >>>> domain >>>> hierarchy as more in-line with JPA terms. >>>> >>>> On Thu, Mar 31, 2016 at 7:43 AM Steve Ebersole >>>> wrote: >>>> >>>> > Well baseline on Jana 8 would mean app support for many Java 8 >>>> features. >>>> > Currency, optional, etc >>>> > >>>> > On Thu, Mar 31, 2016, 7:38 AM Petar Tahchiev >>>> > wrote: >>>> > >>>> >> +1 on going java8. I'd also suggest adding support for javax.currency >>>> >> JSR354 >>>> >> >>>> >> 2016-03-31 15:23 GMT+03:00 Vlad Mihalcea : >>>> >> >>>> >> > Hi, >>>> >> > >>>> >> > It makes sense to unify the core with hem in a single module. >>>> >> > >>>> >> > Currently, the flushing behavior differs if we execute a query >>>> through a >>>> >> > Session or through an EntityManager. >>>> >> > Does it mean that we eliminate those differences as well? >>>> >> > >>>> >> > Vlad >>>> >> > >>>> >> > On Thu, Mar 31, 2016 at 2:57 PM, Steve Ebersole < >>>> steve at hibernate.org> >>>> >> > wrote: >>>> >> > >>>> >> > > We have been having a few side discussions about plans for 6.0, >>>> and I >>>> >> > > thought it would be a good idea to consolidate them together. >>>> >> > > >>>> >> > > >>>> >> > > 1. Incorporate the SQM work. Lots of pieces go into this: >>>> >> > > 1. Replacing the interpretation of HQL/JPQL and Criteria >>>> >> queries. >>>> >> > > 2. *Possibly* leveraging SQM to deal with entity operations >>>> >> > > (load-by-id, merge, etc). >>>> >> > > 3. Improved Query contracts >>>> >> > > 4. Improved persister contracts (including addition of an >>>> >> > "embeddable >>>> >> > > persister"). >>>> >> > > 5. Improved Type contracts >>>> >> > > 2. Extensions to JPA criteria based on SQM work(this is >>>> probably >>>> >> more >>>> >> > on >>>> >> > > ongoing 6.x task) >>>> >> > > 3. Baseline on Java 8 >>>> >> > > >>>> >> > > Is there anything else anyone wants to discuss getting included? >>>> >> > > >>>> >> > > Another one I'd like to discuss is the consolidation of the >>>> >> > hibernate-core >>>> >> > > and hibernate-entitymanager modules into a single module >>>> (possibly >>>> >> > renamed >>>> >> > > hibernate-orm). There are a lot of reasons and benefits to doing >>>> >> this: >>>> >> > > >>>> >> > > 1. A major one would be the consolidation of "type systems". >>>> >> > Hibernate >>>> >> > > has org.hibernate.type.Type. JPA defines >>>> javax.persistence.Type. >>>> >> Now >>>> >> > > with >>>> >> > > SQM we have a 3rd type system in play. >>>> >> > > 2. It is also the major hurdle to moving to being able to >>>> fully >>>> >> > replace >>>> >> > > the legacy criteria with JPA criteria. If Session and >>>> >> EntityManager >>>> >> > (as >>>> >> > > well as SessionFactory ad EntiytManagerFactory) were fully >>>> >> integrated >>>> >> > > then >>>> >> > > Session would be able to build/handle JPA criteria queries. >>>> >> > > 3. Simplified HEM bootstrapping >>>> >> > > >>>> >> > > >>>> >> > > There are also a few challenges to doing this consolidation of >>>> the >>>> >> > > hibernate-core and hibernate-entitymanager modules. The big one >>>> tht >>>> >> > stick >>>> >> > > out in my head is event-listener with different behaviors >>>> between core >>>> >> > and >>>> >> > > hem. >>>> >> > > _______________________________________________ >>>> >> > > 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 >>>> >> > >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> 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 >>>> >> >>>> > >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> >>> > From steve at hibernate.org Fri Apr 1 15:14:49 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 01 Apr 2016 19:14:49 +0000 Subject: [hibernate-dev] HHH-10478 : OperationContext In-Reply-To: References: Message-ID: I do like the proposal. Awesome job on the gist. I'll look over the code over the next few days. On Thu, Mar 31, 2016 at 3:05 PM Gail Badner wrote: > Replying for consideration for 6.0. > > On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole > wrote: > >> This is going to have to wait post-5.1 as I mentioned earlier if this was >> not ready prior to last week. >> >> I have just too much on my plate to look at this over 2 days. >> >> On Mon, Feb 8, 2016 at 12:29 AM Gail Badner wrote: >> >>> The POC [1] assumes that we only need a single OperationContext for each >>> type of operation. OperationContextManager has a Map of OperationContext >>> by >>> OperationContextType. Each OperationContext object is lazily created on >>> the >>> first occurence of the corresponding type of operation. >>> >>> Currently, when an operation is initiated (e.g., by Session.merge( entity >>> )), OperationContextManager [2] does the following: >>> - calls ManageableOperationContext#beforeOperation, which puts the >>> OperationContext "in progress"; >>> - executes the operation, which performs cascades according to mappings; >>> - calls ManageableOperationContext#afterOperation, which puts the >>> OperationContext in an invalid state that is "not in progress". >>> >>> When an operation cascades to other entities, the same OperationContext >>> is >>> used. >>> >>> Obviously, OperationContextManager needs to know if an operation is >>> "top-level" (meaning that the operation is on the original entity, and >>> not >>> cascaded). In the POC, if the relevant OperationContext is not in >>> progress >>> at the time that an opeation is initiated, then OperationContextManager >>> assumes that the operation is top-level. If the OperationContext is "in >>> progress", then OperationContextManager assumes that this is a cascaded >>> operation. >>> >>> I am not sure this is always correct. Can anyone think of a case where >>> this >>> could break down? >>> >>> In the POC, the following EventSource methods that contain an argument >>> for >>> the operation cache has been deprecated and is no longer used because the >>> contents of that argument has been moved into an OperationContext: >>> >>> public void merge(String entityName, Object object, Map copiedAlready) >>> public void persist(String entityName, Object object, Map createdAlready) >>> public void persistOnFlush(String entityName, Object object, Map >>> copiedAlready) >>> public void refresh(String entityName, Object object, Map >>> refreshedAlready) >>> public void delete(String entityName, Object child, boolean >>> isCascadeDeleteEnabled, Set transientEntities) >>> >>> Before the POC, it was the above methods that indicated that it was not >>> top-level. If it turns out that having a single OperationContext is not >>> valid, then there needs to be some other way to determine if the >>> operation >>> was top-level. >>> >>> I had originally planned to use PersistenceContext#getCascadeLevel == 0 >>> to >>> indicate an operation was at the top-level, but I found that won't work >>> for >>> some operations. For example, the cascade level for a top-level delete >>> can >>> be > 1 when deleting orphans due to merge or save-or-update operations. >>> Another example is that cascade level is not 0 on top-level >>> save-or-update >>> while flushing. >>> >>> I have some ideas to work around this, but I didn't want to get too far >>> down that path if it wasn't an issue. >>> >>> Thanks, >>> Gail >>> >>> [1] >>> >>> https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java >>> [2] >>> >>> https://github.com/gbadner/hibernate-core/blob/3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/main/java/org/hibernate/engine/operationContext/internal/OperationContextManager.java#L132 >>> >>> >>> On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner wrote: >>> >>> > I've created a gist with an overview of the design: >>> > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a >>> new >>> > section tomorrow about possible shortcomings. >>> > >>> > Here is my POC: >>> > >>> https://github.com/hibernate/hibernate-orm/compare/master...gbadner:HHH-10478-OperationContext >>> > . Although no tests fail, the approach may be too simple to model what >>> is >>> > necessary. >>> > >>> > At this point the POC is squashed down to 1 commit: >>> > >>> https://github.com/hibernate/hibernate-orm/commit/3d0e2378cb998788b3205afb1e15c443c5ba77e8 >>> > >>> > Have a look and feel free to comment. >>> > >>> > Thanks, >>> > Gail >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> > From paranoiabla at gmail.com Fri Apr 1 15:41:03 2016 From: paranoiabla at gmail.com (Petar Tahchiev) Date: Fri, 1 Apr 2016 22:41:03 +0300 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: Is there any plans for reactive support in Hibernate6? 2016-04-01 22:07 GMT+03:00 Steve Ebersole : > I can look with you right after I finish with the hibernate-entitymanager > consolidation into hibernate-core. Next week sometime, hopefully early... > I'll follow up on your other email thread. > > On Thu, Mar 31, 2016 at 3:06 PM Gail Badner wrote: > > > I'm not sure what you mean by "ready". My POC is ready for discussion. > > > > On Thu, Mar 31, 2016 at 12:51 PM, Steve Ebersole > > wrote: > > > >> Is it ready? > >> > >> On Thu, Mar 31, 2016, 2:28 PM Gail Badner wrote: > >> > >>> I would like to see OperationContext introduced. > >>> > >>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole > >>> wrote: > >>> > >>>> Oh... One other change I want to propose is better incorporate > >>>> MappedSuperclass into the org.hibernate.mapping hierarchy. Koen, this > >>>> will > >>>> affect tooling the most as it would mean changes to those contracts. > >>>> > >>>> If we are making disruptive changes there, I guess the next logical > >>>> question is whether we use that opportunity to make other disruptive > >>>> changes that we have been putting off due to disruption. Mainly I am > >>>> thinking of modeling the org.hibernate.mapping representation of the > >>>> domain > >>>> hierarchy as more in-line with JPA terms. > >>>> > >>>> On Thu, Mar 31, 2016 at 7:43 AM Steve Ebersole > >>>> wrote: > >>>> > >>>> > Well baseline on Jana 8 would mean app support for many Java 8 > >>>> features. > >>>> > Currency, optional, etc > >>>> > > >>>> > On Thu, Mar 31, 2016, 7:38 AM Petar Tahchiev > > >>>> > wrote: > >>>> > > >>>> >> +1 on going java8. I'd also suggest adding support for > javax.currency > >>>> >> JSR354 > >>>> >> > >>>> >> 2016-03-31 15:23 GMT+03:00 Vlad Mihalcea >: > >>>> >> > >>>> >> > Hi, > >>>> >> > > >>>> >> > It makes sense to unify the core with hem in a single module. > >>>> >> > > >>>> >> > Currently, the flushing behavior differs if we execute a query > >>>> through a > >>>> >> > Session or through an EntityManager. > >>>> >> > Does it mean that we eliminate those differences as well? > >>>> >> > > >>>> >> > Vlad > >>>> >> > > >>>> >> > On Thu, Mar 31, 2016 at 2:57 PM, Steve Ebersole < > >>>> steve at hibernate.org> > >>>> >> > wrote: > >>>> >> > > >>>> >> > > We have been having a few side discussions about plans for 6.0, > >>>> and I > >>>> >> > > thought it would be a good idea to consolidate them together. > >>>> >> > > > >>>> >> > > > >>>> >> > > 1. Incorporate the SQM work. Lots of pieces go into this: > >>>> >> > > 1. Replacing the interpretation of HQL/JPQL and Criteria > >>>> >> queries. > >>>> >> > > 2. *Possibly* leveraging SQM to deal with entity > operations > >>>> >> > > (load-by-id, merge, etc). > >>>> >> > > 3. Improved Query contracts > >>>> >> > > 4. Improved persister contracts (including addition of an > >>>> >> > "embeddable > >>>> >> > > persister"). > >>>> >> > > 5. Improved Type contracts > >>>> >> > > 2. Extensions to JPA criteria based on SQM work(this is > >>>> probably > >>>> >> more > >>>> >> > on > >>>> >> > > ongoing 6.x task) > >>>> >> > > 3. Baseline on Java 8 > >>>> >> > > > >>>> >> > > Is there anything else anyone wants to discuss getting > included? > >>>> >> > > > >>>> >> > > Another one I'd like to discuss is the consolidation of the > >>>> >> > hibernate-core > >>>> >> > > and hibernate-entitymanager modules into a single module > >>>> (possibly > >>>> >> > renamed > >>>> >> > > hibernate-orm). There are a lot of reasons and benefits to > doing > >>>> >> this: > >>>> >> > > > >>>> >> > > 1. A major one would be the consolidation of "type systems". > >>>> >> > Hibernate > >>>> >> > > has org.hibernate.type.Type. JPA defines > >>>> javax.persistence.Type. > >>>> >> Now > >>>> >> > > with > >>>> >> > > SQM we have a 3rd type system in play. > >>>> >> > > 2. It is also the major hurdle to moving to being able to > >>>> fully > >>>> >> > replace > >>>> >> > > the legacy criteria with JPA criteria. If Session and > >>>> >> EntityManager > >>>> >> > (as > >>>> >> > > well as SessionFactory ad EntiytManagerFactory) were fully > >>>> >> integrated > >>>> >> > > then > >>>> >> > > Session would be able to build/handle JPA criteria queries. > >>>> >> > > 3. Simplified HEM bootstrapping > >>>> >> > > > >>>> >> > > > >>>> >> > > There are also a few challenges to doing this consolidation of > >>>> the > >>>> >> > > hibernate-core and hibernate-entitymanager modules. The big > one > >>>> tht > >>>> >> > stick > >>>> >> > > out in my head is event-listener with different behaviors > >>>> between core > >>>> >> > and > >>>> >> > > hem. > >>>> >> > > _______________________________________________ > >>>> >> > > 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 > >>>> >> > > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> 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 > >>>> >> > >>>> > > >>>> _______________________________________________ > >>>> 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 > -- 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 Fri Apr 1 15:53:32 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 1 Apr 2016 22:53:32 +0300 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: Just my 2 cents: Reactive means many things. From a persistence perspective, reactive implies CQRS which is exactly the reverse of what Hibernate currently does. Also, reactive systems are eventually consistent which contradicts Hibernate's strong consistency guarantees. Vlad On Fri, Apr 1, 2016 at 10:41 PM, Petar Tahchiev wrote: > Is there any plans for reactive support in Hibernate6? > > 2016-04-01 22:07 GMT+03:00 Steve Ebersole : > > > I can look with you right after I finish with the hibernate-entitymanager > > consolidation into hibernate-core. Next week sometime, hopefully > early... > > I'll follow up on your other email thread. > > > > On Thu, Mar 31, 2016 at 3:06 PM Gail Badner wrote: > > > > > I'm not sure what you mean by "ready". My POC is ready for discussion. > > > > > > On Thu, Mar 31, 2016 at 12:51 PM, Steve Ebersole > > > wrote: > > > > > >> Is it ready? > > >> > > >> On Thu, Mar 31, 2016, 2:28 PM Gail Badner wrote: > > >> > > >>> I would like to see OperationContext introduced. > > >>> > > >>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole > > > >>> wrote: > > >>> > > >>>> Oh... One other change I want to propose is better incorporate > > >>>> MappedSuperclass into the org.hibernate.mapping hierarchy. Koen, > this > > >>>> will > > >>>> affect tooling the most as it would mean changes to those contracts. > > >>>> > > >>>> If we are making disruptive changes there, I guess the next logical > > >>>> question is whether we use that opportunity to make other disruptive > > >>>> changes that we have been putting off due to disruption. Mainly I > am > > >>>> thinking of modeling the org.hibernate.mapping representation of the > > >>>> domain > > >>>> hierarchy as more in-line with JPA terms. > > >>>> > > >>>> On Thu, Mar 31, 2016 at 7:43 AM Steve Ebersole > > > >>>> wrote: > > >>>> > > >>>> > Well baseline on Jana 8 would mean app support for many Java 8 > > >>>> features. > > >>>> > Currency, optional, etc > > >>>> > > > >>>> > On Thu, Mar 31, 2016, 7:38 AM Petar Tahchiev < > paranoiabla at gmail.com > > > > > >>>> > wrote: > > >>>> > > > >>>> >> +1 on going java8. I'd also suggest adding support for > > javax.currency > > >>>> >> JSR354 > > >>>> >> > > >>>> >> 2016-03-31 15:23 GMT+03:00 Vlad Mihalcea < > mihalcea.vlad at gmail.com > > >: > > >>>> >> > > >>>> >> > Hi, > > >>>> >> > > > >>>> >> > It makes sense to unify the core with hem in a single module. > > >>>> >> > > > >>>> >> > Currently, the flushing behavior differs if we execute a query > > >>>> through a > > >>>> >> > Session or through an EntityManager. > > >>>> >> > Does it mean that we eliminate those differences as well? > > >>>> >> > > > >>>> >> > Vlad > > >>>> >> > > > >>>> >> > On Thu, Mar 31, 2016 at 2:57 PM, Steve Ebersole < > > >>>> steve at hibernate.org> > > >>>> >> > wrote: > > >>>> >> > > > >>>> >> > > We have been having a few side discussions about plans for > 6.0, > > >>>> and I > > >>>> >> > > thought it would be a good idea to consolidate them together. > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > 1. Incorporate the SQM work. Lots of pieces go into this: > > >>>> >> > > 1. Replacing the interpretation of HQL/JPQL and > Criteria > > >>>> >> queries. > > >>>> >> > > 2. *Possibly* leveraging SQM to deal with entity > > operations > > >>>> >> > > (load-by-id, merge, etc). > > >>>> >> > > 3. Improved Query contracts > > >>>> >> > > 4. Improved persister contracts (including addition of > an > > >>>> >> > "embeddable > > >>>> >> > > persister"). > > >>>> >> > > 5. Improved Type contracts > > >>>> >> > > 2. Extensions to JPA criteria based on SQM work(this is > > >>>> probably > > >>>> >> more > > >>>> >> > on > > >>>> >> > > ongoing 6.x task) > > >>>> >> > > 3. Baseline on Java 8 > > >>>> >> > > > > >>>> >> > > Is there anything else anyone wants to discuss getting > > included? > > >>>> >> > > > > >>>> >> > > Another one I'd like to discuss is the consolidation of the > > >>>> >> > hibernate-core > > >>>> >> > > and hibernate-entitymanager modules into a single module > > >>>> (possibly > > >>>> >> > renamed > > >>>> >> > > hibernate-orm). There are a lot of reasons and benefits to > > doing > > >>>> >> this: > > >>>> >> > > > > >>>> >> > > 1. A major one would be the consolidation of "type > systems". > > >>>> >> > Hibernate > > >>>> >> > > has org.hibernate.type.Type. JPA defines > > >>>> javax.persistence.Type. > > >>>> >> Now > > >>>> >> > > with > > >>>> >> > > SQM we have a 3rd type system in play. > > >>>> >> > > 2. It is also the major hurdle to moving to being able to > > >>>> fully > > >>>> >> > replace > > >>>> >> > > the legacy criteria with JPA criteria. If Session and > > >>>> >> EntityManager > > >>>> >> > (as > > >>>> >> > > well as SessionFactory ad EntiytManagerFactory) were fully > > >>>> >> integrated > > >>>> >> > > then > > >>>> >> > > Session would be able to build/handle JPA criteria > queries. > > >>>> >> > > 3. Simplified HEM bootstrapping > > >>>> >> > > > > >>>> >> > > > > >>>> >> > > There are also a few challenges to doing this consolidation > of > > >>>> the > > >>>> >> > > hibernate-core and hibernate-entitymanager modules. The big > > one > > >>>> tht > > >>>> >> > stick > > >>>> >> > > out in my head is event-listener with different behaviors > > >>>> between core > > >>>> >> > and > > >>>> >> > > hem. > > >>>> >> > > _______________________________________________ > > >>>> >> > > 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 > > >>>> >> > > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> -- > > >>>> >> 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 > > >>>> >> > > >>>> > > > >>>> _______________________________________________ > > >>>> 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 > > > > > > -- > 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 Apr 4 04:16:03 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 4 Apr 2016 10:16:03 +0200 Subject: [hibernate-dev] README.adoc of hibernate.org Message-ID: Hi, While setting up my environment for hibernate.org and in.relation.to, I noticed that there are broken links in the README... when we read it on GitHub (the .adoc extension is missing). It works OK when we read it from the website using http://hibernate.org/README/. I expect most people to use GitHub to read this document and the other ones related (docker/README.adoc, survival-guide.adoc). I was thinking about adding these files to .awestruct_ignore so that we don't generate website pages for them and fix them for GitHub browsing. Anyone against it? -- Guillaume From sanne at hibernate.org Mon Apr 4 05:52:06 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 4 Apr 2016 10:52:06 +0100 Subject: [hibernate-dev] README.adoc of hibernate.org In-Reply-To: References: Message-ID: It sounds good to me in principle, but I vaguely remember we intentionally added that README to the website for some reason. I don't remember what the reason was exactly though, so my doubt is that we're actually linking to that URL from somewhere. Let's not rush it and wait for several more opinions :) On 4 April 2016 at 09:16, Guillaume Smet wrote: > Hi, > > While setting up my environment for hibernate.org and in.relation.to, I > noticed that there are broken links in the README... when we read it on > GitHub (the .adoc extension is missing). It works OK when we read it from > the website using http://hibernate.org/README/. > > I expect most people to use GitHub to read this document and the other ones > related (docker/README.adoc, survival-guide.adoc). > > I was thinking about adding these files to .awestruct_ignore so that we > don't generate website pages for them and fix them for GitHub browsing. > > Anyone against it? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Apr 4 07:59:45 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 4 Apr 2016 13:59:45 +0200 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: One minor wish I'd have around bootstrapping: Can we make the initiators of services residing in the session factory service registry discoverable by means of a ServiceContributor as it's happening for services living in the standard registry? Currently, it's a hard coded list, requiring Hibernate OGM to provide its own SessionFactoryServiceRegistryFactory implementation which I believe does not fly when it comes to several integrators seeking to provide their own SF-scoped services. Thanks, --Gunnar 2016-03-31 13:57 GMT+02:00 Steve Ebersole : > We have been having a few side discussions about plans for 6.0, and I > thought it would be a good idea to consolidate them together. > > > 1. Incorporate the SQM work. Lots of pieces go into this: > 1. Replacing the interpretation of HQL/JPQL and Criteria queries. > 2. *Possibly* leveraging SQM to deal with entity operations > (load-by-id, merge, etc). > 3. Improved Query contracts > 4. Improved persister contracts (including addition of an "embeddable > persister"). > 5. Improved Type contracts > 2. Extensions to JPA criteria based on SQM work(this is probably more on > ongoing 6.x task) > 3. Baseline on Java 8 > > Is there anything else anyone wants to discuss getting included? > > Another one I'd like to discuss is the consolidation of the hibernate-core > and hibernate-entitymanager modules into a single module (possibly renamed > hibernate-orm). There are a lot of reasons and benefits to doing this: > > 1. A major one would be the consolidation of "type systems". Hibernate > has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now > with > SQM we have a 3rd type system in play. > 2. It is also the major hurdle to moving to being able to fully replace > the legacy criteria with JPA criteria. If Session and EntityManager (as > well as SessionFactory ad EntiytManagerFactory) were fully integrated > then > Session would be able to build/handle JPA criteria queries. > 3. Simplified HEM bootstrapping > > > There are also a few challenges to doing this consolidation of the > hibernate-core and hibernate-entitymanager modules. The big one tht stick > out in my head is event-listener with different behaviors between core and > hem. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Mon Apr 4 08:55:55 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 4 Apr 2016 13:55:55 +0100 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: On 4 April 2016 at 12:59, Gunnar Morling wrote: > One minor wish I'd have around bootstrapping: > > Can we make the initiators of services residing in the session factory > service registry discoverable by means of a ServiceContributor as it's > happening for services living in the standard registry? +1 And this reminds me that it would be nice for some services, i.e. the JTA Platform, to be injected as an instance rather than as a String pointing to the fully qualified classname. WildFly would benefit from it to override some services without having to add them to the Hibernate ORM classpath, and it might help with bootstrap speed too. Scott, AFAIR this was your great idea. Is there a JIRA for it, or could you create one for 6? Thanks, Sanne > > Currently, it's a hard coded list, requiring Hibernate OGM to provide its > own SessionFactoryServiceRegistryFactory implementation which I believe > does not fly when it comes to several integrators seeking to provide their > own SF-scoped services. > > Thanks, > > --Gunnar > > > > 2016-03-31 13:57 GMT+02:00 Steve Ebersole : > >> We have been having a few side discussions about plans for 6.0, and I >> thought it would be a good idea to consolidate them together. >> >> >> 1. Incorporate the SQM work. Lots of pieces go into this: >> 1. Replacing the interpretation of HQL/JPQL and Criteria queries. >> 2. *Possibly* leveraging SQM to deal with entity operations >> (load-by-id, merge, etc). >> 3. Improved Query contracts >> 4. Improved persister contracts (including addition of an "embeddable >> persister"). >> 5. Improved Type contracts >> 2. Extensions to JPA criteria based on SQM work(this is probably more on >> ongoing 6.x task) >> 3. Baseline on Java 8 >> >> Is there anything else anyone wants to discuss getting included? >> >> Another one I'd like to discuss is the consolidation of the hibernate-core >> and hibernate-entitymanager modules into a single module (possibly renamed >> hibernate-orm). There are a lot of reasons and benefits to doing this: >> >> 1. A major one would be the consolidation of "type systems". Hibernate >> has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now >> with >> SQM we have a 3rd type system in play. >> 2. It is also the major hurdle to moving to being able to fully replace >> the legacy criteria with JPA criteria. If Session and EntityManager (as >> well as SessionFactory ad EntiytManagerFactory) were fully integrated >> then >> Session would be able to build/handle JPA criteria queries. >> 3. Simplified HEM bootstrapping >> >> >> There are also a few challenges to doing this consolidation of the >> hibernate-core and hibernate-entitymanager modules. The big one tht stick >> out in my head is event-listener with different behaviors between core and >> hem. >> _______________________________________________ >> 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 Apr 4 09:02:52 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 4 Apr 2016 14:02:52 +0100 Subject: [hibernate-dev] Search: Lucene 6 is coming Message-ID: The Apache Lucene team is voting on candidate releases for Lucene 6.0.0. As usual we'll refrain from making API changes in a minor release, but we should start to sometimes try building against Lucene 6 to make sure to use APIs which will live longer, if there's choice. The most notable change is an entirely new strategy to handle numeric fields; including overhauled APIs. I guess Hibernate Search 6 will probably want to align with Lucene 6 and Hibernate ORM 6; only problem I see with that is I hope people won't get used to these all being nicely aligned as it's probably not sustainable as a rule.. just luck so far (although we managed that with all of the 3.x, 4.x, 5.x and now 6 series of Hibernate Search!). Both Lucene 6 and ORM 6 will require Java 8. I'll update the Search roadmap to reflect this aim, as I assume there won't be concerns? Thanks, Sanne From steve at hibernate.org Mon Apr 4 09:07:37 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 04 Apr 2016 13:07:37 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: JtaPlatform can already be injected by instance. In general, depending on the service initiator, most services can be specified as either name, Class or instance. Many configuration values as well. That's something I have been doing for years. On Mon, Apr 4, 2016, 7:57 AM Sanne Grinovero wrote: > On 4 April 2016 at 12:59, Gunnar Morling wrote: > > One minor wish I'd have around bootstrapping: > > > > Can we make the initiators of services residing in the session factory > > service registry discoverable by means of a ServiceContributor as it's > > happening for services living in the standard registry? > > +1 > And this reminds me that it would be nice for some services, i.e. the > JTA Platform, to be injected as an instance rather than as a String > pointing to the fully qualified classname. > > WildFly would benefit from it to override some services without having > to add them to the Hibernate ORM classpath, and it might help with > bootstrap speed too. > > Scott, AFAIR this was your great idea. Is there a JIRA for it, or > could you create one for 6? > > Thanks, > Sanne > > > > > Currently, it's a hard coded list, requiring Hibernate OGM to provide its > > own SessionFactoryServiceRegistryFactory implementation which I believe > > does not fly when it comes to several integrators seeking to provide > their > > own SF-scoped services. > > > > Thanks, > > > > --Gunnar > > > > > > > > 2016-03-31 13:57 GMT+02:00 Steve Ebersole : > > > >> We have been having a few side discussions about plans for 6.0, and I > >> thought it would be a good idea to consolidate them together. > >> > >> > >> 1. Incorporate the SQM work. Lots of pieces go into this: > >> 1. Replacing the interpretation of HQL/JPQL and Criteria queries. > >> 2. *Possibly* leveraging SQM to deal with entity operations > >> (load-by-id, merge, etc). > >> 3. Improved Query contracts > >> 4. Improved persister contracts (including addition of an > "embeddable > >> persister"). > >> 5. Improved Type contracts > >> 2. Extensions to JPA criteria based on SQM work(this is probably > more on > >> ongoing 6.x task) > >> 3. Baseline on Java 8 > >> > >> Is there anything else anyone wants to discuss getting included? > >> > >> Another one I'd like to discuss is the consolidation of the > hibernate-core > >> and hibernate-entitymanager modules into a single module (possibly > renamed > >> hibernate-orm). There are a lot of reasons and benefits to doing this: > >> > >> 1. A major one would be the consolidation of "type systems". > Hibernate > >> has org.hibernate.type.Type. JPA defines javax.persistence.Type. > Now > >> with > >> SQM we have a 3rd type system in play. > >> 2. It is also the major hurdle to moving to being able to fully > replace > >> the legacy criteria with JPA criteria. If Session and EntityManager > (as > >> well as SessionFactory ad EntiytManagerFactory) were fully integrated > >> then > >> Session would be able to build/handle JPA criteria queries. > >> 3. Simplified HEM bootstrapping > >> > >> > >> There are also a few challenges to doing this consolidation of the > >> hibernate-core and hibernate-entitymanager modules. The big one tht > stick > >> out in my head is event-listener with different behaviors between core > and > >> hem. > >> _______________________________________________ > >> 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 steve at hibernate.org Mon Apr 4 09:08:33 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 04 Apr 2016 13:08:33 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: I think this is reasonable. Is there a Jira for it? On Mon, Apr 4, 2016, 6:59 AM Gunnar Morling wrote: > One minor wish I'd have around bootstrapping: > > Can we make the initiators of services residing in the session factory > service registry discoverable by means of a ServiceContributor as it's > happening for services living in the standard registry? > > Currently, it's a hard coded list, requiring Hibernate OGM to provide its > own SessionFactoryServiceRegistryFactory implementation which I believe > does not fly when it comes to several integrators seeking to provide their > own SF-scoped services. > > Thanks, > > --Gunnar > > > > 2016-03-31 13:57 GMT+02:00 Steve Ebersole : > >> We have been having a few side discussions about plans for 6.0, and I >> thought it would be a good idea to consolidate them together. >> >> >> 1. Incorporate the SQM work. Lots of pieces go into this: >> 1. Replacing the interpretation of HQL/JPQL and Criteria queries. >> 2. *Possibly* leveraging SQM to deal with entity operations >> (load-by-id, merge, etc). >> 3. Improved Query contracts >> 4. Improved persister contracts (including addition of an >> "embeddable >> persister"). >> 5. Improved Type contracts >> 2. Extensions to JPA criteria based on SQM work(this is probably more >> on >> ongoing 6.x task) >> 3. Baseline on Java 8 > > >> >> Is there anything else anyone wants to discuss getting included? >> >> Another one I'd like to discuss is the consolidation of the hibernate-core >> and hibernate-entitymanager modules into a single module (possibly renamed >> hibernate-orm). There are a lot of reasons and benefits to doing this: >> >> 1. A major one would be the consolidation of "type systems". Hibernate > > >> has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now >> with >> SQM we have a 3rd type system in play. >> > 2. It is also the major hurdle to moving to being able to fully replace > > >> the legacy criteria with JPA criteria. If Session and EntityManager >> (as >> well as SessionFactory ad EntiytManagerFactory) were fully integrated >> then >> Session would be able to build/handle JPA criteria queries. >> > 3. Simplified HEM bootstrapping > > >> >> >> There are also a few challenges to doing this consolidation of the >> hibernate-core and hibernate-entitymanager modules. The big one tht stick >> out in my head is event-listener with different behaviors between core and >> hem. >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From sanne at hibernate.org Mon Apr 4 09:10:39 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 4 Apr 2016 14:10:39 +0100 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: On 4 April 2016 at 14:07, Steve Ebersole wrote: > JtaPlatform can already be injected by instance. In general, depending on > the service initiator, most services can be specified as either name, Class > or instance. Many configuration values as well. > > That's something I have been doing for years. Cool, then I'm mistaken about which component it was, just that Scott mentioned it would be nice to inject something which was currently not the case. Maybe my memory is years outdated? Scott? Thanks, Sanne > > > On Mon, Apr 4, 2016, 7:57 AM Sanne Grinovero wrote: >> >> On 4 April 2016 at 12:59, Gunnar Morling wrote: >> > One minor wish I'd have around bootstrapping: >> > >> > Can we make the initiators of services residing in the session factory >> > service registry discoverable by means of a ServiceContributor as it's >> > happening for services living in the standard registry? >> >> +1 >> And this reminds me that it would be nice for some services, i.e. the >> JTA Platform, to be injected as an instance rather than as a String >> pointing to the fully qualified classname. >> >> WildFly would benefit from it to override some services without having >> to add them to the Hibernate ORM classpath, and it might help with >> bootstrap speed too. >> >> Scott, AFAIR this was your great idea. Is there a JIRA for it, or >> could you create one for 6? >> >> Thanks, >> Sanne >> >> > >> > Currently, it's a hard coded list, requiring Hibernate OGM to provide >> > its >> > own SessionFactoryServiceRegistryFactory implementation which I believe >> > does not fly when it comes to several integrators seeking to provide >> > their >> > own SF-scoped services. >> > >> > Thanks, >> > >> > --Gunnar >> > >> > >> > >> > 2016-03-31 13:57 GMT+02:00 Steve Ebersole : >> > >> >> We have been having a few side discussions about plans for 6.0, and I >> >> thought it would be a good idea to consolidate them together. >> >> >> >> >> >> 1. Incorporate the SQM work. Lots of pieces go into this: >> >> 1. Replacing the interpretation of HQL/JPQL and Criteria queries. >> >> 2. *Possibly* leveraging SQM to deal with entity operations >> >> (load-by-id, merge, etc). >> >> 3. Improved Query contracts >> >> 4. Improved persister contracts (including addition of an >> >> "embeddable >> >> persister"). >> >> 5. Improved Type contracts >> >> 2. Extensions to JPA criteria based on SQM work(this is probably >> >> more on >> >> ongoing 6.x task) >> >> 3. Baseline on Java 8 >> >> >> >> Is there anything else anyone wants to discuss getting included? >> >> >> >> Another one I'd like to discuss is the consolidation of the >> >> hibernate-core >> >> and hibernate-entitymanager modules into a single module (possibly >> >> renamed >> >> hibernate-orm). There are a lot of reasons and benefits to doing this: >> >> >> >> 1. A major one would be the consolidation of "type systems". >> >> Hibernate >> >> has org.hibernate.type.Type. JPA defines javax.persistence.Type. >> >> Now >> >> with >> >> SQM we have a 3rd type system in play. >> >> 2. It is also the major hurdle to moving to being able to fully >> >> replace >> >> the legacy criteria with JPA criteria. If Session and EntityManager >> >> (as >> >> well as SessionFactory ad EntiytManagerFactory) were fully >> >> integrated >> >> then >> >> Session would be able to build/handle JPA criteria queries. >> >> 3. Simplified HEM bootstrapping >> >> >> >> >> >> There are also a few challenges to doing this consolidation of the >> >> hibernate-core and hibernate-entitymanager modules. The big one tht >> >> stick >> >> out in my head is event-listener with different behaviors between core >> >> and >> >> hem. >> >> _______________________________________________ >> >> 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 gunnar at hibernate.org Mon Apr 4 09:24:46 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 4 Apr 2016 15:24:46 +0200 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: Now there is: https://hibernate.atlassian.net/browse/HHH-10669 :) Thanks! 2016-04-04 15:08 GMT+02:00 Steve Ebersole : > I think this is reasonable. Is there a Jira for it? > > > On Mon, Apr 4, 2016, 6:59 AM Gunnar Morling wrote: > >> One minor wish I'd have around bootstrapping: >> >> Can we make the initiators of services residing in the session factory >> service registry discoverable by means of a ServiceContributor as it's >> happening for services living in the standard registry? >> >> Currently, it's a hard coded list, requiring Hibernate OGM to provide its >> own SessionFactoryServiceRegistryFactory implementation which I believe >> does not fly when it comes to several integrators seeking to provide their >> own SF-scoped services. >> >> Thanks, >> >> --Gunnar >> >> >> >> 2016-03-31 13:57 GMT+02:00 Steve Ebersole : >> >>> We have been having a few side discussions about plans for 6.0, and I >>> thought it would be a good idea to consolidate them together. >>> >>> >>> 1. Incorporate the SQM work. Lots of pieces go into this: >>> 1. Replacing the interpretation of HQL/JPQL and Criteria queries. >>> 2. *Possibly* leveraging SQM to deal with entity operations >>> (load-by-id, merge, etc). >>> 3. Improved Query contracts >>> 4. Improved persister contracts (including addition of an >>> "embeddable >>> persister"). >>> 5. Improved Type contracts >>> 2. Extensions to JPA criteria based on SQM work(this is probably more >>> on >>> ongoing 6.x task) >>> 3. Baseline on Java 8 >> >> >>> >>> Is there anything else anyone wants to discuss getting included? >>> >>> Another one I'd like to discuss is the consolidation of the >>> hibernate-core >>> and hibernate-entitymanager modules into a single module (possibly >>> renamed >>> hibernate-orm). There are a lot of reasons and benefits to doing this: >>> >>> 1. A major one would be the consolidation of "type systems". >>> Hibernate >> >> >>> has org.hibernate.type.Type. JPA defines javax.persistence.Type. >>> Now with >>> SQM we have a 3rd type system in play. >>> >> 2. It is also the major hurdle to moving to being able to fully replace >> >> >>> the legacy criteria with JPA criteria. If Session and EntityManager >>> (as >>> well as SessionFactory ad EntiytManagerFactory) were fully integrated >>> then >>> Session would be able to build/handle JPA criteria queries. >>> >> 3. Simplified HEM bootstrapping >> >> >>> >>> >>> There are also a few challenges to doing this consolidation of the >>> hibernate-core and hibernate-entitymanager modules. The big one tht >>> stick >>> out in my head is event-listener with different behaviors between core >>> and >>> hem. >>> >> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> From mihalcea.vlad at gmail.com Mon Apr 4 09:35:29 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 4 Apr 2016 16:35:29 +0300 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Hi Gail, I pushed the 5.1 documentation into the 5,0 branch. The only thing that's needed now is to modify the release procedure which I'll send it as a PR. We also have to modify the hibernate.org site so that 5.0 references the same documentation links as 5.1. Vlad On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea wrote: > The 4.x branches contain the old documentation, the one that was written > with Hibernate 3 in mind. > > The new documentation work was started in 5.0 but we only got it done in > 5.1, so 5.0 doesn't contain all the additions we made to the new > documentation. > > I can backport it for sure, but I don't know if it won't break something > during the release phase. > > For this purpose, I'm going to split this task in two: > > 1. Copy the whole asciidoc User Guide that we wrote from scratch. This > step will contain a lot of modifications so it will be difficult to review > it in GitHub probably. But it can be reviewing manually. > 2. Modify the release procedure to use the new User Guide. This step can > be reviewed by you and Steve so we make sure we don't break anything. > > Vlad > > On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner wrote: > >> I noticed there is some information in 4.2 docs that are not in 5.0. I'm >> not sure what happened there. >> >> Is there info in the 5.1 docs that does not apply to 5.0? If so, is there >> a way to easily exclude it? >> >> I don't know what all is involved in backporting the docs. If it can be >> done safely and excluding 5.1-specific info, then please go ahead. >> >> Thanks! >> Gail >> >> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea >> wrote: >> >>> I made the change for 4.2. >>> >>> For 5.0, we should switch to the current 5.1 documentation because the >>> 5.0 User Guide lacks a lot of information. >>> It requires adding the asciidoc documentation, Gradle configs, and also >>> change the release procedure to use asciidoc instead of docbook. >>> >>> Should we add a new task for this? >>> >>> Vlad >>> >>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner wrote: >>> >>>> Hi Vlad, >>>> >>>> Yes, please update the doc for 5.0 and 4.2. >>>> >>>> Thanks! >>>> Gail >>>> >>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>> mihalcea.vlad at gmail.com> wrote: >>>> >>>>> Hi Gail, >>>>> >>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>> release will publish the updated doc, right? >>>>> Should the documentation be updated for the 4.x branches too? >>>>> >>>>> Vlad >>>>> >>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole >>>>> wrote: >>>>> >>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, however I >>>>>> would only change it on master. >>>>>> >>>>>> For the other branches, if anything, just update the doc. >>>>>> >>>>>> >>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> I think this PR is valid: >>>>>>> >>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>> >>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE connection >>>>>>> release mode. >>>>>>> >>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we state in >>>>>>> the docs? >>>>>>> >>>>>>> Vlad >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>> >>>>> >>>> >>> >> > From smarlow at redhat.com Mon Apr 4 10:19:58 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 4 Apr 2016 10:19:58 -0400 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: <5702780E.8020708@redhat.com> On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > On 4 April 2016 at 12:59, Gunnar Morling wrote: >> One minor wish I'd have around bootstrapping: >> >> Can we make the initiators of services residing in the session factory >> service registry discoverable by means of a ServiceContributor as it's >> happening for services living in the standard registry? > > +1 > And this reminds me that it would be nice for some services, i.e. the > JTA Platform, to be injected as an instance rather than as a String > pointing to the fully qualified classname. > > WildFly would benefit from it to override some services without having > to add them to the Hibernate ORM classpath, and it might help with > bootstrap speed too. > > Scott, AFAIR this was your great idea. Is there a JIRA for it, or > could you create one for 6? From an earlier discussion: " hibernate.cache.region.factory_class is currently used by Jipijapa to specify the name of the cache region factory class name. I think this implies that the Hibernate ORM classloader will need access to the Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, the ORM module (org.hibernate:main) depends on the org.hibernate.jipijapa-hibernate5:main module to resolve this class. " Steve made similar changes for other properties (years ago I think) but not all properties were updated to allow class instances to be specified (in addition to class name). So, it was really Steve Ebersole's great idea, not mine :) > > Thanks, > Sanne > >> >> Currently, it's a hard coded list, requiring Hibernate OGM to provide its >> own SessionFactoryServiceRegistryFactory implementation which I believe >> does not fly when it comes to several integrators seeking to provide their >> own SF-scoped services. >> >> Thanks, >> >> --Gunnar >> >> >> >> 2016-03-31 13:57 GMT+02:00 Steve Ebersole : >> >>> We have been having a few side discussions about plans for 6.0, and I >>> thought it would be a good idea to consolidate them together. >>> >>> >>> 1. Incorporate the SQM work. Lots of pieces go into this: >>> 1. Replacing the interpretation of HQL/JPQL and Criteria queries. >>> 2. *Possibly* leveraging SQM to deal with entity operations >>> (load-by-id, merge, etc). >>> 3. Improved Query contracts >>> 4. Improved persister contracts (including addition of an "embeddable >>> persister"). >>> 5. Improved Type contracts >>> 2. Extensions to JPA criteria based on SQM work(this is probably more on >>> ongoing 6.x task) >>> 3. Baseline on Java 8 >>> >>> Is there anything else anyone wants to discuss getting included? >>> >>> Another one I'd like to discuss is the consolidation of the hibernate-core >>> and hibernate-entitymanager modules into a single module (possibly renamed >>> hibernate-orm). There are a lot of reasons and benefits to doing this: >>> >>> 1. A major one would be the consolidation of "type systems". Hibernate >>> has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now >>> with >>> SQM we have a 3rd type system in play. >>> 2. It is also the major hurdle to moving to being able to fully replace >>> the legacy criteria with JPA criteria. If Session and EntityManager (as >>> well as SessionFactory ad EntiytManagerFactory) were fully integrated >>> then >>> Session would be able to build/handle JPA criteria queries. >>> 3. Simplified HEM bootstrapping >>> >>> >>> There are also a few challenges to doing this consolidation of the >>> hibernate-core and hibernate-entitymanager modules. The big one tht stick >>> out in my head is event-listener with different behaviors between core and >>> hem. >>> _______________________________________________ >>> 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 Apr 4 10:32:19 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 04 Apr 2016 14:32:19 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: <5702780E.8020708@redhat.com> References: <5702780E.8020708@redhat.com> Message-ID: Ok, so we aren't accepting a Class reference or instance for L2C RegionFactory? Is there a Jira for that? On Mon, Apr 4, 2016 at 9:20 AM Scott Marlow wrote: > On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > > On 4 April 2016 at 12:59, Gunnar Morling wrote: > >> One minor wish I'd have around bootstrapping: > >> > >> Can we make the initiators of services residing in the session factory > >> service registry discoverable by means of a ServiceContributor as it's > >> happening for services living in the standard registry? > > > > +1 > > And this reminds me that it would be nice for some services, i.e. the > > JTA Platform, to be injected as an instance rather than as a String > > pointing to the fully qualified classname. > > > > WildFly would benefit from it to override some services without having > > to add them to the Hibernate ORM classpath, and it might help with > > bootstrap speed too. > > > > Scott, AFAIR this was your great idea. Is there a JIRA for it, or > > could you create one for 6? > > From an earlier discussion: > > " > hibernate.cache.region.factory_class is currently used by Jipijapa to > specify the name of the cache region factory class name. I think this > implies that the Hibernate ORM classloader will need access to the > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, > the ORM module (org.hibernate:main) depends on the > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > " > > Steve made similar changes for other properties (years ago I think) but > not all properties were updated to allow class instances to be specified > (in addition to class name). So, it was really Steve Ebersole's great > idea, not mine :) > > > > > Thanks, > > Sanne > > > >> > >> Currently, it's a hard coded list, requiring Hibernate OGM to provide > its > >> own SessionFactoryServiceRegistryFactory implementation which I believe > >> does not fly when it comes to several integrators seeking to provide > their > >> own SF-scoped services. > >> > >> Thanks, > >> > >> --Gunnar > >> > >> > >> > >> 2016-03-31 13:57 GMT+02:00 Steve Ebersole : > >> > >>> We have been having a few side discussions about plans for 6.0, and I > >>> thought it would be a good idea to consolidate them together. > >>> > >>> > >>> 1. Incorporate the SQM work. Lots of pieces go into this: > >>> 1. Replacing the interpretation of HQL/JPQL and Criteria > queries. > >>> 2. *Possibly* leveraging SQM to deal with entity operations > >>> (load-by-id, merge, etc). > >>> 3. Improved Query contracts > >>> 4. Improved persister contracts (including addition of an > "embeddable > >>> persister"). > >>> 5. Improved Type contracts > >>> 2. Extensions to JPA criteria based on SQM work(this is probably > more on > >>> ongoing 6.x task) > >>> 3. Baseline on Java 8 > >>> > >>> Is there anything else anyone wants to discuss getting included? > >>> > >>> Another one I'd like to discuss is the consolidation of the > hibernate-core > >>> and hibernate-entitymanager modules into a single module (possibly > renamed > >>> hibernate-orm). There are a lot of reasons and benefits to doing this: > >>> > >>> 1. A major one would be the consolidation of "type systems". > Hibernate > >>> has org.hibernate.type.Type. JPA defines javax.persistence.Type. > Now > >>> with > >>> SQM we have a 3rd type system in play. > >>> 2. It is also the major hurdle to moving to being able to fully > replace > >>> the legacy criteria with JPA criteria. If Session and > EntityManager (as > >>> well as SessionFactory ad EntiytManagerFactory) were fully > integrated > >>> then > >>> Session would be able to build/handle JPA criteria queries. > >>> 3. Simplified HEM bootstrapping > >>> > >>> > >>> There are also a few challenges to doing this consolidation of the > >>> hibernate-core and hibernate-entitymanager modules. The big one tht > stick > >>> out in my head is event-listener with different behaviors between core > and > >>> hem. > >>> _______________________________________________ > >>> 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 smarlow at redhat.com Mon Apr 4 10:37:54 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 4 Apr 2016 10:37:54 -0400 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: <5702780E.8020708@redhat.com> Message-ID: <57027C42.2090709@redhat.com> Hmm, just searched through irc history and came up with fixed by https://hibernate.atlassian.net/browse/HHH-7552. Nice to see this already fixed! ;) On 04/04/2016 10:32 AM, Steve Ebersole wrote: > Ok, so we aren't accepting a Class reference or instance for L2C > RegionFactory? Is there a Jira for that? > > > On Mon, Apr 4, 2016 at 9:20 AM Scott Marlow > wrote: > > On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > > On 4 April 2016 at 12:59, Gunnar Morling > wrote: > >> One minor wish I'd have around bootstrapping: > >> > >> Can we make the initiators of services residing in the session > factory > >> service registry discoverable by means of a ServiceContributor > as it's > >> happening for services living in the standard registry? > > > > +1 > > And this reminds me that it would be nice for some services, i.e. the > > JTA Platform, to be injected as an instance rather than as a String > > pointing to the fully qualified classname. > > > > WildFly would benefit from it to override some services without > having > > to add them to the Hibernate ORM classpath, and it might help with > > bootstrap speed too. > > > > Scott, AFAIR this was your great idea. Is there a JIRA for it, or > > could you create one for 6? > > From an earlier discussion: > > " > hibernate.cache.region.factory_class is currently used by Jipijapa to > specify the name of the cache region factory class name. I think this > implies that the Hibernate ORM classloader will need access to the > Jipijapa supplied class (as mentioned above). Currently, in WildFly 10, > the ORM module (org.hibernate:main) depends on the > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > " > > Steve made similar changes for other properties (years ago I think) but > not all properties were updated to allow class instances to be specified > (in addition to class name). So, it was really Steve Ebersole's great > idea, not mine :) > > > > > Thanks, > > Sanne > > > >> > >> Currently, it's a hard coded list, requiring Hibernate OGM to > provide its > >> own SessionFactoryServiceRegistryFactory implementation which I > believe > >> does not fly when it comes to several integrators seeking to > provide their > >> own SF-scoped services. > >> > >> Thanks, > >> > >> --Gunnar > >> > >> > >> > >> 2016-03-31 13:57 GMT+02:00 Steve Ebersole >: > >> > >>> We have been having a few side discussions about plans for 6.0, > and I > >>> thought it would be a good idea to consolidate them together. > >>> > >>> > >>> 1. Incorporate the SQM work. Lots of pieces go into this: > >>> 1. Replacing the interpretation of HQL/JPQL and Criteria > queries. > >>> 2. *Possibly* leveraging SQM to deal with entity operations > >>> (load-by-id, merge, etc). > >>> 3. Improved Query contracts > >>> 4. Improved persister contracts (including addition of > an "embeddable > >>> persister"). > >>> 5. Improved Type contracts > >>> 2. Extensions to JPA criteria based on SQM work(this is > probably more on > >>> ongoing 6.x task) > >>> 3. Baseline on Java 8 > >>> > >>> Is there anything else anyone wants to discuss getting included? > >>> > >>> Another one I'd like to discuss is the consolidation of the > hibernate-core > >>> and hibernate-entitymanager modules into a single module > (possibly renamed > >>> hibernate-orm). There are a lot of reasons and benefits to > doing this: > >>> > >>> 1. A major one would be the consolidation of "type > systems". Hibernate > >>> has org.hibernate.type.Type. JPA defines > javax.persistence.Type. Now > >>> with > >>> SQM we have a 3rd type system in play. > >>> 2. It is also the major hurdle to moving to being able to > fully replace > >>> the legacy criteria with JPA criteria. If Session and > EntityManager (as > >>> well as SessionFactory ad EntiytManagerFactory) were fully > integrated > >>> then > >>> Session would be able to build/handle JPA criteria queries. > >>> 3. Simplified HEM bootstrapping > >>> > >>> > >>> There are also a few challenges to doing this consolidation of the > >>> hibernate-core and hibernate-entitymanager modules. The big > one tht stick > >>> out in my head is event-listener with different behaviors > between core and > >>> hem. > >>> _______________________________________________ > >>> 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 steve at hibernate.org Mon Apr 4 10:48:15 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 04 Apr 2016 14:48:15 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: <57027C42.2090709@redhat.com> References: <5702780E.8020708@redhat.com> <57027C42.2090709@redhat.com> Message-ID: So there we go :) On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow wrote: > Hmm, just searched through irc history and came up with fixed by > https://hibernate.atlassian.net/browse/HHH-7552. Nice to see this > already fixed! ;) > > On 04/04/2016 10:32 AM, Steve Ebersole wrote: > > Ok, so we aren't accepting a Class reference or instance for L2C > > RegionFactory? Is there a Jira for that? > > > > > > On Mon, Apr 4, 2016 at 9:20 AM Scott Marlow > > wrote: > > > > On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > > > On 4 April 2016 at 12:59, Gunnar Morling > > wrote: > > >> One minor wish I'd have around bootstrapping: > > >> > > >> Can we make the initiators of services residing in the session > > factory > > >> service registry discoverable by means of a ServiceContributor > > as it's > > >> happening for services living in the standard registry? > > > > > > +1 > > > And this reminds me that it would be nice for some services, i.e. > the > > > JTA Platform, to be injected as an instance rather than as a > String > > > pointing to the fully qualified classname. > > > > > > WildFly would benefit from it to override some services without > > having > > > to add them to the Hibernate ORM classpath, and it might help with > > > bootstrap speed too. > > > > > > Scott, AFAIR this was your great idea. Is there a JIRA for it, or > > > could you create one for 6? > > > > From an earlier discussion: > > > > " > > hibernate.cache.region.factory_class is currently used by Jipijapa to > > specify the name of the cache region factory class name. I think this > > implies that the Hibernate ORM classloader will need access to the > > Jipijapa supplied class (as mentioned above). Currently, in WildFly > 10, > > the ORM module (org.hibernate:main) depends on the > > org.hibernate.jipijapa-hibernate5:main module to resolve this class. > > " > > > > Steve made similar changes for other properties (years ago I think) > but > > not all properties were updated to allow class instances to be > specified > > (in addition to class name). So, it was really Steve Ebersole's > great > > idea, not mine :) > > > > > > > > Thanks, > > > Sanne > > > > > >> > > >> Currently, it's a hard coded list, requiring Hibernate OGM to > > provide its > > >> own SessionFactoryServiceRegistryFactory implementation which I > > believe > > >> does not fly when it comes to several integrators seeking to > > provide their > > >> own SF-scoped services. > > >> > > >> Thanks, > > >> > > >> --Gunnar > > >> > > >> > > >> > > >> 2016-03-31 13:57 GMT+02:00 Steve Ebersole > >: > > >> > > >>> We have been having a few side discussions about plans for 6.0, > > and I > > >>> thought it would be a good idea to consolidate them together. > > >>> > > >>> > > >>> 1. Incorporate the SQM work. Lots of pieces go into this: > > >>> 1. Replacing the interpretation of HQL/JPQL and Criteria > > queries. > > >>> 2. *Possibly* leveraging SQM to deal with entity > operations > > >>> (load-by-id, merge, etc). > > >>> 3. Improved Query contracts > > >>> 4. Improved persister contracts (including addition of > > an "embeddable > > >>> persister"). > > >>> 5. Improved Type contracts > > >>> 2. Extensions to JPA criteria based on SQM work(this is > > probably more on > > >>> ongoing 6.x task) > > >>> 3. Baseline on Java 8 > > >>> > > >>> Is there anything else anyone wants to discuss getting included? > > >>> > > >>> Another one I'd like to discuss is the consolidation of the > > hibernate-core > > >>> and hibernate-entitymanager modules into a single module > > (possibly renamed > > >>> hibernate-orm). There are a lot of reasons and benefits to > > doing this: > > >>> > > >>> 1. A major one would be the consolidation of "type > > systems". Hibernate > > >>> has org.hibernate.type.Type. JPA defines > > javax.persistence.Type. Now > > >>> with > > >>> SQM we have a 3rd type system in play. > > >>> 2. It is also the major hurdle to moving to being able to > > fully replace > > >>> the legacy criteria with JPA criteria. If Session and > > EntityManager (as > > >>> well as SessionFactory ad EntiytManagerFactory) were fully > > integrated > > >>> then > > >>> Session would be able to build/handle JPA criteria queries. > > >>> 3. Simplified HEM bootstrapping > > >>> > > >>> > > >>> There are also a few challenges to doing this consolidation of > the > > >>> hibernate-core and hibernate-entitymanager modules. The big > > one tht stick > > >>> out in my head is event-listener with different behaviors > > between core and > > >>> hem. > > >>> _______________________________________________ > > >>> 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 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 Mon Apr 4 11:22:38 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 4 Apr 2016 17:22:38 +0200 Subject: [hibernate-dev] README.adoc of hibernate.org In-Reply-To: References: Message-ID: <20160404152238.GE8238@hibernate.org> I liked the idea of the README as a proper webpage. But I can live without it and I don't have strong grounded arguments for it. On Mon 2016-04-04 10:52, Sanne Grinovero wrote: > It sounds good to me in principle, but I vaguely remember we > intentionally added that README to the website for some reason. > > I don't remember what the reason was exactly though, so my doubt is > that we're actually linking to that URL from somewhere. > Let's not rush it and wait for several more opinions :) > > On 4 April 2016 at 09:16, Guillaume Smet wrote: > > Hi, > > > > While setting up my environment for hibernate.org and in.relation.to, I > > noticed that there are broken links in the README... when we read it on > > GitHub (the .adoc extension is missing). It works OK when we read it from > > the website using http://hibernate.org/README/. > > > > I expect most people to use GitHub to read this document and the other ones > > related (docker/README.adoc, survival-guide.adoc). > > > > I was thinking about adding these files to .awestruct_ignore so that we > > don't generate website pages for them and fix them for GitHub browsing. > > > > Anyone against it? > > > > -- > > Guillaume > > _______________________________________________ > > 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 Mon Apr 4 11:23:48 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 4 Apr 2016 17:23:48 +0200 Subject: [hibernate-dev] Search: Lucene 6 is coming In-Reply-To: References: Message-ID: <20160404152348.GF8238@hibernate.org> +1 On Mon 2016-04-04 14:02, Sanne Grinovero wrote: > The Apache Lucene team is voting on candidate releases for Lucene 6.0.0. > > As usual we'll refrain from making API changes in a minor release, but > we should start to sometimes try building against Lucene 6 to make > sure to use APIs which will live longer, if there's choice. > > The most notable change is an entirely new strategy to handle numeric > fields; including overhauled APIs. > > I guess Hibernate Search 6 will probably want to align with Lucene 6 > and Hibernate ORM 6; only problem I see with that is I hope people > won't get used to these all being nicely aligned as it's probably not > sustainable as a rule.. just luck so far (although we managed that > with all of the 3.x, 4.x, 5.x and now 6 series of Hibernate Search!). > > Both Lucene 6 and ORM 6 will require Java 8. > > I'll update the Search roadmap to reflect this aim, as I assume there > won't be concerns? > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From emmanuel at hibernate.org Mon Apr 4 11:29:23 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 4 Apr 2016 17:29:23 +0200 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: Message-ID: <20160404152923.GG8238@hibernate.org> I don't think I would equate reactive and CQRS, but reactive (say in the Rx sense) definitely goes for a more action centric persistence than an ORM centric persistence. I did explore only a little bit but I could not fully re conciliate a Rx centric API with the idea of a (extra)-transaction bound persistence context. Ideas welcome. On Fri 2016-04-01 22:53, Vlad Mihalcea wrote: > Just my 2 cents: > > Reactive means many things. From a persistence perspective, reactive > implies CQRS which is exactly the reverse of what Hibernate currently does. > Also, reactive systems are eventually consistent which contradicts > Hibernate's strong consistency guarantees. > > Vlad > > On Fri, Apr 1, 2016 at 10:41 PM, Petar Tahchiev > wrote: > > > Is there any plans for reactive support in Hibernate6? > > > > 2016-04-01 22:07 GMT+03:00 Steve Ebersole : > > > > > I can look with you right after I finish with the hibernate-entitymanager > > > consolidation into hibernate-core. Next week sometime, hopefully > > early... > > > I'll follow up on your other email thread. > > > > > > On Thu, Mar 31, 2016 at 3:06 PM Gail Badner wrote: > > > > > > > I'm not sure what you mean by "ready". My POC is ready for discussion. > > > > > > > > On Thu, Mar 31, 2016 at 12:51 PM, Steve Ebersole > > > > wrote: > > > > > > > >> Is it ready? > > > >> > > > >> On Thu, Mar 31, 2016, 2:28 PM Gail Badner wrote: > > > >> > > > >>> I would like to see OperationContext introduced. > > > >>> > > > >>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole > > > > > >>> wrote: > > > >>> > > > >>>> Oh... One other change I want to propose is better incorporate > > > >>>> MappedSuperclass into the org.hibernate.mapping hierarchy. Koen, > > this > > > >>>> will > > > >>>> affect tooling the most as it would mean changes to those contracts. > > > >>>> > > > >>>> If we are making disruptive changes there, I guess the next logical > > > >>>> question is whether we use that opportunity to make other disruptive > > > >>>> changes that we have been putting off due to disruption. Mainly I > > am > > > >>>> thinking of modeling the org.hibernate.mapping representation of the > > > >>>> domain > > > >>>> hierarchy as more in-line with JPA terms. > > > >>>> > > > >>>> On Thu, Mar 31, 2016 at 7:43 AM Steve Ebersole > > > > > >>>> wrote: > > > >>>> > > > >>>> > Well baseline on Jana 8 would mean app support for many Java 8 > > > >>>> features. > > > >>>> > Currency, optional, etc > > > >>>> > > > > >>>> > On Thu, Mar 31, 2016, 7:38 AM Petar Tahchiev < > > paranoiabla at gmail.com > > > > > > > >>>> > wrote: > > > >>>> > > > > >>>> >> +1 on going java8. I'd also suggest adding support for > > > javax.currency > > > >>>> >> JSR354 > > > >>>> >> > > > >>>> >> 2016-03-31 15:23 GMT+03:00 Vlad Mihalcea < > > mihalcea.vlad at gmail.com > > > >: > > > >>>> >> > > > >>>> >> > Hi, > > > >>>> >> > > > > >>>> >> > It makes sense to unify the core with hem in a single module. > > > >>>> >> > > > > >>>> >> > Currently, the flushing behavior differs if we execute a query > > > >>>> through a > > > >>>> >> > Session or through an EntityManager. > > > >>>> >> > Does it mean that we eliminate those differences as well? > > > >>>> >> > > > > >>>> >> > Vlad > > > >>>> >> > > > > >>>> >> > On Thu, Mar 31, 2016 at 2:57 PM, Steve Ebersole < > > > >>>> steve at hibernate.org> > > > >>>> >> > wrote: > > > >>>> >> > > > > >>>> >> > > We have been having a few side discussions about plans for > > 6.0, > > > >>>> and I > > > >>>> >> > > thought it would be a good idea to consolidate them together. > > > >>>> >> > > > > > >>>> >> > > > > > >>>> >> > > 1. Incorporate the SQM work. Lots of pieces go into this: > > > >>>> >> > > 1. Replacing the interpretation of HQL/JPQL and > > Criteria > > > >>>> >> queries. > > > >>>> >> > > 2. *Possibly* leveraging SQM to deal with entity > > > operations > > > >>>> >> > > (load-by-id, merge, etc). > > > >>>> >> > > 3. Improved Query contracts > > > >>>> >> > > 4. Improved persister contracts (including addition of > > an > > > >>>> >> > "embeddable > > > >>>> >> > > persister"). > > > >>>> >> > > 5. Improved Type contracts > > > >>>> >> > > 2. Extensions to JPA criteria based on SQM work(this is > > > >>>> probably > > > >>>> >> more > > > >>>> >> > on > > > >>>> >> > > ongoing 6.x task) > > > >>>> >> > > 3. Baseline on Java 8 > > > >>>> >> > > > > > >>>> >> > > Is there anything else anyone wants to discuss getting > > > included? > > > >>>> >> > > > > > >>>> >> > > Another one I'd like to discuss is the consolidation of the > > > >>>> >> > hibernate-core > > > >>>> >> > > and hibernate-entitymanager modules into a single module > > > >>>> (possibly > > > >>>> >> > renamed > > > >>>> >> > > hibernate-orm). There are a lot of reasons and benefits to > > > doing > > > >>>> >> this: > > > >>>> >> > > > > > >>>> >> > > 1. A major one would be the consolidation of "type > > systems". > > > >>>> >> > Hibernate > > > >>>> >> > > has org.hibernate.type.Type. JPA defines > > > >>>> javax.persistence.Type. > > > >>>> >> Now > > > >>>> >> > > with > > > >>>> >> > > SQM we have a 3rd type system in play. > > > >>>> >> > > 2. It is also the major hurdle to moving to being able to > > > >>>> fully > > > >>>> >> > replace > > > >>>> >> > > the legacy criteria with JPA criteria. If Session and > > > >>>> >> EntityManager > > > >>>> >> > (as > > > >>>> >> > > well as SessionFactory ad EntiytManagerFactory) were fully > > > >>>> >> integrated > > > >>>> >> > > then > > > >>>> >> > > Session would be able to build/handle JPA criteria > > queries. > > > >>>> >> > > 3. Simplified HEM bootstrapping > > > >>>> >> > > > > > >>>> >> > > > > > >>>> >> > > There are also a few challenges to doing this consolidation > > of > > > >>>> the > > > >>>> >> > > hibernate-core and hibernate-entitymanager modules. The big > > > one > > > >>>> tht > > > >>>> >> > stick > > > >>>> >> > > out in my head is event-listener with different behaviors > > > >>>> between core > > > >>>> >> > and > > > >>>> >> > > hem. > > > >>>> >> > > _______________________________________________ > > > >>>> >> > > 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 > > > >>>> >> > > > > >>>> >> > > > >>>> >> > > > >>>> >> > > > >>>> >> -- > > > >>>> >> 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 > > > >>>> >> > > > >>>> > > > > >>>> _______________________________________________ > > > >>>> 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 > > > > > > > > > > > -- > > 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 > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From sanne at hibernate.org Mon Apr 4 11:36:09 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 4 Apr 2016 16:36:09 +0100 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: <5702780E.8020708@redhat.com> <57027C42.2090709@redhat.com> Message-ID: On 4 April 2016 at 15:48, Steve Ebersole wrote: > So there we go :) > > On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow wrote: >> >> Hmm, just searched through irc history and came up with fixed by >> https://hibernate.atlassian.net/browse/HHH-7552. Nice to see this >> already fixed! ;) Great, so you could fix WildFly 10 to already benefit from it and cleanup the classpath! From steve at hibernate.org Mon Apr 4 11:55:25 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 04 Apr 2016 15:55:25 +0000 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: <5702780E.8020708@redhat.com> <57027C42.2090709@redhat.com> Message-ID: So to me the biggest design question is in regard to exceptions. Where possible I plan on integrating the 2 hierarchies (which probably means the Hibernate exceptions becoming interfaces). In cases where such an integration is not possible we will have to err on the side of preferring the JPA exceptions. Everyone ok with that? On Mon, Apr 4, 2016 at 10:37 AM Sanne Grinovero wrote: > On 4 April 2016 at 15:48, Steve Ebersole wrote: > > So there we go :) > > > > On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow wrote: > >> > >> Hmm, just searched through irc history and came up with fixed by > >> https://hibernate.atlassian.net/browse/HHH-7552. Nice to see this > >> already fixed! ;) > > Great, so you could fix WildFly 10 to already benefit from it and > cleanup the classpath! > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From smarlow at redhat.com Mon Apr 4 12:25:50 2016 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 4 Apr 2016 12:25:50 -0400 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: <5702780E.8020708@redhat.com> <57027C42.2090709@redhat.com> Message-ID: <5702958E.3010002@redhat.com> On 04/04/2016 11:36 AM, Sanne Grinovero wrote: > On 4 April 2016 at 15:48, Steve Ebersole wrote: >> So there we go :) >> >> On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow wrote: >>> >>> Hmm, just searched through irc history and came up with fixed by >>> https://hibernate.atlassian.net/browse/HHH-7552. Nice to see this >>> already fixed! ;) > > Great, so you could fix WildFly 10 to already benefit from it and > cleanup the classpath! > Not sure, I think that we might still need it for starting the Infinispan 2lc. From emmanuel at hibernate.org Mon Apr 4 12:36:55 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 4 Apr 2016 18:36:55 +0200 Subject: [hibernate-dev] 6.0 planning In-Reply-To: References: <5702780E.8020708@redhat.com> <57027C42.2090709@redhat.com> Message-ID: <20160404163655.GK8238@hibernate.org> Yes I think that's reasonable. My gut feeling is that there are only a handful HibernateException subclass really useful when coding an application, breaking the rest is probably fine. On Mon 2016-04-04 15:55, Steve Ebersole wrote: > So to me the biggest design question is in regard to exceptions. Where > possible I plan on integrating the 2 hierarchies (which probably means the > Hibernate exceptions becoming interfaces). In cases where such an > integration is not possible we will have to err on the side of preferring > the JPA exceptions. > > Everyone ok with that? > > > On Mon, Apr 4, 2016 at 10:37 AM Sanne Grinovero wrote: > > > On 4 April 2016 at 15:48, Steve Ebersole wrote: > > > So there we go :) > > > > > > On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow wrote: > > >> > > >> Hmm, just searched through irc history and came up with fixed by > > >> https://hibernate.atlassian.net/browse/HHH-7552. Nice to see this > > >> already fixed! ;) > > > > Great, so you could fix WildFly 10 to already benefit from it and > > cleanup the classpath! > > _______________________________________________ > > 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 Mon Apr 4 14:33:59 2016 From: gbadner at redhat.com (Gail Badner) Date: Mon, 4 Apr 2016 11:33:59 -0700 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Is there is any 5.1-specific content? If so, it needs to be stripped out for 5.0. On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea wrote: > Hi Gail, > > I pushed the 5.1 documentation into the 5,0 branch. > The only thing that's needed now is to modify the release procedure which > I'll send it as a PR. > > We also have to modify the hibernate.org site so that 5.0 references the > same documentation links as 5.1. > > Vlad > > On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea > wrote: > >> The 4.x branches contain the old documentation, the one that was written >> with Hibernate 3 in mind. >> >> The new documentation work was started in 5.0 but we only got it done in >> 5.1, so 5.0 doesn't contain all the additions we made to the new >> documentation. >> >> I can backport it for sure, but I don't know if it won't break something >> during the release phase. >> >> For this purpose, I'm going to split this task in two: >> >> 1. Copy the whole asciidoc User Guide that we wrote from scratch. This >> step will contain a lot of modifications so it will be difficult to review >> it in GitHub probably. But it can be reviewing manually. >> 2. Modify the release procedure to use the new User Guide. This step can >> be reviewed by you and Steve so we make sure we don't break anything. >> >> Vlad >> >> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner wrote: >> >>> I noticed there is some information in 4.2 docs that are not in 5.0. I'm >>> not sure what happened there. >>> >>> Is there info in the 5.1 docs that does not apply to 5.0? If so, is >>> there a way to easily exclude it? >>> >>> I don't know what all is involved in backporting the docs. If it can be >>> done safely and excluding 5.1-specific info, then please go ahead. >>> >>> Thanks! >>> Gail >>> >>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea >> > wrote: >>> >>>> I made the change for 4.2. >>>> >>>> For 5.0, we should switch to the current 5.1 documentation because the >>>> 5.0 User Guide lacks a lot of information. >>>> It requires adding the asciidoc documentation, Gradle configs, and also >>>> change the release procedure to use asciidoc instead of docbook. >>>> >>>> Should we add a new task for this? >>>> >>>> Vlad >>>> >>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>> wrote: >>>> >>>>> Hi Vlad, >>>>> >>>>> Yes, please update the doc for 5.0 and 4.2. >>>>> >>>>> Thanks! >>>>> Gail >>>>> >>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> wrote: >>>>> >>>>>> Hi Gail, >>>>>> >>>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>>> release will publish the updated doc, right? >>>>>> Should the documentation be updated for the 4.x branches too? >>>>>> >>>>>> Vlad >>>>>> >>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole >>>>>> wrote: >>>>>> >>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, however >>>>>>> I would only change it on master. >>>>>>> >>>>>>> For the other branches, if anything, just update the doc. >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>> >>>>>>>> I think this PR is valid: >>>>>>>> >>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>> >>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>> connection >>>>>>>> release mode. >>>>>>>> >>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we state in >>>>>>>> the docs? >>>>>>>> >>>>>>>> Vlad >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mihalcea.vlad at gmail.com Mon Apr 4 14:48:05 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 4 Apr 2016 21:48:05 +0300 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Sure, I'm going to take care of it tomorrow. Vlad On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner wrote: > Is there is any 5.1-specific content? If so, it needs to be stripped out > for 5.0. > > On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea > wrote: > >> Hi Gail, >> >> I pushed the 5.1 documentation into the 5,0 branch. >> The only thing that's needed now is to modify the release procedure which >> I'll send it as a PR. >> >> We also have to modify the hibernate.org site so that 5.0 references the >> same documentation links as 5.1. >> >> Vlad >> >> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea >> wrote: >> >>> The 4.x branches contain the old documentation, the one that was written >>> with Hibernate 3 in mind. >>> >>> The new documentation work was started in 5.0 but we only got it done in >>> 5.1, so 5.0 doesn't contain all the additions we made to the new >>> documentation. >>> >>> I can backport it for sure, but I don't know if it won't break something >>> during the release phase. >>> >>> For this purpose, I'm going to split this task in two: >>> >>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. This >>> step will contain a lot of modifications so it will be difficult to review >>> it in GitHub probably. But it can be reviewing manually. >>> 2. Modify the release procedure to use the new User Guide. This step can >>> be reviewed by you and Steve so we make sure we don't break anything. >>> >>> Vlad >>> >>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner wrote: >>> >>>> I noticed there is some information in 4.2 docs that are not in 5.0. >>>> I'm not sure what happened there. >>>> >>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, is >>>> there a way to easily exclude it? >>>> >>>> I don't know what all is involved in backporting the docs. If it can be >>>> done safely and excluding 5.1-specific info, then please go ahead. >>>> >>>> Thanks! >>>> Gail >>>> >>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>> mihalcea.vlad at gmail.com> wrote: >>>> >>>>> I made the change for 4.2. >>>>> >>>>> For 5.0, we should switch to the current 5.1 documentation because the >>>>> 5.0 User Guide lacks a lot of information. >>>>> It requires adding the asciidoc documentation, Gradle configs, and >>>>> also change the release procedure to use asciidoc instead of docbook. >>>>> >>>>> Should we add a new task for this? >>>>> >>>>> Vlad >>>>> >>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>> wrote: >>>>> >>>>>> Hi Vlad, >>>>>> >>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>> >>>>>> Thanks! >>>>>> Gail >>>>>> >>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> Hi Gail, >>>>>>> >>>>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>>>> release will publish the updated doc, right? >>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole >>>>>> > wrote: >>>>>>> >>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, however >>>>>>>> I would only change it on master. >>>>>>>> >>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>> >>>>>>>>> I think this PR is valid: >>>>>>>>> >>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>> >>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>> connection >>>>>>>>> release mode. >>>>>>>>> >>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we state in >>>>>>>>> the docs? >>>>>>>>> >>>>>>>>> Vlad >>>>>>>>> _______________________________________________ >>>>>>>>> hibernate-dev mailing list >>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From gbadner at redhat.com Mon Apr 4 16:02:07 2016 From: gbadner at redhat.com (Gail Badner) Date: Mon, 4 Apr 2016 13:02:07 -0700 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Thanks much! On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea wrote: > Sure, > > I'm going to take care of it tomorrow. > > Vlad > > On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner wrote: > >> Is there is any 5.1-specific content? If so, it needs to be stripped out >> for 5.0. >> >> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea >> wrote: >> >>> Hi Gail, >>> >>> I pushed the 5.1 documentation into the 5,0 branch. >>> The only thing that's needed now is to modify the release procedure >>> which I'll send it as a PR. >>> >>> We also have to modify the hibernate.org site so that 5.0 references >>> the same documentation links as 5.1. >>> >>> Vlad >>> >>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea >>> wrote: >>> >>>> The 4.x branches contain the old documentation, the one that was >>>> written with Hibernate 3 in mind. >>>> >>>> The new documentation work was started in 5.0 but we only got it done >>>> in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>> documentation. >>>> >>>> I can backport it for sure, but I don't know if it won't break >>>> something during the release phase. >>>> >>>> For this purpose, I'm going to split this task in two: >>>> >>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. This >>>> step will contain a lot of modifications so it will be difficult to review >>>> it in GitHub probably. But it can be reviewing manually. >>>> 2. Modify the release procedure to use the new User Guide. This step >>>> can be reviewed by you and Steve so we make sure we don't break anything. >>>> >>>> Vlad >>>> >>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>> wrote: >>>> >>>>> I noticed there is some information in 4.2 docs that are not in 5.0. >>>>> I'm not sure what happened there. >>>>> >>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, is >>>>> there a way to easily exclude it? >>>>> >>>>> I don't know what all is involved in backporting the docs. If it can >>>>> be done safely and excluding 5.1-specific info, then please go ahead. >>>>> >>>>> Thanks! >>>>> Gail >>>>> >>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> wrote: >>>>> >>>>>> I made the change for 4.2. >>>>>> >>>>>> For 5.0, we should switch to the current 5.1 documentation because >>>>>> the 5.0 User Guide lacks a lot of information. >>>>>> It requires adding the asciidoc documentation, Gradle configs, and >>>>>> also change the release procedure to use asciidoc instead of docbook. >>>>>> >>>>>> Should we add a new task for this? >>>>>> >>>>>> Vlad >>>>>> >>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>>> wrote: >>>>>> >>>>>>> Hi Vlad, >>>>>>> >>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>> >>>>>>> Thanks! >>>>>>> Gail >>>>>>> >>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>> >>>>>>>> Hi Gail, >>>>>>>> >>>>>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>>>>> release will publish the updated doc, right? >>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>> >>>>>>>> Vlad >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>> steve at hibernate.org> wrote: >>>>>>>> >>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>> however I would only change it on master. >>>>>>>>> >>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I think this PR is valid: >>>>>>>>>> >>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>> >>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>> connection >>>>>>>>>> release mode. >>>>>>>>>> >>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we state >>>>>>>>>> in the docs? >>>>>>>>>> >>>>>>>>>> Vlad >>>>>>>>>> _______________________________________________ >>>>>>>>>> hibernate-dev mailing list >>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mihalcea.vlad at gmail.com Tue Apr 5 01:47:03 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 5 Apr 2016 08:47:03 +0300 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Hi Gail, I removed the 5.1 references on the new User Guide. You can check it out and see how you like it: > cd documentation > gradle rUG Let me know what you think. Vlad On Mon, Apr 4, 2016 at 11:02 PM, Gail Badner wrote: > Thanks much! > > On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea > wrote: > >> Sure, >> >> I'm going to take care of it tomorrow. >> >> Vlad >> >> On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner wrote: >> >>> Is there is any 5.1-specific content? If so, it needs to be stripped out >>> for 5.0. >>> >>> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea >>> wrote: >>> >>>> Hi Gail, >>>> >>>> I pushed the 5.1 documentation into the 5,0 branch. >>>> The only thing that's needed now is to modify the release procedure >>>> which I'll send it as a PR. >>>> >>>> We also have to modify the hibernate.org site so that 5.0 references >>>> the same documentation links as 5.1. >>>> >>>> Vlad >>>> >>>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea >>> > wrote: >>>> >>>>> The 4.x branches contain the old documentation, the one that was >>>>> written with Hibernate 3 in mind. >>>>> >>>>> The new documentation work was started in 5.0 but we only got it done >>>>> in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>>> documentation. >>>>> >>>>> I can backport it for sure, but I don't know if it won't break >>>>> something during the release phase. >>>>> >>>>> For this purpose, I'm going to split this task in two: >>>>> >>>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. This >>>>> step will contain a lot of modifications so it will be difficult to review >>>>> it in GitHub probably. But it can be reviewing manually. >>>>> 2. Modify the release procedure to use the new User Guide. This step >>>>> can be reviewed by you and Steve so we make sure we don't break anything. >>>>> >>>>> Vlad >>>>> >>>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>>> wrote: >>>>> >>>>>> I noticed there is some information in 4.2 docs that are not in 5.0. >>>>>> I'm not sure what happened there. >>>>>> >>>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, is >>>>>> there a way to easily exclude it? >>>>>> >>>>>> I don't know what all is involved in backporting the docs. If it can >>>>>> be done safely and excluding 5.1-specific info, then please go ahead. >>>>>> >>>>>> Thanks! >>>>>> Gail >>>>>> >>>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> I made the change for 4.2. >>>>>>> >>>>>>> For 5.0, we should switch to the current 5.1 documentation because >>>>>>> the 5.0 User Guide lacks a lot of information. >>>>>>> It requires adding the asciidoc documentation, Gradle configs, and >>>>>>> also change the release procedure to use asciidoc instead of docbook. >>>>>>> >>>>>>> Should we add a new task for this? >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Vlad, >>>>>>>> >>>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Gail >>>>>>>> >>>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Gail, >>>>>>>>> >>>>>>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>>>>>> release will publish the updated doc, right? >>>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>>> >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>> >>>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>>> however I would only change it on master. >>>>>>>>>> >>>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I think this PR is valid: >>>>>>>>>>> >>>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>>> >>>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>>> connection >>>>>>>>>>> release mode. >>>>>>>>>>> >>>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we state >>>>>>>>>>> in the docs? >>>>>>>>>>> >>>>>>>>>>> Vlad >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From gunnar at hibernate.org Tue Apr 5 02:27:33 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 5 Apr 2016 08:27:33 +0200 Subject: [hibernate-dev] README.adoc of hibernate.org In-Reply-To: <20160404152238.GE8238@hibernate.org> References: <20160404152238.GE8238@hibernate.org> Message-ID: It should be possible to make it work rendered *and* when previewed on GitHub by defining a suffix for links if you are in the "GitHub environment": ifdef::env-github[:outfilesuffix: .adoc] See https://github.com/asciidoctor/asciidoctor/issues/417 and https://github.com/opendevise/asciidoc-samples/blob/master/sandbox.adoc. --Gunnar 2016-04-04 17:22 GMT+02:00 Emmanuel Bernard : > I liked the idea of the README as a proper webpage. But I can live > without it and I don't have strong grounded arguments for it. > > On Mon 2016-04-04 10:52, Sanne Grinovero wrote: > > It sounds good to me in principle, but I vaguely remember we > > intentionally added that README to the website for some reason. > > > > I don't remember what the reason was exactly though, so my doubt is > > that we're actually linking to that URL from somewhere. > > Let's not rush it and wait for several more opinions :) > > > > On 4 April 2016 at 09:16, Guillaume Smet > wrote: > > > Hi, > > > > > > While setting up my environment for hibernate.org and in.relation.to, > I > > > noticed that there are broken links in the README... when we read it on > > > GitHub (the .adoc extension is missing). It works OK when we read it > from > > > the website using http://hibernate.org/README/. > > > > > > I expect most people to use GitHub to read this document and the other > ones > > > related (docker/README.adoc, survival-guide.adoc). > > > > > > I was thinking about adding these files to .awestruct_ignore so that we > > > don't generate website pages for them and fix them for GitHub browsing. > > > > > > Anyone against it? > > > > > > -- > > > Guillaume > > > _______________________________________________ > > > 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 gunnar at hibernate.org Tue Apr 5 02:30:42 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 5 Apr 2016 08:30:42 +0200 Subject: [hibernate-dev] Search: Lucene 6 is coming In-Reply-To: <20160404152348.GF8238@hibernate.org> References: <20160404152348.GF8238@hibernate.org> Message-ID: Apart from migration concerns, is anything in Lucene 6 allowing us to provide new exciting functionality to users? 2016-04-04 17:23 GMT+02:00 Emmanuel Bernard : > +1 > > On Mon 2016-04-04 14:02, Sanne Grinovero wrote: > > The Apache Lucene team is voting on candidate releases for Lucene 6.0.0. > > > > As usual we'll refrain from making API changes in a minor release, but > > we should start to sometimes try building against Lucene 6 to make > > sure to use APIs which will live longer, if there's choice. > > > > The most notable change is an entirely new strategy to handle numeric > > fields; including overhauled APIs. > > > > I guess Hibernate Search 6 will probably want to align with Lucene 6 > > and Hibernate ORM 6; only problem I see with that is I hope people > > won't get used to these all being nicely aligned as it's probably not > > sustainable as a rule.. just luck so far (although we managed that > > with all of the 3.x, 4.x, 5.x and now 6 series of Hibernate Search!). > > > > Both Lucene 6 and ORM 6 will require Java 8. > > > > I'll update the Search roadmap to reflect this aim, as I assume there > > won't be concerns? > > > > 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 sanne at hibernate.org Tue Apr 5 05:58:54 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 5 Apr 2016 10:58:54 +0100 Subject: [hibernate-dev] Search: Lucene 6 is coming In-Reply-To: References: <20160404152348.GF8238@hibernate.org> Message-ID: On 5 April 2016 at 07:30, Gunnar Morling wrote: > Apart from migration concerns, is anything in Lucene 6 allowing us to > provide new exciting functionality to users? The best one seems to be the new encoding technique for numerics - also mentioned as breaking API - is fabulously more efficient: smaller in terms of index space, much faster to query and also somewhat more efficient at indexing time: faster and less intensive on the JVM heap. - https://www.elastic.co/blog/lucene-points-6.0 Not least it supports multi-dimension numeric fields, so stuff like Spatial get a double win. The Query API now include Guillaume's patches to make our life easier to transform them to ES, and they've been working more on making queries immutable. Filters were not removed but are based on the immutable queries, it seems all like sensible cleanup to me. The Lucene mailing list is talking already about what should be included in Lucene 7 so I'm having the impression of a bit of a more aggressive version increase pace.. Nobody can tell of course: maybe it will take the somewhat usual amount of time but it seems possible the project is ramping up on dev speed. Thanks, Sanne > > 2016-04-04 17:23 GMT+02:00 Emmanuel Bernard : >> >> +1 >> >> On Mon 2016-04-04 14:02, Sanne Grinovero wrote: >> > The Apache Lucene team is voting on candidate releases for Lucene 6.0.0. >> > >> > As usual we'll refrain from making API changes in a minor release, but >> > we should start to sometimes try building against Lucene 6 to make >> > sure to use APIs which will live longer, if there's choice. >> > >> > The most notable change is an entirely new strategy to handle numeric >> > fields; including overhauled APIs. >> > >> > I guess Hibernate Search 6 will probably want to align with Lucene 6 >> > and Hibernate ORM 6; only problem I see with that is I hope people >> > won't get used to these all being nicely aligned as it's probably not >> > sustainable as a rule.. just luck so far (although we managed that >> > with all of the 3.x, 4.x, 5.x and now 6 series of Hibernate Search!). >> > >> > Both Lucene 6 and ORM 6 will require Java 8. >> > >> > I'll update the Search roadmap to reflect this aim, as I assume there >> > won't be concerns? >> > >> > 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 mihalcea.vlad at gmail.com Tue Apr 5 09:11:59 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 5 Apr 2016 16:11:59 +0300 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly Message-ID: Hi, While reviewing the PR for this issue: https://hibernate.atlassian.net/browse/HHH-10649 I realized that the ReadWrite cache concurrency strategy has a flaw that permits "read uncommitted" anomalies. The RW cache concurrency strategy guards any modifications with Lock entries, as explained in this post that I wrote some time ago: http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ Every time we update/delete an entry, a Lock is put in the cache under the entity key, and, this way, "read uncommitted" anomalies should be prevented. The problem comes when entries are evicted either explicitly: session.getSessionFactory().getCache().evictEntity( CacheableItem.class, item1.getId() ); or implicitly: session.refresh( item1 ); During eviction, the 2PL will remove the Lock entry, and if the user attempts to load the entity anew (in the same transaction that has modified the entity but which is not committed yet), an uncommitted change could be propagated to the 2PL. This issue is replicated by the PR associated to this Jira issue, and I also replicated it with manual eviction and entity loading. To fix it, the RW cache concurrency strategy should not delete entries from 2PL upon eviction, but instead it should turn them in Lock entries. For the evict method, this is not really a problem, but evictAll would imply taking all entries and replacing them with Locks, and that might not perform very well in a distributed-cache scenario. Ideally, lock entries would be stored separately than actual cached value entries, and this problem would be fixed in a much cleaner fashion. Let me know what you think about this. Vlad From sanne at hibernate.org Tue Apr 5 09:30:17 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 5 Apr 2016 14:30:17 +0100 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: References: Message-ID: On 5 April 2016 at 14:11, Vlad Mihalcea wrote: > Hi, > > While reviewing the PR for this issue: > > https://hibernate.atlassian.net/browse/HHH-10649 > > I realized that the ReadWrite cache concurrency strategy has a flaw that > permits "read uncommitted" anomalies. > The RW cache concurrency strategy guards any modifications with Lock > entries, as explained in this post that I wrote some time ago: > > http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ > > Every time we update/delete an entry, a Lock is put in the cache under the > entity key, and, this way, "read uncommitted" anomalies should be prevented. > > The problem comes when entries are evicted either explicitly: > > session.getSessionFactory().getCache().evictEntity( CacheableItem.class, > item1.getId() ); > > or implicitly: > > session.refresh( item1 ); Good catch! I think this is caused as we generally don't expect the evict operation to be controlled explicitly. In my personal experience, I would use the evictAll method to nuke the cache state after some significant operation, like restoring a backup.. and no other Session would have been opened in the meantime. I never used an explicit single-shot evict so I can't say what the use case would be. But of course you're right that it might be used differently, or at least such a limitation should be clear. > > During eviction, the 2PL will remove the Lock entry, and if the user > attempts to load the entity anew (in the same transaction that has modified > the entity but which is not committed yet), an uncommitted change could be > propagated to the 2PL. > > This issue is replicated by the PR associated to this Jira issue, and I > also replicated it with manual eviction and entity loading. > > To fix it, the RW cache concurrency strategy should not delete entries from > 2PL upon eviction, but instead it should turn them in Lock entries. I'm not sure I understood this part. Shouldn't it rather be allowed to delete everything, except any existing locks? Then rather than turn the remaining locks into locks, it would be enough to leave them. > For the evict method, this is not really a problem, but evictAll would > imply taking all entries and replacing them with Locks, and that might not > perform very well in a distributed-cache scenario. > > Ideally, lock entries would be stored separately than actual cached value > entries, and this problem would be fixed in a much cleaner fashion. I'd leave this as a detail to the Cache implementation, some might be able to perform some operation more efficiently. Probably a good idea to clarify this expectation on the javadocs of the SPI methods. Thanks, Sanne > > Let me know what you think about this. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From mihalcea.vlad at gmail.com Tue Apr 5 10:13:59 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 5 Apr 2016 17:13:59 +0300 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: References: Message-ID: Hi, I'd definitely fix it for the refresh operation, which does an implicit cache eviction too. In this case, the proposed PR solution is fine since it simply locks the entry right after it is evicted from the cache and releases the lock after the transaction is ended. This way, we won't push an uncommitted entity into 2PL during the two-phase loading phase that is triggered by the refresh operation. For sessionFactory.getCache.evictEntity/evictCollection, if there is a current Session going on, we could propagate a CacheEvictEvent/CollectionCacheEvictEvent which can apply the lock on that particular entity/collection, and we release it right after the current transaction is ended, similar to what refresh should do as well. For every other use case, like evictAll/evictRegion, we should just document the behavior. I saw that Radim has added such a warning for Infinispan in the new User Guide: read-write mode is supported on non-transactional distributed/replicated > caches, however, eviction should not be used in this configuration. Use of > eviction can lead to consistency issues. Unfortunately, the EhCache documentation makes a wrong assumption: read-write - Caches data that is sometimes updated while maintaining the > semantics of ?read committed? isolation level. Vlad On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero wrote: > On 5 April 2016 at 14:11, Vlad Mihalcea wrote: > > Hi, > > > > While reviewing the PR for this issue: > > > > https://hibernate.atlassian.net/browse/HHH-10649 > > > > I realized that the ReadWrite cache concurrency strategy has a flaw that > > permits "read uncommitted" anomalies. > > The RW cache concurrency strategy guards any modifications with Lock > > entries, as explained in this post that I wrote some time ago: > > > > > http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ > > > > Every time we update/delete an entry, a Lock is put in the cache under > the > > entity key, and, this way, "read uncommitted" anomalies should be > prevented. > > > > The problem comes when entries are evicted either explicitly: > > > > session.getSessionFactory().getCache().evictEntity( CacheableItem.class, > > item1.getId() ); > > > > or implicitly: > > > > session.refresh( item1 ); > > Good catch! > > I think this is caused as we generally don't expect the evict > operation to be controlled explicitly. > In my personal experience, I would use the evictAll method to nuke the > cache state after some significant operation, like restoring a > backup.. and no other Session would have been opened in the meantime. > I never used an explicit single-shot evict so I can't say what the use > case would be. > > But of course you're right that it might be used differently, or at > least such a limitation should be clear. > > > > > During eviction, the 2PL will remove the Lock entry, and if the user > > attempts to load the entity anew (in the same transaction that has > modified > > the entity but which is not committed yet), an uncommitted change could > be > > propagated to the 2PL. > > > > This issue is replicated by the PR associated to this Jira issue, and I > > also replicated it with manual eviction and entity loading. > > > > To fix it, the RW cache concurrency strategy should not delete entries > from > > 2PL upon eviction, but instead it should turn them in Lock entries. > > I'm not sure I understood this part. Shouldn't it rather be allowed to > delete everything, except any existing locks? > Then rather than turn the remaining locks into locks, it would be > enough to leave them. > > > For the evict method, this is not really a problem, but evictAll would > > imply taking all entries and replacing them with Locks, and that might > not > > perform very well in a distributed-cache scenario. > > > > Ideally, lock entries would be stored separately than actual cached value > > entries, and this problem would be fixed in a much cleaner fashion. > > I'd leave this as a detail to the Cache implementation, some might be > able to perform some operation more efficiently. > Probably a good idea to clarify this expectation on the javadocs of > the SPI methods. > > Thanks, > Sanne > > > > > > Let me know what you think about this. > > > > Vlad > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From postmaster at lists.jboss.org Tue Apr 5 11:20:50 2016 From: postmaster at lists.jboss.org (The Post Office) Date: Tue, 5 Apr 2016 23:20:50 +0800 Subject: [hibernate-dev] Returned mail: Data format error Message-ID: <201604051520.u35FKiTf025383@lists01.dmz-a.mwc.hst.phx2.redhat.com> ??{U?????`EiQ?K??R o~?2?B??]?U?eb?? 1???[?U??Tp{0:?z?,?b?mf??Q ]?E 3??4??????Y,O??b[????????d:?jK???6?lDh;)??N??D>E??U CU???e????`?K91?? DU?r????L?6{O???2???1D?%??3>?H(z?i ?E^?O?a? O?h????Z???' Ydq?0??D??U???????t :?G??(??$??]?6?j ?????wK????R???TQ"v???rV{i??-$??X?H{??H???Q???ID??>}q????7|?7???Py??B?"?????"?}b?W{(??&\j_x0??>w?i?B????v???V?;i?w??%?n?h?znq?F???Z??V?????s??n?Pb???Tn6~KJ?Q??[??t??????1C????????????????????????Q????.?z??? ?U?N???Z?Mt?&cO?? ??]A?$d??B?{?w??V6???V^?v??TG~? )bh} ?????E??B"????Hv?d?2???????f?~T??R4n???????pJ???uN????s?????E`?????x?]R?]??u????$?95?Z?i)*??!?9m2????*??|;???}Q?oM# n?I7?5$??_? ?N???b.l?V}p???????9?ft?1??,? ?m?o$R??????N???4Z?k?{???Gb&?H?v?gS??2?2??kz??0w#!???f?!T?5?xaI?L?>F6???????#8??r?[?3?\?ZF??`??QKi??L??r???????{??W??_??i]G???D?????9?????CN???"j??7`?????G??*??????pK4??7??? ???Y??&??^!??*/???U??GF5?R??\?????&?(?FA??_p^???&L.p???p?Z??CJ,A? O?,U???????'????gMg?]kR? ?x0??O??{Z??z?x?&c:??v/?n??M??`?9??????/px?/yXi????&?;Q??8c?????S?????.? ?E??0C??x???J?:??!?W?%I? ??8??mt?O???k?t!U?O?X????EF?du?????>?L????L"???%"?d:_???}>i??NND?*?b??7????p^?t?^?E6?}r?E??????1i?)??WX;vT????kq?W?Yh?X??gz????w?C}??{7J?O??????vazY???U5?? 2??g{??????????. ? ?}S????USV?????!????A??Ri?~e?ztV?????u???/???Z??.???????"P?ld[? References: Message-ID: Hi Vlad, It looks great! If it's ready to go, I'll push it to https://docs.jboss.org/hibernate/orm/5.0/ and update the link on hibernate.org. Thanks! Gail On Mon, Apr 4, 2016 at 10:47 PM, Vlad Mihalcea wrote: > Hi Gail, > > I removed the 5.1 references on the new User Guide. > You can check it out and see how you like it: > > > cd documentation > > gradle rUG > > Let me know what you think. > > Vlad > > On Mon, Apr 4, 2016 at 11:02 PM, Gail Badner wrote: > >> Thanks much! >> >> On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea >> wrote: >> >>> Sure, >>> >>> I'm going to take care of it tomorrow. >>> >>> Vlad >>> >>> On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner wrote: >>> >>>> Is there is any 5.1-specific content? If so, it needs to be stripped >>>> out for 5.0. >>>> >>>> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea >>>> wrote: >>>> >>>>> Hi Gail, >>>>> >>>>> I pushed the 5.1 documentation into the 5,0 branch. >>>>> The only thing that's needed now is to modify the release procedure >>>>> which I'll send it as a PR. >>>>> >>>>> We also have to modify the hibernate.org site so that 5.0 references >>>>> the same documentation links as 5.1. >>>>> >>>>> Vlad >>>>> >>>>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> wrote: >>>>> >>>>>> The 4.x branches contain the old documentation, the one that was >>>>>> written with Hibernate 3 in mind. >>>>>> >>>>>> The new documentation work was started in 5.0 but we only got it done >>>>>> in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>>>> documentation. >>>>>> >>>>>> I can backport it for sure, but I don't know if it won't break >>>>>> something during the release phase. >>>>>> >>>>>> For this purpose, I'm going to split this task in two: >>>>>> >>>>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. >>>>>> This step will contain a lot of modifications so it will be difficult to >>>>>> review it in GitHub probably. But it can be reviewing manually. >>>>>> 2. Modify the release procedure to use the new User Guide. This step >>>>>> can be reviewed by you and Steve so we make sure we don't break anything. >>>>>> >>>>>> Vlad >>>>>> >>>>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>>>> wrote: >>>>>> >>>>>>> I noticed there is some information in 4.2 docs that are not in 5.0. >>>>>>> I'm not sure what happened there. >>>>>>> >>>>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, is >>>>>>> there a way to easily exclude it? >>>>>>> >>>>>>> I don't know what all is involved in backporting the docs. If it can >>>>>>> be done safely and excluding 5.1-specific info, then please go ahead. >>>>>>> >>>>>>> Thanks! >>>>>>> Gail >>>>>>> >>>>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>> >>>>>>>> I made the change for 4.2. >>>>>>>> >>>>>>>> For 5.0, we should switch to the current 5.1 documentation because >>>>>>>> the 5.0 User Guide lacks a lot of information. >>>>>>>> It requires adding the asciidoc documentation, Gradle configs, and >>>>>>>> also change the release procedure to use asciidoc instead of docbook. >>>>>>>> >>>>>>>> Should we add a new task for this? >>>>>>>> >>>>>>>> Vlad >>>>>>>> >>>>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Vlad, >>>>>>>>> >>>>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Gail >>>>>>>>> >>>>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Gail, >>>>>>>>>> >>>>>>>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>>>>>>> release will publish the updated doc, right? >>>>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>>>> >>>>>>>>>> Vlad >>>>>>>>>> >>>>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>> >>>>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>>>> however I would only change it on master. >>>>>>>>>>> >>>>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I think this PR is valid: >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>>>> >>>>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>>>> connection >>>>>>>>>>>> release mode. >>>>>>>>>>>> >>>>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we state >>>>>>>>>>>> in the docs? >>>>>>>>>>>> >>>>>>>>>>>> Vlad >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mihalcea.vlad at gmail.com Tue Apr 5 15:00:38 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 5 Apr 2016 22:00:38 +0300 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Thanks for the feedback, Fo the moment, the 5.0 docs are ready, and we can push the integration further, as you suggested. There will be other updates that we'll do to improve the docs (Envers, Spatial, Portability topics), and I'll make sure to split the 5.1-related things from changes that apply to 5.0. This way, we can maintain the 5.0 docs much more easily. Vlad On Tue, Apr 5, 2016 at 9:36 PM, Gail Badner wrote: > Hi Vlad, > > It looks great! If it's ready to go, I'll push it to > https://docs.jboss.org/hibernate/orm/5.0/ and update the link on > hibernate.org. > > Thanks! > Gail > > On Mon, Apr 4, 2016 at 10:47 PM, Vlad Mihalcea > wrote: > >> Hi Gail, >> >> I removed the 5.1 references on the new User Guide. >> You can check it out and see how you like it: >> >> > cd documentation >> > gradle rUG >> >> Let me know what you think. >> >> Vlad >> >> On Mon, Apr 4, 2016 at 11:02 PM, Gail Badner wrote: >> >>> Thanks much! >>> >>> On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea >>> wrote: >>> >>>> Sure, >>>> >>>> I'm going to take care of it tomorrow. >>>> >>>> Vlad >>>> >>>> On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner wrote: >>>> >>>>> Is there is any 5.1-specific content? If so, it needs to be stripped >>>>> out for 5.0. >>>>> >>>>> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea >>>> > wrote: >>>>> >>>>>> Hi Gail, >>>>>> >>>>>> I pushed the 5.1 documentation into the 5,0 branch. >>>>>> The only thing that's needed now is to modify the release procedure >>>>>> which I'll send it as a PR. >>>>>> >>>>>> We also have to modify the hibernate.org site so that 5.0 references >>>>>> the same documentation links as 5.1. >>>>>> >>>>>> Vlad >>>>>> >>>>>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> The 4.x branches contain the old documentation, the one that was >>>>>>> written with Hibernate 3 in mind. >>>>>>> >>>>>>> The new documentation work was started in 5.0 but we only got it >>>>>>> done in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>>>>> documentation. >>>>>>> >>>>>>> I can backport it for sure, but I don't know if it won't break >>>>>>> something during the release phase. >>>>>>> >>>>>>> For this purpose, I'm going to split this task in two: >>>>>>> >>>>>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. >>>>>>> This step will contain a lot of modifications so it will be difficult to >>>>>>> review it in GitHub probably. But it can be reviewing manually. >>>>>>> 2. Modify the release procedure to use the new User Guide. This step >>>>>>> can be reviewed by you and Steve so we make sure we don't break anything. >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>>>>> wrote: >>>>>>> >>>>>>>> I noticed there is some information in 4.2 docs that are not in >>>>>>>> 5.0. I'm not sure what happened there. >>>>>>>> >>>>>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, is >>>>>>>> there a way to easily exclude it? >>>>>>>> >>>>>>>> I don't know what all is involved in backporting the docs. If it >>>>>>>> can be done safely and excluding 5.1-specific info, then please go ahead. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Gail >>>>>>>> >>>>>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>> >>>>>>>>> I made the change for 4.2. >>>>>>>>> >>>>>>>>> For 5.0, we should switch to the current 5.1 documentation because >>>>>>>>> the 5.0 User Guide lacks a lot of information. >>>>>>>>> It requires adding the asciidoc documentation, Gradle configs, and >>>>>>>>> also change the release procedure to use asciidoc instead of docbook. >>>>>>>>> >>>>>>>>> Should we add a new task for this? >>>>>>>>> >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Vlad, >>>>>>>>>> >>>>>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Gail >>>>>>>>>> >>>>>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Gail, >>>>>>>>>>> >>>>>>>>>>> For the 5.0 branch, I could update the doc for this issue. A new >>>>>>>>>>> release will publish the updated doc, right? >>>>>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>>>>> >>>>>>>>>>> Vlad >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>>>>> however I would only change it on master. >>>>>>>>>>>> >>>>>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I think this PR is valid: >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>>>>> >>>>>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>>>>> connection >>>>>>>>>>>>> release mode. >>>>>>>>>>>>> >>>>>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we >>>>>>>>>>>>> state in the docs? >>>>>>>>>>>>> >>>>>>>>>>>>> Vlad >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From steve at hibernate.org Tue Apr 5 15:00:33 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 05 Apr 2016 19:00:33 +0000 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: References: Message-ID: The contract for SessionFactory-level even says that it operates outside of the confines of an Session-based locking of the cached data. So it works this way by design. We can question the design decision, but that's a different discussion. On Tue, Apr 5, 2016 at 9:38 AM Vlad Mihalcea wrote: > Hi, > > I'd definitely fix it for the refresh operation, which does an implicit > cache eviction too. > In this case, the proposed PR solution is fine since it simply locks the > entry right after it is evicted from the cache and releases the lock after > the transaction is ended. > This way, we won't push an uncommitted entity into 2PL during the two-phase > loading phase that is triggered by the refresh operation. > > For sessionFactory.getCache.evictEntity/evictCollection, if there is a > current Session going on, we could propagate a > CacheEvictEvent/CollectionCacheEvictEvent which can apply the lock on that > particular entity/collection, and we release it right after the current > transaction is ended, similar to what refresh should do as well. > > For every other use case, like evictAll/evictRegion, we should just > document the behavior. > > I saw that Radim has added such a warning for Infinispan in the new User > Guide: > > read-write mode is supported on non-transactional distributed/replicated > > caches, however, eviction should not be used in this configuration. Use > of > > eviction can lead to consistency issues. > > > Unfortunately, the EhCache documentation > < > http://www.ehcache.org/documentation/2.8/integrations/hibernate.html#read-write > > > makes a wrong assumption: > > read-write - Caches data that is sometimes updated while maintaining the > > semantics of ?read committed? isolation level. > > > Vlad > > On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero > wrote: > > > On 5 April 2016 at 14:11, Vlad Mihalcea wrote: > > > Hi, > > > > > > While reviewing the PR for this issue: > > > > > > https://hibernate.atlassian.net/browse/HHH-10649 > > > > > > I realized that the ReadWrite cache concurrency strategy has a flaw > that > > > permits "read uncommitted" anomalies. > > > The RW cache concurrency strategy guards any modifications with Lock > > > entries, as explained in this post that I wrote some time ago: > > > > > > > > > http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ > > > > > > Every time we update/delete an entry, a Lock is put in the cache under > > the > > > entity key, and, this way, "read uncommitted" anomalies should be > > prevented. > > > > > > The problem comes when entries are evicted either explicitly: > > > > > > session.getSessionFactory().getCache().evictEntity( > CacheableItem.class, > > > item1.getId() ); > > > > > > or implicitly: > > > > > > session.refresh( item1 ); > > > > Good catch! > > > > I think this is caused as we generally don't expect the evict > > operation to be controlled explicitly. > > In my personal experience, I would use the evictAll method to nuke the > > cache state after some significant operation, like restoring a > > backup.. and no other Session would have been opened in the meantime. > > I never used an explicit single-shot evict so I can't say what the use > > case would be. > > > > But of course you're right that it might be used differently, or at > > least such a limitation should be clear. > > > > > > > > During eviction, the 2PL will remove the Lock entry, and if the user > > > attempts to load the entity anew (in the same transaction that has > > modified > > > the entity but which is not committed yet), an uncommitted change could > > be > > > propagated to the 2PL. > > > > > > This issue is replicated by the PR associated to this Jira issue, and I > > > also replicated it with manual eviction and entity loading. > > > > > > To fix it, the RW cache concurrency strategy should not delete entries > > from > > > 2PL upon eviction, but instead it should turn them in Lock entries. > > > > I'm not sure I understood this part. Shouldn't it rather be allowed to > > delete everything, except any existing locks? > > Then rather than turn the remaining locks into locks, it would be > > enough to leave them. > > > > > For the evict method, this is not really a problem, but evictAll would > > > imply taking all entries and replacing them with Locks, and that might > > not > > > perform very well in a distributed-cache scenario. > > > > > > Ideally, lock entries would be stored separately than actual cached > value > > > entries, and this problem would be fixed in a much cleaner fashion. > > > > I'd leave this as a detail to the Cache implementation, some might be > > able to perform some operation more efficiently. > > Probably a good idea to clarify this expectation on the javadocs of > > the SPI methods. > > > > Thanks, > > Sanne > > > > > > > > > > Let me know what you think about this. > > > > > > Vlad > > > _______________________________________________ > > > 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 mihalcea.vlad at gmail.com Tue Apr 5 15:08:22 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 5 Apr 2016 22:08:22 +0300 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: References: Message-ID: That's exactly what I mean too. I think we can improve it a little bit when the evict is forced while being on running Session. But that's not in the scope of the original issue which stays as is. I'll add a new Jira issue with a test case, and a design change proposal that we can discuss when we have some spare time. Vlad On Tue, Apr 5, 2016 at 10:00 PM, Steve Ebersole wrote: > The contract for SessionFactory-level even says that it operates outside > of the confines of an Session-based locking of the cached data. So it > works this way by design. We can question the design decision, but that's > a different discussion. > > On Tue, Apr 5, 2016 at 9:38 AM Vlad Mihalcea > wrote: > >> Hi, >> >> I'd definitely fix it for the refresh operation, which does an implicit >> cache eviction too. >> In this case, the proposed PR solution is fine since it simply locks the >> entry right after it is evicted from the cache and releases the lock after >> the transaction is ended. >> This way, we won't push an uncommitted entity into 2PL during the >> two-phase >> loading phase that is triggered by the refresh operation. >> >> For sessionFactory.getCache.evictEntity/evictCollection, if there is a >> current Session going on, we could propagate a >> CacheEvictEvent/CollectionCacheEvictEvent which can apply the lock on that >> particular entity/collection, and we release it right after the current >> transaction is ended, similar to what refresh should do as well. >> >> For every other use case, like evictAll/evictRegion, we should just >> document the behavior. >> >> I saw that Radim has added such a warning for Infinispan in the new User >> Guide: >> >> read-write mode is supported on non-transactional distributed/replicated >> > caches, however, eviction should not be used in this configuration. Use >> of >> > eviction can lead to consistency issues. >> >> >> Unfortunately, the EhCache documentation >> < >> http://www.ehcache.org/documentation/2.8/integrations/hibernate.html#read-write >> > >> >> makes a wrong assumption: >> >> read-write - Caches data that is sometimes updated while maintaining the >> > semantics of ?read committed? isolation level. >> >> >> Vlad >> >> On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero >> wrote: >> >> > On 5 April 2016 at 14:11, Vlad Mihalcea >> wrote: >> > > Hi, >> > > >> > > While reviewing the PR for this issue: >> > > >> > > https://hibernate.atlassian.net/browse/HHH-10649 >> > > >> > > I realized that the ReadWrite cache concurrency strategy has a flaw >> that >> > > permits "read uncommitted" anomalies. >> > > The RW cache concurrency strategy guards any modifications with Lock >> > > entries, as explained in this post that I wrote some time ago: >> > > >> > > >> > >> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ >> > > >> > > Every time we update/delete an entry, a Lock is put in the cache under >> > the >> > > entity key, and, this way, "read uncommitted" anomalies should be >> > prevented. >> > > >> > > The problem comes when entries are evicted either explicitly: >> > > >> > > session.getSessionFactory().getCache().evictEntity( >> CacheableItem.class, >> > > item1.getId() ); >> > > >> > > or implicitly: >> > > >> > > session.refresh( item1 ); >> > >> > Good catch! >> > >> > I think this is caused as we generally don't expect the evict >> > operation to be controlled explicitly. >> > In my personal experience, I would use the evictAll method to nuke the >> > cache state after some significant operation, like restoring a >> > backup.. and no other Session would have been opened in the meantime. >> > I never used an explicit single-shot evict so I can't say what the use >> > case would be. >> > >> > But of course you're right that it might be used differently, or at >> > least such a limitation should be clear. >> > >> > > >> > > During eviction, the 2PL will remove the Lock entry, and if the user >> > > attempts to load the entity anew (in the same transaction that has >> > modified >> > > the entity but which is not committed yet), an uncommitted change >> could >> > be >> > > propagated to the 2PL. >> > > >> > > This issue is replicated by the PR associated to this Jira issue, and >> I >> > > also replicated it with manual eviction and entity loading. >> > > >> > > To fix it, the RW cache concurrency strategy should not delete entries >> > from >> > > 2PL upon eviction, but instead it should turn them in Lock entries. >> > >> > I'm not sure I understood this part. Shouldn't it rather be allowed to >> > delete everything, except any existing locks? >> > Then rather than turn the remaining locks into locks, it would be >> > enough to leave them. >> > >> > > For the evict method, this is not really a problem, but evictAll would >> > > imply taking all entries and replacing them with Locks, and that might >> > not >> > > perform very well in a distributed-cache scenario. >> > > >> > > Ideally, lock entries would be stored separately than actual cached >> value >> > > entries, and this problem would be fixed in a much cleaner fashion. >> > >> > I'd leave this as a detail to the Cache implementation, some might be >> > able to perform some operation more efficiently. >> > Probably a good idea to clarify this expectation on the javadocs of >> > the SPI methods. >> > >> > Thanks, >> > Sanne >> > >> > >> > > >> > > Let me know what you think about this. >> > > >> > > Vlad >> > > _______________________________________________ >> > > 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 Apr 5 18:36:39 2016 From: gbadner at redhat.com (Gail Badner) Date: Tue, 5 Apr 2016 15:36:39 -0700 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Hi Vlad, I've pushed the documentation to http://docs.jboss.org/hibernate/orm/5.0/userguide/html_single/Hibernate_User_Guide.html and updated the link on hibernate.org. The old user guide is still out there. I've asked for it to be removed. The new user guide looks great! Thanks for your help on this. Gail On Tue, Apr 5, 2016 at 12:00 PM, Vlad Mihalcea wrote: > Thanks for the feedback, > > Fo the moment, the 5.0 docs are ready, and we can push the integration > further, as you suggested. > > There will be other updates that we'll do to improve the docs (Envers, > Spatial, Portability topics), and I'll make sure to split the 5.1-related > things from changes that apply to 5.0. > This way, we can maintain the 5.0 docs much more easily. > > Vlad > > On Tue, Apr 5, 2016 at 9:36 PM, Gail Badner wrote: > >> Hi Vlad, >> >> It looks great! If it's ready to go, I'll push it to >> https://docs.jboss.org/hibernate/orm/5.0/ and update the link on >> hibernate.org. >> >> Thanks! >> Gail >> >> On Mon, Apr 4, 2016 at 10:47 PM, Vlad Mihalcea >> wrote: >> >>> Hi Gail, >>> >>> I removed the 5.1 references on the new User Guide. >>> You can check it out and see how you like it: >>> >>> > cd documentation >>> > gradle rUG >>> >>> Let me know what you think. >>> >>> Vlad >>> >>> On Mon, Apr 4, 2016 at 11:02 PM, Gail Badner wrote: >>> >>>> Thanks much! >>>> >>>> On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea >>> > wrote: >>>> >>>>> Sure, >>>>> >>>>> I'm going to take care of it tomorrow. >>>>> >>>>> Vlad >>>>> >>>>> On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner >>>>> wrote: >>>>> >>>>>> Is there is any 5.1-specific content? If so, it needs to be stripped >>>>>> out for 5.0. >>>>>> >>>>>> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> Hi Gail, >>>>>>> >>>>>>> I pushed the 5.1 documentation into the 5,0 branch. >>>>>>> The only thing that's needed now is to modify the release procedure >>>>>>> which I'll send it as a PR. >>>>>>> >>>>>>> We also have to modify the hibernate.org site so that 5.0 >>>>>>> references the same documentation links as 5.1. >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>> >>>>>>>> The 4.x branches contain the old documentation, the one that was >>>>>>>> written with Hibernate 3 in mind. >>>>>>>> >>>>>>>> The new documentation work was started in 5.0 but we only got it >>>>>>>> done in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>>>>>> documentation. >>>>>>>> >>>>>>>> I can backport it for sure, but I don't know if it won't break >>>>>>>> something during the release phase. >>>>>>>> >>>>>>>> For this purpose, I'm going to split this task in two: >>>>>>>> >>>>>>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. >>>>>>>> This step will contain a lot of modifications so it will be difficult to >>>>>>>> review it in GitHub probably. But it can be reviewing manually. >>>>>>>> 2. Modify the release procedure to use the new User Guide. This >>>>>>>> step can be reviewed by you and Steve so we make sure we don't break >>>>>>>> anything. >>>>>>>> >>>>>>>> Vlad >>>>>>>> >>>>>>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I noticed there is some information in 4.2 docs that are not in >>>>>>>>> 5.0. I'm not sure what happened there. >>>>>>>>> >>>>>>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, >>>>>>>>> is there a way to easily exclude it? >>>>>>>>> >>>>>>>>> I don't know what all is involved in backporting the docs. If it >>>>>>>>> can be done safely and excluding 5.1-specific info, then please go ahead. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Gail >>>>>>>>> >>>>>>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> I made the change for 4.2. >>>>>>>>>> >>>>>>>>>> For 5.0, we should switch to the current 5.1 documentation >>>>>>>>>> because the 5.0 User Guide lacks a lot of information. >>>>>>>>>> It requires adding the asciidoc documentation, Gradle configs, >>>>>>>>>> and also change the release procedure to use asciidoc instead of docbook. >>>>>>>>>> >>>>>>>>>> Should we add a new task for this? >>>>>>>>>> >>>>>>>>>> Vlad >>>>>>>>>> >>>>>>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Vlad, >>>>>>>>>>> >>>>>>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Gail >>>>>>>>>>> >>>>>>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Gail, >>>>>>>>>>>> >>>>>>>>>>>> For the 5.0 branch, I could update the doc for this issue. A >>>>>>>>>>>> new release will publish the updated doc, right? >>>>>>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>>>>>> >>>>>>>>>>>> Vlad >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>>>>>> however I would only change it on master. >>>>>>>>>>>>> >>>>>>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I think this PR is valid: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>>>>>> connection >>>>>>>>>>>>>> release mode. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we >>>>>>>>>>>>>> state in the docs? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Vlad >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mihalcea.vlad at gmail.com Tue Apr 5 23:51:23 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 6 Apr 2016 06:51:23 +0300 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Hi Gail, I'm glad you like the new User Guide. Related to the old one, I think we could leave it hosted on docs.jboss.org because some users might have bookmarked it, and deleting it might get them angry. Vlad On Wed, Apr 6, 2016 at 1:36 AM, Gail Badner wrote: > Hi Vlad, > > I've pushed the documentation to > http://docs.jboss.org/hibernate/orm/5.0/userguide/html_single/Hibernate_User_Guide.html > and updated the link on hibernate.org. > > The old user guide is still out there. I've asked for it to be removed. > > The new user guide looks great! Thanks for your help on this. > Gail > > On Tue, Apr 5, 2016 at 12:00 PM, Vlad Mihalcea > wrote: > >> Thanks for the feedback, >> >> Fo the moment, the 5.0 docs are ready, and we can push the integration >> further, as you suggested. >> >> There will be other updates that we'll do to improve the docs (Envers, >> Spatial, Portability topics), and I'll make sure to split the 5.1-related >> things from changes that apply to 5.0. >> This way, we can maintain the 5.0 docs much more easily. >> >> Vlad >> >> On Tue, Apr 5, 2016 at 9:36 PM, Gail Badner wrote: >> >>> Hi Vlad, >>> >>> It looks great! If it's ready to go, I'll push it to >>> https://docs.jboss.org/hibernate/orm/5.0/ and update the link on >>> hibernate.org. >>> >>> Thanks! >>> Gail >>> >>> On Mon, Apr 4, 2016 at 10:47 PM, Vlad Mihalcea >>> wrote: >>> >>>> Hi Gail, >>>> >>>> I removed the 5.1 references on the new User Guide. >>>> You can check it out and see how you like it: >>>> >>>> > cd documentation >>>> > gradle rUG >>>> >>>> Let me know what you think. >>>> >>>> Vlad >>>> >>>> On Mon, Apr 4, 2016 at 11:02 PM, Gail Badner >>>> wrote: >>>> >>>>> Thanks much! >>>>> >>>>> On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea < >>>>> mihalcea.vlad at gmail.com> wrote: >>>>> >>>>>> Sure, >>>>>> >>>>>> I'm going to take care of it tomorrow. >>>>>> >>>>>> Vlad >>>>>> >>>>>> On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner >>>>>> wrote: >>>>>> >>>>>>> Is there is any 5.1-specific content? If so, it needs to be stripped >>>>>>> out for 5.0. >>>>>>> >>>>>>> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea < >>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>> >>>>>>>> Hi Gail, >>>>>>>> >>>>>>>> I pushed the 5.1 documentation into the 5,0 branch. >>>>>>>> The only thing that's needed now is to modify the release procedure >>>>>>>> which I'll send it as a PR. >>>>>>>> >>>>>>>> We also have to modify the hibernate.org site so that 5.0 >>>>>>>> references the same documentation links as 5.1. >>>>>>>> >>>>>>>> Vlad >>>>>>>> >>>>>>>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>> >>>>>>>>> The 4.x branches contain the old documentation, the one that was >>>>>>>>> written with Hibernate 3 in mind. >>>>>>>>> >>>>>>>>> The new documentation work was started in 5.0 but we only got it >>>>>>>>> done in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>>>>>>> documentation. >>>>>>>>> >>>>>>>>> I can backport it for sure, but I don't know if it won't break >>>>>>>>> something during the release phase. >>>>>>>>> >>>>>>>>> For this purpose, I'm going to split this task in two: >>>>>>>>> >>>>>>>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. >>>>>>>>> This step will contain a lot of modifications so it will be difficult to >>>>>>>>> review it in GitHub probably. But it can be reviewing manually. >>>>>>>>> 2. Modify the release procedure to use the new User Guide. This >>>>>>>>> step can be reviewed by you and Steve so we make sure we don't break >>>>>>>>> anything. >>>>>>>>> >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I noticed there is some information in 4.2 docs that are not in >>>>>>>>>> 5.0. I'm not sure what happened there. >>>>>>>>>> >>>>>>>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, >>>>>>>>>> is there a way to easily exclude it? >>>>>>>>>> >>>>>>>>>> I don't know what all is involved in backporting the docs. If it >>>>>>>>>> can be done safely and excluding 5.1-specific info, then please go ahead. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Gail >>>>>>>>>> >>>>>>>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> I made the change for 4.2. >>>>>>>>>>> >>>>>>>>>>> For 5.0, we should switch to the current 5.1 documentation >>>>>>>>>>> because the 5.0 User Guide lacks a lot of information. >>>>>>>>>>> It requires adding the asciidoc documentation, Gradle configs, >>>>>>>>>>> and also change the release procedure to use asciidoc instead of docbook. >>>>>>>>>>> >>>>>>>>>>> Should we add a new task for this? >>>>>>>>>>> >>>>>>>>>>> Vlad >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Vlad, >>>>>>>>>>>> >>>>>>>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> Gail >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Gail, >>>>>>>>>>>>> >>>>>>>>>>>>> For the 5.0 branch, I could update the doc for this issue. A >>>>>>>>>>>>> new release will publish the updated doc, right? >>>>>>>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>>>>>>> >>>>>>>>>>>>> Vlad >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back to >>>>>>>>>>>>>> ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>>>>>>> however I would only change it on master. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think this PR is valid: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>>>>>>> connection >>>>>>>>>>>>>>> release mode. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we >>>>>>>>>>>>>>> state in the docs? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Vlad >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From rvansa at redhat.com Wed Apr 6 05:58:57 2016 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 6 Apr 2016 11:58:57 +0200 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: References: Message-ID: <5704DDE1.1030702@redhat.com> On 04/05/2016 04:13 PM, Vlad Mihalcea wrote: > Hi, > > I'd definitely fix it for the refresh operation, which does an implicit > cache eviction too. > In this case, the proposed PR solution is fine since it simply locks the > entry right after it is evicted from the cache and releases the lock after > the transaction is ended. > This way, we won't push an uncommitted entity into 2PL during the two-phase > loading phase that is triggered by the refresh operation. > > For sessionFactory.getCache.evictEntity/evictCollection, if there is a > current Session going on, we could propagate a > CacheEvictEvent/CollectionCacheEvictEvent which can apply the lock on that > particular entity/collection, and we release it right after the current > transaction is ended, similar to what refresh should do as well. > > For every other use case, like evictAll/evictRegion, we should just > document the behavior. > > I saw that Radim has added such a warning for Infinispan in the new User > Guide: > > read-write mode is supported on non-transactional distributed/replicated >> caches, however, eviction should not be used in this configuration. Use of >> eviction can lead to consistency issues. This is a different matter; in Infinispan 2LC impl you store locks and entries either in two different caches (the entries cache is invalidation, locks is local), or in single cache (replicated/distributed). As we don't want to lose locks randomly, and eviction picks entries unpredictably, its use is discouraged. I think that this issue does not apply to Infinispan with the invalidation configuration, since evict/evictAll does not remove any locks, and the lock blocks further updates (including putFromLoads) to the entry in cache until the transaction commits. In case of replicated/distributed cache, it seems that the evict is ignored after update, but evictAll is not (that would qualify as a bug) - so after evictAll you could observe the uncommitted read. Nevertheless I would have to test this. Radim > > Unfortunately, the EhCache documentation > > makes a wrong assumption: > > read-write - Caches data that is sometimes updated while maintaining the >> semantics of ?read committed? isolation level. > > Vlad > > On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero wrote: > >> On 5 April 2016 at 14:11, Vlad Mihalcea wrote: >>> Hi, >>> >>> While reviewing the PR for this issue: >>> >>> https://hibernate.atlassian.net/browse/HHH-10649 >>> >>> I realized that the ReadWrite cache concurrency strategy has a flaw that >>> permits "read uncommitted" anomalies. >>> The RW cache concurrency strategy guards any modifications with Lock >>> entries, as explained in this post that I wrote some time ago: >>> >>> >> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ >>> Every time we update/delete an entry, a Lock is put in the cache under >> the >>> entity key, and, this way, "read uncommitted" anomalies should be >> prevented. >>> The problem comes when entries are evicted either explicitly: >>> >>> session.getSessionFactory().getCache().evictEntity( CacheableItem.class, >>> item1.getId() ); >>> >>> or implicitly: >>> >>> session.refresh( item1 ); >> Good catch! >> >> I think this is caused as we generally don't expect the evict >> operation to be controlled explicitly. >> In my personal experience, I would use the evictAll method to nuke the >> cache state after some significant operation, like restoring a >> backup.. and no other Session would have been opened in the meantime. >> I never used an explicit single-shot evict so I can't say what the use >> case would be. >> >> But of course you're right that it might be used differently, or at >> least such a limitation should be clear. >> >>> During eviction, the 2PL will remove the Lock entry, and if the user >>> attempts to load the entity anew (in the same transaction that has modified >>> the entity but which is not committed yet), an uncommitted change could be >>> propagated to the 2PL. >>> >>> This issue is replicated by the PR associated to this Jira issue, and I >>> also replicated it with manual eviction and entity loading. >>> >>> To fix it, the RW cache concurrency strategy should not delete entries from >>> 2PL upon eviction, but instead it should turn them in Lock entries. >> I'm not sure I understood this part. Shouldn't it rather be allowed to >> delete everything, except any existing locks? >> Then rather than turn the remaining locks into locks, it would be >> enough to leave them. >> >>> For the evict method, this is not really a problem, but evictAll would >>> imply taking all entries and replacing them with Locks, and that might not >>> perform very well in a distributed-cache scenario. >>> >>> Ideally, lock entries would be stored separately than actual cached value >>> entries, and this problem would be fixed in a much cleaner fashion. >> I'd leave this as a detail to the Cache implementation, some might be >> able to perform some operation more efficiently. >> Probably a good idea to clarify this expectation on the javadocs of >> the SPI methods. >> >> Thanks, >> Sanne >> >> >>> Let me know what you think about this. >>> >>> Vlad >>> _______________________________________________ >>> 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 -- Radim Vansa JBoss Performance Team From mihalcea.vlad at gmail.com Wed Apr 6 06:17:32 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 6 Apr 2016 13:17:32 +0300 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: <5704DDE1.1030702@redhat.com> References: <5704DDE1.1030702@redhat.com> Message-ID: Hi Radim, I pushed this fix on master and 5.1, and I managed to add an EHCache where the same behavior was replicated as well: https://github.com/hibernate/hibernate-orm/commit/cbdab9d87f05b4255c7930a32fe995f87f0f3e0b For Infinispan, I think it's better if you can investigate if this is an issue or if the change does not break anything either (all Infinispan tests ran fine, so hopefully this should not be the case). Thanks, Vlad On Wed, Apr 6, 2016 at 12:58 PM, Radim Vansa wrote: > On 04/05/2016 04:13 PM, Vlad Mihalcea wrote: > > Hi, > > > > I'd definitely fix it for the refresh operation, which does an implicit > > cache eviction too. > > In this case, the proposed PR solution is fine since it simply locks the > > entry right after it is evicted from the cache and releases the lock > after > > the transaction is ended. > > This way, we won't push an uncommitted entity into 2PL during the > two-phase > > loading phase that is triggered by the refresh operation. > > > > For sessionFactory.getCache.evictEntity/evictCollection, if there is a > > current Session going on, we could propagate a > > CacheEvictEvent/CollectionCacheEvictEvent which can apply the lock on > that > > particular entity/collection, and we release it right after the current > > transaction is ended, similar to what refresh should do as well. > > > > For every other use case, like evictAll/evictRegion, we should just > > document the behavior. > > > > I saw that Radim has added such a warning for Infinispan in the new User > > Guide: > > > > read-write mode is supported on non-transactional distributed/replicated > >> caches, however, eviction should not be used in this configuration. Use > of > >> eviction can lead to consistency issues. > > This is a different matter; in Infinispan 2LC impl you store locks and > entries either in two different caches (the entries cache is > invalidation, locks is local), or in single cache > (replicated/distributed). As we don't want to lose locks randomly, and > eviction picks entries unpredictably, its use is discouraged. > > I think that this issue does not apply to Infinispan with the > invalidation configuration, since evict/evictAll does not remove any > locks, and the lock blocks further updates (including putFromLoads) to > the entry in cache until the transaction commits. In case of > replicated/distributed cache, it seems that the evict is ignored after > update, but evictAll is not (that would qualify as a bug) - so after > evictAll you could observe the uncommitted read. Nevertheless I would > have to test this. > > Radim > > > > > Unfortunately, the EhCache documentation > > < > http://www.ehcache.org/documentation/2.8/integrations/hibernate.html#read-write > > > > makes a wrong assumption: > > > > read-write - Caches data that is sometimes updated while maintaining the > >> semantics of ?read committed? isolation level. > > > > Vlad > > > > On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero > wrote: > > > >> On 5 April 2016 at 14:11, Vlad Mihalcea > wrote: > >>> Hi, > >>> > >>> While reviewing the PR for this issue: > >>> > >>> https://hibernate.atlassian.net/browse/HHH-10649 > >>> > >>> I realized that the ReadWrite cache concurrency strategy has a flaw > that > >>> permits "read uncommitted" anomalies. > >>> The RW cache concurrency strategy guards any modifications with Lock > >>> entries, as explained in this post that I wrote some time ago: > >>> > >>> > >> > http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ > >>> Every time we update/delete an entry, a Lock is put in the cache under > >> the > >>> entity key, and, this way, "read uncommitted" anomalies should be > >> prevented. > >>> The problem comes when entries are evicted either explicitly: > >>> > >>> session.getSessionFactory().getCache().evictEntity( > CacheableItem.class, > >>> item1.getId() ); > >>> > >>> or implicitly: > >>> > >>> session.refresh( item1 ); > >> Good catch! > >> > >> I think this is caused as we generally don't expect the evict > >> operation to be controlled explicitly. > >> In my personal experience, I would use the evictAll method to nuke the > >> cache state after some significant operation, like restoring a > >> backup.. and no other Session would have been opened in the meantime. > >> I never used an explicit single-shot evict so I can't say what the use > >> case would be. > >> > >> But of course you're right that it might be used differently, or at > >> least such a limitation should be clear. > >> > >>> During eviction, the 2PL will remove the Lock entry, and if the user > >>> attempts to load the entity anew (in the same transaction that has > modified > >>> the entity but which is not committed yet), an uncommitted change > could be > >>> propagated to the 2PL. > >>> > >>> This issue is replicated by the PR associated to this Jira issue, and I > >>> also replicated it with manual eviction and entity loading. > >>> > >>> To fix it, the RW cache concurrency strategy should not delete entries > from > >>> 2PL upon eviction, but instead it should turn them in Lock entries. > >> I'm not sure I understood this part. Shouldn't it rather be allowed to > >> delete everything, except any existing locks? > >> Then rather than turn the remaining locks into locks, it would be > >> enough to leave them. > >> > >>> For the evict method, this is not really a problem, but evictAll would > >>> imply taking all entries and replacing them with Locks, and that might > not > >>> perform very well in a distributed-cache scenario. > >>> > >>> Ideally, lock entries would be stored separately than actual cached > value > >>> entries, and this problem would be fixed in a much cleaner fashion. > >> I'd leave this as a detail to the Cache implementation, some might be > >> able to perform some operation more efficiently. > >> Probably a good idea to clarify this expectation on the javadocs of > >> the SPI methods. > >> > >> Thanks, > >> Sanne > >> > >> > >>> Let me know what you think about this. > >>> > >>> Vlad > >>> _______________________________________________ > >>> 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 > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From rvansa at redhat.com Wed Apr 6 06:37:24 2016 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 6 Apr 2016 12:37:24 +0200 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: <5704DDE1.1030702@redhat.com> References: <5704DDE1.1030702@redhat.com> Message-ID: <5704E6E4.2090808@redhat.com> On 04/06/2016 11:58 AM, Radim Vansa wrote: > On 04/05/2016 04:13 PM, Vlad Mihalcea wrote: >> Hi, >> >> I'd definitely fix it for the refresh operation, which does an implicit >> cache eviction too. >> In this case, the proposed PR solution is fine since it simply locks the >> entry right after it is evicted from the cache and releases the lock after >> the transaction is ended. >> This way, we won't push an uncommitted entity into 2PL during the two-phase >> loading phase that is triggered by the refresh operation. >> >> For sessionFactory.getCache.evictEntity/evictCollection, if there is a >> current Session going on, we could propagate a >> CacheEvictEvent/CollectionCacheEvictEvent which can apply the lock on that >> particular entity/collection, and we release it right after the current >> transaction is ended, similar to what refresh should do as well. >> >> For every other use case, like evictAll/evictRegion, we should just >> document the behavior. >> >> I saw that Radim has added such a warning for Infinispan in the new User >> Guide: >> >> read-write mode is supported on non-transactional distributed/replicated >>> caches, however, eviction should not be used in this configuration. Use of >>> eviction can lead to consistency issues. > This is a different matter; in Infinispan 2LC impl you store locks and > entries either in two different caches (the entries cache is > invalidation, locks is local), or in single cache > (replicated/distributed). As we don't want to lose locks randomly, and > eviction picks entries unpredictably, its use is discouraged. ... it's use is discouraged in the repl/dist mode as you can't allow eviction on entries but prohibit on locks with both of these in single cache. > > I think that this issue does not apply to Infinispan with the > invalidation configuration, since evict/evictAll does not remove any > locks, and the lock blocks further updates (including putFromLoads) to > the entry in cache until the transaction commits. In case of > replicated/distributed cache, it seems that the evict is ignored after > update, but evictAll is not (that would qualify as a bug) - so after > evictAll you could observe the uncommitted read. Nevertheless I would > have to test this. > > Radim > >> Unfortunately, the EhCache documentation >> >> makes a wrong assumption: >> >> read-write - Caches data that is sometimes updated while maintaining the >>> semantics of ?read committed? isolation level. >> Vlad >> >> On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero wrote: >> >>> On 5 April 2016 at 14:11, Vlad Mihalcea wrote: >>>> Hi, >>>> >>>> While reviewing the PR for this issue: >>>> >>>> https://hibernate.atlassian.net/browse/HHH-10649 >>>> >>>> I realized that the ReadWrite cache concurrency strategy has a flaw that >>>> permits "read uncommitted" anomalies. >>>> The RW cache concurrency strategy guards any modifications with Lock >>>> entries, as explained in this post that I wrote some time ago: >>>> >>>> >>> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ >>>> Every time we update/delete an entry, a Lock is put in the cache under >>> the >>>> entity key, and, this way, "read uncommitted" anomalies should be >>> prevented. >>>> The problem comes when entries are evicted either explicitly: >>>> >>>> session.getSessionFactory().getCache().evictEntity( CacheableItem.class, >>>> item1.getId() ); >>>> >>>> or implicitly: >>>> >>>> session.refresh( item1 ); >>> Good catch! >>> >>> I think this is caused as we generally don't expect the evict >>> operation to be controlled explicitly. >>> In my personal experience, I would use the evictAll method to nuke the >>> cache state after some significant operation, like restoring a >>> backup.. and no other Session would have been opened in the meantime. >>> I never used an explicit single-shot evict so I can't say what the use >>> case would be. >>> >>> But of course you're right that it might be used differently, or at >>> least such a limitation should be clear. >>> >>>> During eviction, the 2PL will remove the Lock entry, and if the user >>>> attempts to load the entity anew (in the same transaction that has modified >>>> the entity but which is not committed yet), an uncommitted change could be >>>> propagated to the 2PL. >>>> >>>> This issue is replicated by the PR associated to this Jira issue, and I >>>> also replicated it with manual eviction and entity loading. >>>> >>>> To fix it, the RW cache concurrency strategy should not delete entries from >>>> 2PL upon eviction, but instead it should turn them in Lock entries. >>> I'm not sure I understood this part. Shouldn't it rather be allowed to >>> delete everything, except any existing locks? >>> Then rather than turn the remaining locks into locks, it would be >>> enough to leave them. >>> >>>> For the evict method, this is not really a problem, but evictAll would >>>> imply taking all entries and replacing them with Locks, and that might not >>>> perform very well in a distributed-cache scenario. >>>> >>>> Ideally, lock entries would be stored separately than actual cached value >>>> entries, and this problem would be fixed in a much cleaner fashion. >>> I'd leave this as a detail to the Cache implementation, some might be >>> able to perform some operation more efficiently. >>> Probably a good idea to clarify this expectation on the javadocs of >>> the SPI methods. >>> >>> Thanks, >>> Sanne >>> >>> >>>> Let me know what you think about this. >>>> >>>> Vlad >>>> _______________________________________________ >>>> 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 > -- Radim Vansa JBoss Performance Team From sanne at hibernate.org Wed Apr 6 06:43:24 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 6 Apr 2016 11:43:24 +0100 Subject: [hibernate-dev] OGM: convergence for a 5.0.0.Final ? Message-ID: Hi, I was hoping that even w/o a specific OGM sprint we would soon (next week?) be able to re-spin the CR1 with minor effort as the 5.0.0.Final. Among tasks scheduled for 5.0.0.Final: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%205.0.0.Final%20ORDER%20BY%20status%20ASC%2C%20assignee%20ASC I'm assigned two documentation related issues; these seem important enough to stay flagged for 5.0.0.Final and should be doable. OGM-888 also relates documentation and should be doable. Could we agree on moving out the other open issues? Personally I think the only one needing some attention still is: - OGM-817 Adapt to changes around auto-quoting Thanks, Sanne From rvansa at redhat.com Wed Apr 6 07:02:39 2016 From: rvansa at redhat.com (Radim Vansa) Date: Wed, 6 Apr 2016 13:02:39 +0200 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: References: <5704DDE1.1030702@redhat.com> Message-ID: <5704ECCF.9030602@redhat.com> Hi Vlad, I think that this change is safe (it uses only the supported flow of 2LC SPI calls), though it introduces a bit more overhead for the refresh. FYI, besides unit tests, there's CorrectnessTestCase [1] - I've used this one to find out most of flaws in Infinispan 2LC impl. Could be worth a try running this on EHCache, too. I've noticed some of the added tests explicitly use H2. Hibernate uses 1.3 for the testsuite - I was running tests with both 1.3 and 1.4 and the behaviour can differ a lot, since 1.4 can lock separate rows and 1.3 locks just whole tables (pardon me if I recall that incorrectly) - this can lead to different timing, and eventually to deadlock/test failure. Just to let you know that I had problems with these. Radim [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java On 04/06/2016 12:17 PM, Vlad Mihalcea wrote: > Hi Radim, > > I pushed this fix on master and 5.1, and I managed to add an EHCache > where the same behavior was replicated as well: > > https://github.com/hibernate/hibernate-orm/commit/cbdab9d87f05b4255c7930a32fe995f87f0f3e0b > > For Infinispan, I think it's better if you can investigate if this is > an issue or if the change does not break anything either (all > Infinispan tests ran fine, so hopefully this should not be the case). > > Thanks, > Vlad > > On Wed, Apr 6, 2016 at 12:58 PM, Radim Vansa > wrote: > > On 04/05/2016 04:13 PM, Vlad Mihalcea wrote: > > Hi, > > > > I'd definitely fix it for the refresh operation, which does an > implicit > > cache eviction too. > > In this case, the proposed PR solution is fine since it simply > locks the > > entry right after it is evicted from the cache and releases the > lock after > > the transaction is ended. > > This way, we won't push an uncommitted entity into 2PL during > the two-phase > > loading phase that is triggered by the refresh operation. > > > > For sessionFactory.getCache.evictEntity/evictCollection, if > there is a > > current Session going on, we could propagate a > > CacheEvictEvent/CollectionCacheEvictEvent which can apply the > lock on that > > particular entity/collection, and we release it right after the > current > > transaction is ended, similar to what refresh should do as well. > > > > For every other use case, like evictAll/evictRegion, we should just > > document the behavior. > > > > I saw that Radim has added such a warning for Infinispan in the > new User > > Guide: > > > > read-write mode is supported on non-transactional > distributed/replicated > >> caches, however, eviction should not be used in this > configuration. Use of > >> eviction can lead to consistency issues. > > This is a different matter; in Infinispan 2LC impl you store locks and > entries either in two different caches (the entries cache is > invalidation, locks is local), or in single cache > (replicated/distributed). As we don't want to lose locks randomly, and > eviction picks entries unpredictably, its use is discouraged. > > I think that this issue does not apply to Infinispan with the > invalidation configuration, since evict/evictAll does not remove any > locks, and the lock blocks further updates (including putFromLoads) to > the entry in cache until the transaction commits. In case of > replicated/distributed cache, it seems that the evict is ignored after > update, but evictAll is not (that would qualify as a bug) - so after > evictAll you could observe the uncommitted read. Nevertheless I would > have to test this. > > Radim > > > > > Unfortunately, the EhCache documentation > > > > > makes a wrong assumption: > > > > read-write - Caches data that is sometimes updated while > maintaining the > >> semantics of ?read committed? isolation level. > > > > Vlad > > > > On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero > > wrote: > > > >> On 5 April 2016 at 14:11, Vlad Mihalcea > > wrote: > >>> Hi, > >>> > >>> While reviewing the PR for this issue: > >>> > >>> https://hibernate.atlassian.net/browse/HHH-10649 > >>> > >>> I realized that the ReadWrite cache concurrency strategy has a > flaw that > >>> permits "read uncommitted" anomalies. > >>> The RW cache concurrency strategy guards any modifications > with Lock > >>> entries, as explained in this post that I wrote some time ago: > >>> > >>> > >> > http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ > >>> Every time we update/delete an entry, a Lock is put in the > cache under > >> the > >>> entity key, and, this way, "read uncommitted" anomalies should be > >> prevented. > >>> The problem comes when entries are evicted either explicitly: > >>> > >>> session.getSessionFactory().getCache().evictEntity( > CacheableItem.class, > >>> item1.getId() ); > >>> > >>> or implicitly: > >>> > >>> session.refresh( item1 ); > >> Good catch! > >> > >> I think this is caused as we generally don't expect the evict > >> operation to be controlled explicitly. > >> In my personal experience, I would use the evictAll method to > nuke the > >> cache state after some significant operation, like restoring a > >> backup.. and no other Session would have been opened in the > meantime. > >> I never used an explicit single-shot evict so I can't say what > the use > >> case would be. > >> > >> But of course you're right that it might be used differently, or at > >> least such a limitation should be clear. > >> > >>> During eviction, the 2PL will remove the Lock entry, and if > the user > >>> attempts to load the entity anew (in the same transaction that > has modified > >>> the entity but which is not committed yet), an uncommitted > change could be > >>> propagated to the 2PL. > >>> > >>> This issue is replicated by the PR associated to this Jira > issue, and I > >>> also replicated it with manual eviction and entity loading. > >>> > >>> To fix it, the RW cache concurrency strategy should not delete > entries from > >>> 2PL upon eviction, but instead it should turn them in Lock > entries. > >> I'm not sure I understood this part. Shouldn't it rather be > allowed to > >> delete everything, except any existing locks? > >> Then rather than turn the remaining locks into locks, it would be > >> enough to leave them. > >> > >>> For the evict method, this is not really a problem, but > evictAll would > >>> imply taking all entries and replacing them with Locks, and > that might not > >>> perform very well in a distributed-cache scenario. > >>> > >>> Ideally, lock entries would be stored separately than actual > cached value > >>> entries, and this problem would be fixed in a much cleaner > fashion. > >> I'd leave this as a detail to the Cache implementation, some > might be > >> able to perform some operation more efficiently. > >> Probably a good idea to clarify this expectation on the javadocs of > >> the SPI methods. > >> > >> Thanks, > >> Sanne > >> > >> > >>> Let me know what you think about this. > >>> > >>> Vlad > >>> _______________________________________________ > >>> 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 > > > -- > Radim Vansa > > JBoss Performance Team > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- Radim Vansa JBoss Performance Team From mihalcea.vlad at gmail.com Wed Apr 6 08:24:37 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 6 Apr 2016 15:24:37 +0300 Subject: [hibernate-dev] ReadWrite 2LC "read uncommitted" data anomaly In-Reply-To: <5704ECCF.9030602@redhat.com> References: <5704DDE1.1030702@redhat.com> <5704ECCF.9030602@redhat.com> Message-ID: Hi Radim, I'll have to port the CorrectnessTesCase to EhCache too. The Refresh test case uses H2 explicitly because I wanted to make sure that we always run this test on an MVCC DB (the test sets the MVCC flag in the connection URL). If the underlying DB uses 2PL, the test will halt. The test can, therefore, run on Oracle, Postgres, and InnoDB, but it will fail for SQL Server and in-memory DBs that are not explicitly configured to use MVCC. Vlad On Wed, Apr 6, 2016 at 2:02 PM, Radim Vansa wrote: > Hi Vlad, > > I think that this change is safe (it uses only the supported flow of 2LC > SPI calls), though it introduces a bit more overhead for the refresh. > > FYI, besides unit tests, there's CorrectnessTestCase [1] - I've used this > one to find out most of flaws in Infinispan 2LC impl. Could be worth a try > running this on EHCache, too. > > I've noticed some of the added tests explicitly use H2. Hibernate uses 1.3 > for the testsuite - I was running tests with both 1.3 and 1.4 and the > behaviour can differ a lot, since 1.4 can lock separate rows and 1.3 locks > just whole tables (pardon me if I recall that incorrectly) - this can lead > to different timing, and eventually to deadlock/test failure. Just to let > you know that I had problems with these. > > Radim > > [1] > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/stress/CorrectnessTestCase.java > > On 04/06/2016 12:17 PM, Vlad Mihalcea wrote: > >> Hi Radim, >> >> I pushed this fix on master and 5.1, and I managed to add an EHCache >> where the same behavior was replicated as well: >> >> >> https://github.com/hibernate/hibernate-orm/commit/cbdab9d87f05b4255c7930a32fe995f87f0f3e0b >> >> For Infinispan, I think it's better if you can investigate if this is an >> issue or if the change does not break anything either (all Infinispan tests >> ran fine, so hopefully this should not be the case). >> >> Thanks, >> Vlad >> >> On Wed, Apr 6, 2016 at 12:58 PM, Radim Vansa > rvansa at redhat.com>> wrote: >> >> On 04/05/2016 04:13 PM, Vlad Mihalcea wrote: >> > Hi, >> > >> > I'd definitely fix it for the refresh operation, which does an >> implicit >> > cache eviction too. >> > In this case, the proposed PR solution is fine since it simply >> locks the >> > entry right after it is evicted from the cache and releases the >> lock after >> > the transaction is ended. >> > This way, we won't push an uncommitted entity into 2PL during >> the two-phase >> > loading phase that is triggered by the refresh operation. >> > >> > For sessionFactory.getCache.evictEntity/evictCollection, if >> there is a >> > current Session going on, we could propagate a >> > CacheEvictEvent/CollectionCacheEvictEvent which can apply the >> lock on that >> > particular entity/collection, and we release it right after the >> current >> > transaction is ended, similar to what refresh should do as well. >> > >> > For every other use case, like evictAll/evictRegion, we should just >> > document the behavior. >> > >> > I saw that Radim has added such a warning for Infinispan in the >> new User >> > Guide: >> > >> > read-write mode is supported on non-transactional >> distributed/replicated >> >> caches, however, eviction should not be used in this >> configuration. Use of >> >> eviction can lead to consistency issues. >> >> This is a different matter; in Infinispan 2LC impl you store locks and >> entries either in two different caches (the entries cache is >> invalidation, locks is local), or in single cache >> (replicated/distributed). As we don't want to lose locks randomly, and >> eviction picks entries unpredictably, its use is discouraged. >> >> I think that this issue does not apply to Infinispan with the >> invalidation configuration, since evict/evictAll does not remove any >> locks, and the lock blocks further updates (including putFromLoads) to >> the entry in cache until the transaction commits. In case of >> replicated/distributed cache, it seems that the evict is ignored after >> update, but evictAll is not (that would qualify as a bug) - so after >> evictAll you could observe the uncommitted read. Nevertheless I would >> have to test this. >> >> Radim >> >> > >> > Unfortunately, the EhCache documentation >> > >> < >> http://www.ehcache.org/documentation/2.8/integrations/hibernate.html#read-write >> > >> > makes a wrong assumption: >> > >> > read-write - Caches data that is sometimes updated while >> maintaining the >> >> semantics of ?read committed? isolation level. >> > >> > Vlad >> > >> > On Tue, Apr 5, 2016 at 4:30 PM, Sanne Grinovero >> > wrote: >> > >> >> On 5 April 2016 at 14:11, Vlad Mihalcea >> > wrote: >> >>> Hi, >> >>> >> >>> While reviewing the PR for this issue: >> >>> >> >>> https://hibernate.atlassian.net/browse/HHH-10649 >> >>> >> >>> I realized that the ReadWrite cache concurrency strategy has a >> flaw that >> >>> permits "read uncommitted" anomalies. >> >>> The RW cache concurrency strategy guards any modifications >> with Lock >> >>> entries, as explained in this post that I wrote some time ago: >> >>> >> >>> >> >> >> >> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/ >> >>> Every time we update/delete an entry, a Lock is put in the >> cache under >> >> the >> >>> entity key, and, this way, "read uncommitted" anomalies should be >> >> prevented. >> >>> The problem comes when entries are evicted either explicitly: >> >>> >> >>> session.getSessionFactory().getCache().evictEntity( >> CacheableItem.class, >> >>> item1.getId() ); >> >>> >> >>> or implicitly: >> >>> >> >>> session.refresh( item1 ); >> >> Good catch! >> >> >> >> I think this is caused as we generally don't expect the evict >> >> operation to be controlled explicitly. >> >> In my personal experience, I would use the evictAll method to >> nuke the >> >> cache state after some significant operation, like restoring a >> >> backup.. and no other Session would have been opened in the >> meantime. >> >> I never used an explicit single-shot evict so I can't say what >> the use >> >> case would be. >> >> >> >> But of course you're right that it might be used differently, or at >> >> least such a limitation should be clear. >> >> >> >>> During eviction, the 2PL will remove the Lock entry, and if >> the user >> >>> attempts to load the entity anew (in the same transaction that >> has modified >> >>> the entity but which is not committed yet), an uncommitted >> change could be >> >>> propagated to the 2PL. >> >>> >> >>> This issue is replicated by the PR associated to this Jira >> issue, and I >> >>> also replicated it with manual eviction and entity loading. >> >>> >> >>> To fix it, the RW cache concurrency strategy should not delete >> entries from >> >>> 2PL upon eviction, but instead it should turn them in Lock >> entries. >> >> I'm not sure I understood this part. Shouldn't it rather be >> allowed to >> >> delete everything, except any existing locks? >> >> Then rather than turn the remaining locks into locks, it would be >> >> enough to leave them. >> >> >> >>> For the evict method, this is not really a problem, but >> evictAll would >> >>> imply taking all entries and replacing them with Locks, and >> that might not >> >>> perform very well in a distributed-cache scenario. >> >>> >> >>> Ideally, lock entries would be stored separately than actual >> cached value >> >>> entries, and this problem would be fixed in a much cleaner >> fashion. >> >> I'd leave this as a detail to the Cache implementation, some >> might be >> >> able to perform some operation more efficiently. >> >> Probably a good idea to clarify this expectation on the javadocs of >> >> the SPI methods. >> >> >> >> Thanks, >> >> Sanne >> >> >> >> >> >>> Let me know what you think about this. >> >>> >> >>> Vlad >> >>> _______________________________________________ >> >>> 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 >> >> >> -- >> Radim Vansa > >> JBoss Performance Team >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> > > -- > Radim Vansa > JBoss Performance Team > > From gunnar at hibernate.org Wed Apr 6 09:05:53 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 6 Apr 2016 15:05:53 +0200 Subject: [hibernate-dev] OGM: convergence for a 5.0.0.Final ? In-Reply-To: References: Message-ID: +1 For doing the Final next week or maybe the one after. We could focus for one day or two to address the remaining (doc) issues. One further thing missing would be the slot rename you recently suggested. Note that the 4.2 core module would be added implicitly if the 4.2 module sets (using slot "main") and 5.0 module sets both are around. So the doc should say how to disable the implicitly added 4.2 in such case, if needed. Thinking about it, would it actually work with only the "5.0" slot is present? Not that the code adding the implicit dependency stumbles upon this... > OGM-817 Adapt to changes around auto-quoting That'd be needing a bit more thoughts/time though. I think we could do that in a subsequent release, too. Normally, ORM will quote specific table names (e.g. "Module") but the OGM integration disables that by default. In a subsequent release we'd have to drive it ideally based on actually reserved keywords for specific stores. 2016-04-06 12:43 GMT+02:00 Sanne Grinovero : > Hi, > I was hoping that even w/o a specific OGM sprint we would soon (next > week?) be able to re-spin the CR1 with minor effort as the > 5.0.0.Final. > > Among tasks scheduled for 5.0.0.Final: > - > https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%205.0.0.Final%20ORDER%20BY%20status%20ASC%2C%20assignee%20ASC > > I'm assigned two documentation related issues; these seem important > enough to stay flagged for 5.0.0.Final and should be doable. OGM-888 > also relates documentation and should be doable. > > Could we agree on moving out the other open issues? > > Personally I think the only one needing some attention still is: > - OGM-817 Adapt to changes around auto-quoting > > 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 Wed Apr 6 10:13:08 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 6 Apr 2016 15:13:08 +0100 Subject: [hibernate-dev] OGM: convergence for a 5.0.0.Final ? In-Reply-To: References: Message-ID: On 6 April 2016 at 14:05, Gunnar Morling wrote: > +1 For doing the Final next week or maybe the one after. We could focus for > one day or two to address the remaining (doc) issues. > > One further thing missing would be the slot rename you recently suggested. > Note that the 4.2 core module would be added implicitly if the 4.2 module > sets (using slot "main") and 5.0 module sets both are around. So the doc > should say how to disable the implicitly added 4.2 in such case, if needed. > Thinking about it, would it actually work with only the "5.0" slot is > present? Not that the code adding the implicit dependency stumbles upon > this... Good point, tracking now as: - https://hibernate.atlassian.net/browse/OGM-1015 We started some discussions about how modules should be but I had the impression I opened a pandora box rather than finding some consensus :) I'll get back to the relevant thread, but maybe we'll need a chat to expedite things. >> OGM-817 Adapt to changes around auto-quoting > > That'd be needing a bit more thoughts/time though. > > I think we could do that in a subsequent release, too. Normally, ORM will > quote specific table names (e.g. "Module") but the OGM integration disables > that by default. In a subsequent release we'd have to drive it ideally based > on actually reserved keywords for specific stores. Ok that sounds better than it initially looked, but I'm not entirely reassured: left this one scheduled for 5.0.0.Final for now so we can have another look. I've moved all other issues (not the docs ones). I didn't disable notifications this time so you all have time to fix or question that move. Looks feasible :) - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%205.0.0.Final%20and%20status%20%3D%20Open Next I'm splitting some of those doc issues into OGM + WEBSITE issues, as I can't update the website before the release and can't release w/o fixing the docs so I need to break out of the deadlock :) Thanks, Sanne > > > > 2016-04-06 12:43 GMT+02:00 Sanne Grinovero : >> >> Hi, >> I was hoping that even w/o a specific OGM sprint we would soon (next >> week?) be able to re-spin the CR1 with minor effort as the >> 5.0.0.Final. >> >> Among tasks scheduled for 5.0.0.Final: >> - >> https://hibernate.atlassian.net/issues/?jql=project%20%3D%20OGM%20AND%20fixVersion%20%3D%205.0.0.Final%20ORDER%20BY%20status%20ASC%2C%20assignee%20ASC >> >> I'm assigned two documentation related issues; these seem important >> enough to stay flagged for 5.0.0.Final and should be doable. OGM-888 >> also relates documentation and should be doable. >> >> Could we agree on moving out the other open issues? >> >> Personally I think the only one needing some attention still is: >> - OGM-817 Adapt to changes around auto-quoting >> >> 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 Wed Apr 6 12:15:44 2016 From: steve at hibernate.org (Steve Ebersole) Date: Wed, 06 Apr 2016 16:15:44 +0000 Subject: [hibernate-dev] Master Message-ID: Obviously consolidating hibernate-entitymanager into hibernate-core is a fairly big effort. And I am getting concerned about the continuing pushes to master in the meantime, many of which I know touch on code I have changed. My concern is obviously getting done all this refactoring work and then having to sift through all of the changes that have been pushed in the interim and attempting to work out the proper integration strategy. Long story short... I am contemplating pushing to master sooner rather than later even though my refactoring may not be completely finished, especially as we get towards the end of the week. From gbadner at redhat.com Wed Apr 6 14:16:18 2016 From: gbadner at redhat.com (Gail Badner) Date: Wed, 6 Apr 2016 11:16:18 -0700 Subject: [hibernate-dev] JDBC uses ON_CLOSE connection release mode In-Reply-To: References: Message-ID: Sorry, too late; it's gone. I guess I'll wait to hear if people are upset. On Tue, Apr 5, 2016 at 8:51 PM, Vlad Mihalcea wrote: > Hi Gail, > > I'm glad you like the new User Guide. > > Related to the old one, I think we could leave it hosted on docs.jboss.org > because some users might have bookmarked it, and deleting it might get them > angry. > > Vlad > > On Wed, Apr 6, 2016 at 1:36 AM, Gail Badner wrote: > >> Hi Vlad, >> >> I've pushed the documentation to >> http://docs.jboss.org/hibernate/orm/5.0/userguide/html_single/Hibernate_User_Guide.html >> and updated the link on hibernate.org. >> >> The old user guide is still out there. I've asked for it to be removed. >> >> The new user guide looks great! Thanks for your help on this. >> Gail >> >> On Tue, Apr 5, 2016 at 12:00 PM, Vlad Mihalcea >> wrote: >> >>> Thanks for the feedback, >>> >>> Fo the moment, the 5.0 docs are ready, and we can push the integration >>> further, as you suggested. >>> >>> There will be other updates that we'll do to improve the docs (Envers, >>> Spatial, Portability topics), and I'll make sure to split the 5.1-related >>> things from changes that apply to 5.0. >>> This way, we can maintain the 5.0 docs much more easily. >>> >>> Vlad >>> >>> On Tue, Apr 5, 2016 at 9:36 PM, Gail Badner wrote: >>> >>>> Hi Vlad, >>>> >>>> It looks great! If it's ready to go, I'll push it to >>>> https://docs.jboss.org/hibernate/orm/5.0/ and update the link on >>>> hibernate.org. >>>> >>>> Thanks! >>>> Gail >>>> >>>> On Mon, Apr 4, 2016 at 10:47 PM, Vlad Mihalcea >>> > wrote: >>>> >>>>> Hi Gail, >>>>> >>>>> I removed the 5.1 references on the new User Guide. >>>>> You can check it out and see how you like it: >>>>> >>>>> > cd documentation >>>>> > gradle rUG >>>>> >>>>> Let me know what you think. >>>>> >>>>> Vlad >>>>> >>>>> On Mon, Apr 4, 2016 at 11:02 PM, Gail Badner >>>>> wrote: >>>>> >>>>>> Thanks much! >>>>>> >>>>>> On Mon, Apr 4, 2016 at 11:48 AM, Vlad Mihalcea < >>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>> >>>>>>> Sure, >>>>>>> >>>>>>> I'm going to take care of it tomorrow. >>>>>>> >>>>>>> Vlad >>>>>>> >>>>>>> On Mon, Apr 4, 2016 at 9:33 PM, Gail Badner >>>>>>> wrote: >>>>>>> >>>>>>>> Is there is any 5.1-specific content? If so, it needs to be >>>>>>>> stripped out for 5.0. >>>>>>>> >>>>>>>> On Mon, Apr 4, 2016 at 6:35 AM, Vlad Mihalcea < >>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Gail, >>>>>>>>> >>>>>>>>> I pushed the 5.1 documentation into the 5,0 branch. >>>>>>>>> The only thing that's needed now is to modify the release >>>>>>>>> procedure which I'll send it as a PR. >>>>>>>>> >>>>>>>>> We also have to modify the hibernate.org site so that 5.0 >>>>>>>>> references the same documentation links as 5.1. >>>>>>>>> >>>>>>>>> Vlad >>>>>>>>> >>>>>>>>> On Thu, Mar 24, 2016 at 7:34 AM, Vlad Mihalcea < >>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> The 4.x branches contain the old documentation, the one that was >>>>>>>>>> written with Hibernate 3 in mind. >>>>>>>>>> >>>>>>>>>> The new documentation work was started in 5.0 but we only got it >>>>>>>>>> done in 5.1, so 5.0 doesn't contain all the additions we made to the new >>>>>>>>>> documentation. >>>>>>>>>> >>>>>>>>>> I can backport it for sure, but I don't know if it won't break >>>>>>>>>> something during the release phase. >>>>>>>>>> >>>>>>>>>> For this purpose, I'm going to split this task in two: >>>>>>>>>> >>>>>>>>>> 1. Copy the whole asciidoc User Guide that we wrote from scratch. >>>>>>>>>> This step will contain a lot of modifications so it will be difficult to >>>>>>>>>> review it in GitHub probably. But it can be reviewing manually. >>>>>>>>>> 2. Modify the release procedure to use the new User Guide. This >>>>>>>>>> step can be reviewed by you and Steve so we make sure we don't break >>>>>>>>>> anything. >>>>>>>>>> >>>>>>>>>> Vlad >>>>>>>>>> >>>>>>>>>> On Thu, Mar 24, 2016 at 1:52 AM, Gail Badner >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I noticed there is some information in 4.2 docs that are not in >>>>>>>>>>> 5.0. I'm not sure what happened there. >>>>>>>>>>> >>>>>>>>>>> Is there info in the 5.1 docs that does not apply to 5.0? If so, >>>>>>>>>>> is there a way to easily exclude it? >>>>>>>>>>> >>>>>>>>>>> I don't know what all is involved in backporting the docs. If it >>>>>>>>>>> can be done safely and excluding 5.1-specific info, then please go ahead. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Gail >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 23, 2016 at 12:17 AM, Vlad Mihalcea < >>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> I made the change for 4.2. >>>>>>>>>>>> >>>>>>>>>>>> For 5.0, we should switch to the current 5.1 documentation >>>>>>>>>>>> because the 5.0 User Guide lacks a lot of information. >>>>>>>>>>>> It requires adding the asciidoc documentation, Gradle configs, >>>>>>>>>>>> and also change the release procedure to use asciidoc instead of docbook. >>>>>>>>>>>> >>>>>>>>>>>> Should we add a new task for this? >>>>>>>>>>>> >>>>>>>>>>>> Vlad >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 22, 2016 at 8:07 PM, Gail Badner < >>>>>>>>>>>> gbadner at redhat.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Vlad, >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, please update the doc for 5.0 and 4.2. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> Gail >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Mar 20, 2016 at 11:37 PM, Vlad Mihalcea < >>>>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Gail, >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the 5.0 branch, I could update the doc for this issue. A >>>>>>>>>>>>>> new release will publish the updated doc, right? >>>>>>>>>>>>>> Should the documentation be updated for the 4.x branches too? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Vlad >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 17, 2016 at 9:04 PM, Steve Ebersole < >>>>>>>>>>>>>> steve at hibernate.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> It looks like it changed during 3.6 -> 4.0, reverting back >>>>>>>>>>>>>>> to ON_CLOSE. I agree it should changed to AFTER_TRANSACTION, >>>>>>>>>>>>>>> however I would only change it on master. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the other branches, if anything, just update the doc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 3, 2016 at 12:40 AM Vlad Mihalcea < >>>>>>>>>>>>>>> mihalcea.vlad at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think this PR is valid: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/hibernate/hibernate-orm/pull/997 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I checked it out and, when using JDBC, we use the ON_CLOSE >>>>>>>>>>>>>>>> connection >>>>>>>>>>>>>>>> release mode. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Shouldn't we use the AFTER_TRANSACTION release mode as we >>>>>>>>>>>>>>>> state in the docs? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Vlad >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>>> hibernate-dev at lists.jboss.org >>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sanne at hibernate.org Wed Apr 6 17:04:01 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 6 Apr 2016 22:04:01 +0100 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: Sounds reasonable. Do you think it will be unstable, i.e. should we temporarily disable complaint emails from Jenkins, or even the full build tasks? Also, this implies that any future backport becomes similarly harder, so you could also simply ask others to hold pushing on master, then have people forward-port when it's done.. it's the same really but that's why I mention it: as the complexity is interchangeable it's a fair request, with the difference you have: - others help you port the other patches forward rather than doing it all alone - the authors of the original patch doing it, that should make it a bit simpler On 6 April 2016 at 17:15, Steve Ebersole wrote: > Obviously consolidating hibernate-entitymanager into hibernate-core is a > fairly big effort. And I am getting concerned about the continuing pushes > to master in the meantime, many of which I know touch on code I have > changed. My concern is obviously getting done all this refactoring work > and then having to sift through all of the changes that have been pushed in > the interim and attempting to work out the proper integration strategy. > > Long story short... I am contemplating pushing to master sooner rather than > later even though my refactoring may not be completely finished, especially > as we get towards the end of the week. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From zerg2k at yahoo.com Wed Apr 6 17:41:22 2016 From: zerg2k at yahoo.com (Noel Diaz) Date: Wed, 6 Apr 2016 21:41:22 +0000 (UTC) Subject: [hibernate-dev] Hibernate-ORM In-Reply-To: <1861921256.2849215.1459365148047.JavaMail.yahoo@mail.yahoo.com> References: <1861921256.2849215.1459365148047.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1337737318.533966.1459978882788.JavaMail.yahoo@mail.yahoo.com> Hi Gail,Because this is a blocker for me is there an ETA or a patch that I can pull to move on my end util 5.1.1 actually gets it? Sorry for the annoyance, ~Noel? On Wednesday, March 30, 2016 3:12 PM, Noel Diaz wrote: Hi Gail, Thank you very much for your prompt reply. The reason I asked for 5.1.1 is because I could see Steve's comments: In the JIRA link?:?[HHH-10373] Sequence generator for idbag ignores generator parameters - Hibernate JIRA | | | | | | | | | | | [HHH-10373] Sequence generator for idbag ignores generator parameters - Hib... | | | | Steve Ebersole?made changes -?28/Feb/2016 09:49 AM | Fix Version/s | | 5.1.1?[ 22550 ] | | Fix Version/s | | 5.0.9?[ 22651 ] | Maybe I misread (or misinterpreted that message) Again, Thank you! Noel On Wednesday, March 30, 2016 2:22 PM, Gail Badner wrote: Hi Noel, HHH-10373 has not been fixed yet so it's not availablein 5.1.1-SNAPSHOT yet. Hibernate snapshots are at: https://repository.jboss.org/nexus/content/groups/public/org/hibernate. Regards, Gail On Wed, Mar 30, 2016 at 8:27 AM, Noel Diaz wrote: Hi, I am getting blocked by this issue:?https://hibernate.atlassian.net/browse/HHH-10373 Where can I get 5.1.1 snapshot files? cheers,~noel _______________________________________________ hibernate-dev mailing list hibernate-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev From crancran at gmail.com Wed Apr 6 17:47:59 2016 From: crancran at gmail.com (Chris Cranford) Date: Wed, 6 Apr 2016 16:47:59 -0500 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: I have to concur with Sanne, a hold on master pushes until this merge of artifacts is complete makes the most sense from an all around logistics perspective. On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero wrote: > Sounds reasonable. Do you think it will be unstable, i.e. should we > temporarily disable complaint emails from Jenkins, or even the full > build tasks? > > Also, this implies that any future backport becomes similarly harder, > so you could also simply ask others to hold pushing on master, then > have people forward-port when it's done.. it's the same really but > that's why I mention it: as the complexity is interchangeable it's a > fair request, with the difference you have: > - others help you port the other patches forward rather than doing it all > alone > - the authors of the original patch doing it, that should make it a bit > simpler > > > > On 6 April 2016 at 17:15, Steve Ebersole wrote: > > Obviously consolidating hibernate-entitymanager into hibernate-core is a > > fairly big effort. And I am getting concerned about the continuing > pushes > > to master in the meantime, many of which I know touch on code I have > > changed. My concern is obviously getting done all this refactoring work > > and then having to sift through all of the changes that have been pushed > in > > the interim and attempting to work out the proper integration strategy. > > > > Long story short... I am contemplating pushing to master sooner rather > than > > later even though my refactoring may not be completely finished, > especially > > as we get towards the end of the week. > > _______________________________________________ > > 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 Apr 7 10:57:20 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 07 Apr 2016 14:57:20 +0000 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: I agree that would be best. If everyone agrees to stop pushing to master for the time being to allow me to finish this consolidation then I can not rush it as much On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: > I have to concur with Sanne, a hold on master pushes until this merge of > artifacts is complete makes the most sense from an all around logistics > perspective. > > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero > wrote: > > > Sounds reasonable. Do you think it will be unstable, i.e. should we > > temporarily disable complaint emails from Jenkins, or even the full > > build tasks? > > > > Also, this implies that any future backport becomes similarly harder, > > so you could also simply ask others to hold pushing on master, then > > have people forward-port when it's done.. it's the same really but > > that's why I mention it: as the complexity is interchangeable it's a > > fair request, with the difference you have: > > - others help you port the other patches forward rather than doing it > all > > alone > > - the authors of the original patch doing it, that should make it a bit > > simpler > > > > > > > > On 6 April 2016 at 17:15, Steve Ebersole wrote: > > > Obviously consolidating hibernate-entitymanager into hibernate-core is > a > > > fairly big effort. And I am getting concerned about the continuing > > pushes > > > to master in the meantime, many of which I know touch on code I have > > > changed. My concern is obviously getting done all this refactoring > work > > > and then having to sift through all of the changes that have been > pushed > > in > > > the interim and attempting to work out the proper integration strategy. > > > > > > Long story short... I am contemplating pushing to master sooner rather > > than > > > later even though my refactoring may not be completely finished, > > especially > > > as we get towards the end of the week. > > > _______________________________________________ > > > 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 mihalcea.vlad at gmail.com Thu Apr 7 11:01:07 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 7 Apr 2016 18:01:07 +0300 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: Hi, Until the merge is done, I'll take a break integrating the PRs that are also relevant to the master branch. Vlad On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole wrote: > I agree that would be best. If everyone agrees to stop pushing to master > for the time being to allow me to finish this consolidation then I can not > rush it as much > > On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: > > > I have to concur with Sanne, a hold on master pushes until this merge of > > artifacts is complete makes the most sense from an all around logistics > > perspective. > > > > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero > > wrote: > > > > > Sounds reasonable. Do you think it will be unstable, i.e. should we > > > temporarily disable complaint emails from Jenkins, or even the full > > > build tasks? > > > > > > Also, this implies that any future backport becomes similarly harder, > > > so you could also simply ask others to hold pushing on master, then > > > have people forward-port when it's done.. it's the same really but > > > that's why I mention it: as the complexity is interchangeable it's a > > > fair request, with the difference you have: > > > - others help you port the other patches forward rather than doing it > > all > > > alone > > > - the authors of the original patch doing it, that should make it a > bit > > > simpler > > > > > > > > > > > > On 6 April 2016 at 17:15, Steve Ebersole wrote: > > > > Obviously consolidating hibernate-entitymanager into hibernate-core > is > > a > > > > fairly big effort. And I am getting concerned about the continuing > > > pushes > > > > to master in the meantime, many of which I know touch on code I have > > > > changed. My concern is obviously getting done all this refactoring > > work > > > > and then having to sift through all of the changes that have been > > pushed > > > in > > > > the interim and attempting to work out the proper integration > strategy. > > > > > > > > Long story short... I am contemplating pushing to master sooner > rather > > > than > > > > later even though my refactoring may not be completely finished, > > > especially > > > > as we get towards the end of the week. > > > > _______________________________________________ > > > > 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 steve at hibernate.org Thu Apr 7 11:34:24 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 07 Apr 2016 15:34:24 +0000 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: As a follow up to this... Sanne had a great suggestion on HipChat. What about turning all this work (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be 5.2 would include: 1. Move to Java 8 2. Consolidation of hibernate-entitymanager into hibernate-core 3. Deprecations, lots of deprecations :) The idea is that then we could start 6.0 off "clean" by removing all the deprecations and layering in SQM work. On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea wrote: > Hi, > > Until the merge is done, I'll take a break integrating the PRs that are > also relevant to the master branch. > > Vlad > > On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > wrote: > >> I agree that would be best. If everyone agrees to stop pushing to master >> for the time being to allow me to finish this consolidation then I can not >> rush it as much >> >> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: >> >> > I have to concur with Sanne, a hold on master pushes until this merge of >> > artifacts is complete makes the most sense from an all around logistics >> > perspective. >> > >> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero >> > wrote: >> > >> > > Sounds reasonable. Do you think it will be unstable, i.e. should we >> > > temporarily disable complaint emails from Jenkins, or even the full >> > > build tasks? >> > > >> > > Also, this implies that any future backport becomes similarly harder, >> > > so you could also simply ask others to hold pushing on master, then >> > > have people forward-port when it's done.. it's the same really but >> > > that's why I mention it: as the complexity is interchangeable it's a >> > > fair request, with the difference you have: >> > > - others help you port the other patches forward rather than doing it >> > all >> > > alone >> > > - the authors of the original patch doing it, that should make it a >> bit >> > > simpler >> > > >> > > >> > > >> > > On 6 April 2016 at 17:15, Steve Ebersole wrote: >> > > > Obviously consolidating hibernate-entitymanager into hibernate-core >> is >> > a >> > > > fairly big effort. And I am getting concerned about the continuing >> > > pushes >> > > > to master in the meantime, many of which I know touch on code I have >> > > > changed. My concern is obviously getting done all this refactoring >> > work >> > > > and then having to sift through all of the changes that have been >> > pushed >> > > in >> > > > the interim and attempting to work out the proper integration >> strategy. >> > > > >> > > > Long story short... I am contemplating pushing to master sooner >> rather >> > > than >> > > > later even though my refactoring may not be completely finished, >> > > especially >> > > > as we get towards the end of the week. >> > > > _______________________________________________ >> > > > 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 crancran at gmail.com Thu Apr 7 12:03:39 2016 From: crancran at gmail.com (Chris Cranford) Date: Thu, 7 Apr 2016 11:03:39 -0500 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: +1 for 5.2 On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole wrote: > As a follow up to this... > > Sanne had a great suggestion on HipChat. What about turning all this work > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be > 5.2 would include: > > 1. Move to Java 8 > 2. Consolidation of hibernate-entitymanager into hibernate-core > 3. Deprecations, lots of deprecations :) > > > The idea is that then we could start 6.0 off "clean" by removing all the > deprecations and layering in SQM work. > > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > wrote: > >> Hi, >> >> Until the merge is done, I'll take a break integrating the PRs that are >> also relevant to the master branch. >> >> Vlad >> >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >> wrote: >> >>> I agree that would be best. If everyone agrees to stop pushing to master >>> for the time being to allow me to finish this consolidation then I can >>> not >>> rush it as much >>> >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford >>> wrote: >>> >>> > I have to concur with Sanne, a hold on master pushes until this merge >>> of >>> > artifacts is complete makes the most sense from an all around logistics >>> > perspective. >>> > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero >>> > wrote: >>> > >>> > > Sounds reasonable. Do you think it will be unstable, i.e. should we >>> > > temporarily disable complaint emails from Jenkins, or even the full >>> > > build tasks? >>> > > >>> > > Also, this implies that any future backport becomes similarly harder, >>> > > so you could also simply ask others to hold pushing on master, then >>> > > have people forward-port when it's done.. it's the same really but >>> > > that's why I mention it: as the complexity is interchangeable it's a >>> > > fair request, with the difference you have: >>> > > - others help you port the other patches forward rather than doing >>> it >>> > all >>> > > alone >>> > > - the authors of the original patch doing it, that should make it a >>> bit >>> > > simpler >>> > > >>> > > >>> > > >>> > > On 6 April 2016 at 17:15, Steve Ebersole >>> wrote: >>> > > > Obviously consolidating hibernate-entitymanager into >>> hibernate-core is >>> > a >>> > > > fairly big effort. And I am getting concerned about the continuing >>> > > pushes >>> > > > to master in the meantime, many of which I know touch on code I >>> have >>> > > > changed. My concern is obviously getting done all this refactoring >>> > work >>> > > > and then having to sift through all of the changes that have been >>> > pushed >>> > > in >>> > > > the interim and attempting to work out the proper integration >>> strategy. >>> > > > >>> > > > Long story short... I am contemplating pushing to master sooner >>> rather >>> > > than >>> > > > later even though my refactoring may not be completely finished, >>> > > especially >>> > > > as we get towards the end of the week. >>> > > > _______________________________________________ >>> > > > 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 mihalcea.vlad at gmail.com Thu Apr 7 12:20:34 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 7 Apr 2016 19:20:34 +0300 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: +1 too. On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford wrote: > +1 for 5.2 > > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole > wrote: > > > As a follow up to this... > > > > Sanne had a great suggestion on HipChat. What about turning all this > work > > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be > > 5.2 would include: > > > > 1. Move to Java 8 > > 2. Consolidation of hibernate-entitymanager into hibernate-core > > 3. Deprecations, lots of deprecations :) > > > > > > The idea is that then we could start 6.0 off "clean" by removing all the > > deprecations and layering in SQM work. > > > > > > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > > wrote: > > > >> Hi, > >> > >> Until the merge is done, I'll take a break integrating the PRs that are > >> also relevant to the master branch. > >> > >> Vlad > >> > >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > >> wrote: > >> > >>> I agree that would be best. If everyone agrees to stop pushing to > master > >>> for the time being to allow me to finish this consolidation then I can > >>> not > >>> rush it as much > >>> > >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > >>> wrote: > >>> > >>> > I have to concur with Sanne, a hold on master pushes until this merge > >>> of > >>> > artifacts is complete makes the most sense from an all around > logistics > >>> > perspective. > >>> > > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero > > >>> > wrote: > >>> > > >>> > > Sounds reasonable. Do you think it will be unstable, i.e. should we > >>> > > temporarily disable complaint emails from Jenkins, or even the full > >>> > > build tasks? > >>> > > > >>> > > Also, this implies that any future backport becomes similarly > harder, > >>> > > so you could also simply ask others to hold pushing on master, then > >>> > > have people forward-port when it's done.. it's the same really but > >>> > > that's why I mention it: as the complexity is interchangeable it's > a > >>> > > fair request, with the difference you have: > >>> > > - others help you port the other patches forward rather than doing > >>> it > >>> > all > >>> > > alone > >>> > > - the authors of the original patch doing it, that should make it > a > >>> bit > >>> > > simpler > >>> > > > >>> > > > >>> > > > >>> > > On 6 April 2016 at 17:15, Steve Ebersole > >>> wrote: > >>> > > > Obviously consolidating hibernate-entitymanager into > >>> hibernate-core is > >>> > a > >>> > > > fairly big effort. And I am getting concerned about the > continuing > >>> > > pushes > >>> > > > to master in the meantime, many of which I know touch on code I > >>> have > >>> > > > changed. My concern is obviously getting done all this > refactoring > >>> > work > >>> > > > and then having to sift through all of the changes that have been > >>> > pushed > >>> > > in > >>> > > > the interim and attempting to work out the proper integration > >>> strategy. > >>> > > > > >>> > > > Long story short... I am contemplating pushing to master sooner > >>> rather > >>> > > than > >>> > > > later even though my refactoring may not be completely finished, > >>> > > especially > >>> > > > as we get towards the end of the week. > >>> > > > _______________________________________________ > >>> > > > 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 dreborier at gmail.com Thu Apr 7 13:21:03 2016 From: dreborier at gmail.com (andrea boriero) Date: Thu, 7 Apr 2016 18:21:03 +0100 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: +1 On 7 Apr 2016 17:22, "Vlad Mihalcea" wrote: > +1 too. > > > > On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford wrote: > > > +1 for 5.2 > > > > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole > > wrote: > > > > > As a follow up to this... > > > > > > Sanne had a great suggestion on HipChat. What about turning all this > > work > > > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would > be > > > 5.2 would include: > > > > > > 1. Move to Java 8 > > > 2. Consolidation of hibernate-entitymanager into hibernate-core > > > 3. Deprecations, lots of deprecations :) > > > > > > > > > The idea is that then we could start 6.0 off "clean" by removing all > the > > > deprecations and layering in SQM work. > > > > > > > > > > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > > > > wrote: > > > > > >> Hi, > > >> > > >> Until the merge is done, I'll take a break integrating the PRs that > are > > >> also relevant to the master branch. > > >> > > >> Vlad > > >> > > >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > > >> wrote: > > >> > > >>> I agree that would be best. If everyone agrees to stop pushing to > > master > > >>> for the time being to allow me to finish this consolidation then I > can > > >>> not > > >>> rush it as much > > >>> > > >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > > >>> wrote: > > >>> > > >>> > I have to concur with Sanne, a hold on master pushes until this > merge > > >>> of > > >>> > artifacts is complete makes the most sense from an all around > > logistics > > >>> > perspective. > > >>> > > > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > sanne at hibernate.org > > > > > >>> > wrote: > > >>> > > > >>> > > Sounds reasonable. Do you think it will be unstable, i.e. should > we > > >>> > > temporarily disable complaint emails from Jenkins, or even the > full > > >>> > > build tasks? > > >>> > > > > >>> > > Also, this implies that any future backport becomes similarly > > harder, > > >>> > > so you could also simply ask others to hold pushing on master, > then > > >>> > > have people forward-port when it's done.. it's the same really > but > > >>> > > that's why I mention it: as the complexity is interchangeable > it's > > a > > >>> > > fair request, with the difference you have: > > >>> > > - others help you port the other patches forward rather than > doing > > >>> it > > >>> > all > > >>> > > alone > > >>> > > - the authors of the original patch doing it, that should make > it > > a > > >>> bit > > >>> > > simpler > > >>> > > > > >>> > > > > >>> > > > > >>> > > On 6 April 2016 at 17:15, Steve Ebersole > > >>> wrote: > > >>> > > > Obviously consolidating hibernate-entitymanager into > > >>> hibernate-core is > > >>> > a > > >>> > > > fairly big effort. And I am getting concerned about the > > continuing > > >>> > > pushes > > >>> > > > to master in the meantime, many of which I know touch on code I > > >>> have > > >>> > > > changed. My concern is obviously getting done all this > > refactoring > > >>> > work > > >>> > > > and then having to sift through all of the changes that have > been > > >>> > pushed > > >>> > > in > > >>> > > > the interim and attempting to work out the proper integration > > >>> strategy. > > >>> > > > > > >>> > > > Long story short... I am contemplating pushing to master sooner > > >>> rather > > >>> > > than > > >>> > > > later even though my refactoring may not be completely > finished, > > >>> > > especially > > >>> > > > as we get towards the end of the week. > > >>> > > > _______________________________________________ > > >>> > > > 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 gbadner at redhat.com Thu Apr 7 14:48:34 2016 From: gbadner at redhat.com (Gail Badner) Date: Thu, 7 Apr 2016 11:48:34 -0700 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: +1 On Thu, Apr 7, 2016 at 10:21 AM, andrea boriero wrote: > +1 > On 7 Apr 2016 17:22, "Vlad Mihalcea" wrote: > > > +1 too. > > > > > > > > On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford > wrote: > > > > > +1 for 5.2 > > > > > > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole > > > wrote: > > > > > > > As a follow up to this... > > > > > > > > Sanne had a great suggestion on HipChat. What about turning all this > > > work > > > > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea > would > > be > > > > 5.2 would include: > > > > > > > > 1. Move to Java 8 > > > > 2. Consolidation of hibernate-entitymanager into hibernate-core > > > > 3. Deprecations, lots of deprecations :) > > > > > > > > > > > > The idea is that then we could start 6.0 off "clean" by removing all > > the > > > > deprecations and layering in SQM work. > > > > > > > > > > > > > > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < > mihalcea.vlad at gmail.com > > > > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> Until the merge is done, I'll take a break integrating the PRs that > > are > > > >> also relevant to the master branch. > > > >> > > > >> Vlad > > > >> > > > >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > > > > >> wrote: > > > >> > > > >>> I agree that would be best. If everyone agrees to stop pushing to > > > master > > > >>> for the time being to allow me to finish this consolidation then I > > can > > > >>> not > > > >>> rush it as much > > > >>> > > > >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > > > >>> wrote: > > > >>> > > > >>> > I have to concur with Sanne, a hold on master pushes until this > > merge > > > >>> of > > > >>> > artifacts is complete makes the most sense from an all around > > > logistics > > > >>> > perspective. > > > >>> > > > > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > > sanne at hibernate.org > > > > > > > >>> > wrote: > > > >>> > > > > >>> > > Sounds reasonable. Do you think it will be unstable, i.e. > should > > we > > > >>> > > temporarily disable complaint emails from Jenkins, or even the > > full > > > >>> > > build tasks? > > > >>> > > > > > >>> > > Also, this implies that any future backport becomes similarly > > > harder, > > > >>> > > so you could also simply ask others to hold pushing on master, > > then > > > >>> > > have people forward-port when it's done.. it's the same really > > but > > > >>> > > that's why I mention it: as the complexity is interchangeable > > it's > > > a > > > >>> > > fair request, with the difference you have: > > > >>> > > - others help you port the other patches forward rather than > > doing > > > >>> it > > > >>> > all > > > >>> > > alone > > > >>> > > - the authors of the original patch doing it, that should make > > it > > > a > > > >>> bit > > > >>> > > simpler > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > On 6 April 2016 at 17:15, Steve Ebersole > > > >>> wrote: > > > >>> > > > Obviously consolidating hibernate-entitymanager into > > > >>> hibernate-core is > > > >>> > a > > > >>> > > > fairly big effort. And I am getting concerned about the > > > continuing > > > >>> > > pushes > > > >>> > > > to master in the meantime, many of which I know touch on > code I > > > >>> have > > > >>> > > > changed. My concern is obviously getting done all this > > > refactoring > > > >>> > work > > > >>> > > > and then having to sift through all of the changes that have > > been > > > >>> > pushed > > > >>> > > in > > > >>> > > > the interim and attempting to work out the proper integration > > > >>> strategy. > > > >>> > > > > > > >>> > > > Long story short... I am contemplating pushing to master > sooner > > > >>> rather > > > >>> > > than > > > >>> > > > later even though my refactoring may not be completely > > finished, > > > >>> > > especially > > > >>> > > > as we get towards the end of the week. > > > >>> > > > _______________________________________________ > > > >>> > > > 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 gbadner at redhat.com Thu Apr 7 14:49:14 2016 From: gbadner at redhat.com (Gail Badner) Date: Thu, 7 Apr 2016 11:49:14 -0700 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: I am holding off on pushing to master until I hear otherwise. On Thu, Apr 7, 2016 at 11:48 AM, Gail Badner wrote: > +1 > > On Thu, Apr 7, 2016 at 10:21 AM, andrea boriero > wrote: > >> +1 >> On 7 Apr 2016 17:22, "Vlad Mihalcea" wrote: >> >> > +1 too. >> > >> > >> > >> > On Thu, Apr 7, 2016 at 7:03 PM, Chris Cranford >> wrote: >> > >> > > +1 for 5.2 >> > > >> > > On Thu, Apr 7, 2016 at 10:34 AM, Steve Ebersole >> > > wrote: >> > > >> > > > As a follow up to this... >> > > > >> > > > Sanne had a great suggestion on HipChat. What about turning all >> this >> > > work >> > > > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea >> would >> > be >> > > > 5.2 would include: >> > > > >> > > > 1. Move to Java 8 >> > > > 2. Consolidation of hibernate-entitymanager into hibernate-core >> > > > 3. Deprecations, lots of deprecations :) >> > > > >> > > > >> > > > The idea is that then we could start 6.0 off "clean" by removing all >> > the >> > > > deprecations and layering in SQM work. >> > > > >> > > > >> > > > >> > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < >> mihalcea.vlad at gmail.com >> > > >> > > > wrote: >> > > > >> > > >> Hi, >> > > >> >> > > >> Until the merge is done, I'll take a break integrating the PRs that >> > are >> > > >> also relevant to the master branch. >> > > >> >> > > >> Vlad >> > > >> >> > > >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole < >> steve at hibernate.org> >> > > >> wrote: >> > > >> >> > > >>> I agree that would be best. If everyone agrees to stop pushing to >> > > master >> > > >>> for the time being to allow me to finish this consolidation then I >> > can >> > > >>> not >> > > >>> rush it as much >> > > >>> >> > > >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > > >> > > >>> wrote: >> > > >>> >> > > >>> > I have to concur with Sanne, a hold on master pushes until this >> > merge >> > > >>> of >> > > >>> > artifacts is complete makes the most sense from an all around >> > > logistics >> > > >>> > perspective. >> > > >>> > >> > > >>> > On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < >> > sanne at hibernate.org >> > > > >> > > >>> > wrote: >> > > >>> > >> > > >>> > > Sounds reasonable. Do you think it will be unstable, i.e. >> should >> > we >> > > >>> > > temporarily disable complaint emails from Jenkins, or even the >> > full >> > > >>> > > build tasks? >> > > >>> > > >> > > >>> > > Also, this implies that any future backport becomes similarly >> > > harder, >> > > >>> > > so you could also simply ask others to hold pushing on master, >> > then >> > > >>> > > have people forward-port when it's done.. it's the same really >> > but >> > > >>> > > that's why I mention it: as the complexity is interchangeable >> > it's >> > > a >> > > >>> > > fair request, with the difference you have: >> > > >>> > > - others help you port the other patches forward rather than >> > doing >> > > >>> it >> > > >>> > all >> > > >>> > > alone >> > > >>> > > - the authors of the original patch doing it, that should >> make >> > it >> > > a >> > > >>> bit >> > > >>> > > simpler >> > > >>> > > >> > > >>> > > >> > > >>> > > >> > > >>> > > On 6 April 2016 at 17:15, Steve Ebersole > > >> > > >>> wrote: >> > > >>> > > > Obviously consolidating hibernate-entitymanager into >> > > >>> hibernate-core is >> > > >>> > a >> > > >>> > > > fairly big effort. And I am getting concerned about the >> > > continuing >> > > >>> > > pushes >> > > >>> > > > to master in the meantime, many of which I know touch on >> code I >> > > >>> have >> > > >>> > > > changed. My concern is obviously getting done all this >> > > refactoring >> > > >>> > work >> > > >>> > > > and then having to sift through all of the changes that have >> > been >> > > >>> > pushed >> > > >>> > > in >> > > >>> > > > the interim and attempting to work out the proper >> integration >> > > >>> strategy. >> > > >>> > > > >> > > >>> > > > Long story short... I am contemplating pushing to master >> sooner >> > > >>> rather >> > > >>> > > than >> > > >>> > > > later even though my refactoring may not be completely >> > finished, >> > > >>> > > especially >> > > >>> > > > as we get towards the end of the week. >> > > >>> > > > _______________________________________________ >> > > >>> > > > 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 sanne at hibernate.org Fri Apr 8 07:30:27 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 8 Apr 2016 12:30:27 +0100 Subject: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests Message-ID: Github now offers an option to not create the "merge commit" when you want to merge a PR from the web ui. It comes at a significant cost though: it will merge the PR but squash all commits in one. While initially thinking that doesn't help us at all, at second thought: we really want any non-trivial code change to be checked out locally, run the testsuite, and only then push. But let's say there's a trivial PR fixing some typos in documentation! You look at it, looks good and then you really just want to say "go ahead" and get back to more important matters. Besides, we have Jenkins carefully testing these too and it will grey out the button if the build fails, so there's some kind of last defence in case you didn't notice that the "docs typo" PR actually sneaks in some real problem. So I'd say we could enable this option with the "squashing" ? We would still refrain from using the green button for most patches, but it could save some "boring process" minutes for those simpler patches. I've enabled this option for Hibernate Search. We can seek team consensus before actually using it (you're not supposed to use the "green button" at all currently), I might at least have it default to the less annoying option: if you do use it by mistake, it will squash it all. The open question remains if we're ok to use it regularly for trivial PRs, and if you want this switched on all Hibernate repositories. Thanks, Sanne From davide at hibernate.org Fri Apr 8 07:46:43 2016 From: davide at hibernate.org (Davide D'Alto) Date: Fri, 8 Apr 2016 12:46:43 +0100 Subject: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests In-Reply-To: References: Message-ID: +1 It seems sensible to me to use it for trivial pull request or where it makes sense to have a single commit. On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero wrote: > Github now offers an option to not create the "merge commit" when you > want to merge a PR from the web ui. > > It comes at a significant cost though: it will merge the PR but squash > all commits in one. > > While initially thinking that doesn't help us at all, at second > thought: we really want any non-trivial code change to be checked out > locally, run the testsuite, and only then push. > > But let's say there's a trivial PR fixing some typos in documentation! > You look at it, looks good and then you really just want to say "go > ahead" and get back to more important matters. Besides, we have > Jenkins carefully testing these too and it will grey out the button if > the build fails, so there's some kind of last defence in case you > didn't notice that the "docs typo" PR actually sneaks in some real > problem. > > So I'd say we could enable this option with the "squashing" ? > > We would still refrain from using the green button for most patches, > but it could save some "boring process" minutes for those simpler > patches. > > I've enabled this option for Hibernate Search. We can seek team > consensus before actually using it (you're not supposed to use the > "green button" at all currently), I might at least have it default to > the less annoying option: if you do use it by mistake, it will squash > it all. > > The open question remains if we're ok to use it regularly for trivial > PRs, and if you want this switched on all Hibernate repositories. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Fri Apr 8 08:02:58 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 8 Apr 2016 15:02:58 +0300 Subject: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests In-Reply-To: References: Message-ID: Since this feature does not support rebase, what happens if the master has newer commits that the PR does not. Will it do a merge commit in this case? On Fri, Apr 8, 2016 at 2:46 PM, Davide D'Alto wrote: > +1 > > It seems sensible to me to use it for trivial pull request or where it > makes > sense to have a single commit. > > > On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero > wrote: > > > Github now offers an option to not create the "merge commit" when you > > want to merge a PR from the web ui. > > > > It comes at a significant cost though: it will merge the PR but squash > > all commits in one. > > > > While initially thinking that doesn't help us at all, at second > > thought: we really want any non-trivial code change to be checked out > > locally, run the testsuite, and only then push. > > > > But let's say there's a trivial PR fixing some typos in documentation! > > You look at it, looks good and then you really just want to say "go > > ahead" and get back to more important matters. Besides, we have > > Jenkins carefully testing these too and it will grey out the button if > > the build fails, so there's some kind of last defence in case you > > didn't notice that the "docs typo" PR actually sneaks in some real > > problem. > > > > So I'd say we could enable this option with the "squashing" ? > > > > We would still refrain from using the green button for most patches, > > but it could save some "boring process" minutes for those simpler > > patches. > > > > I've enabled this option for Hibernate Search. We can seek team > > consensus before actually using it (you're not supposed to use the > > "green button" at all currently), I might at least have it default to > > the less annoying option: if you do use it by mistake, it will squash > > it all. > > > > The open question remains if we're ok to use it regularly for trivial > > PRs, and if you want this switched on all Hibernate repositories. > > > > 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 sanne at hibernate.org Fri Apr 8 08:35:11 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 8 Apr 2016 13:35:11 +0100 Subject: [hibernate-dev] A warmup task: HSEARCH-2207 Message-ID: Hi Mincong, Gunnar suggested that I find a first task for you to familiarize with the project, and to have you practice the process of creating patches and proposing them for integration over GitHub. I think this issue could be suited: - https://hibernate.atlassian.net/browse/HSEARCH-2207 I hope it's not too boring! It's not just an exercise, we need that done so it would be a valuable contribution already. Do you have an account on our JIRA server? If not create one, then let me know your user id so I can assign the issue to you. Thanks, Sanne From smarlow at redhat.com Fri Apr 8 10:04:52 2016 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 8 Apr 2016 10:04:52 -0400 Subject: [hibernate-dev] Master In-Reply-To: References: Message-ID: <5707BA84.5010307@redhat.com> I'm curious if Search/OGM master branches would likely align with 5.2? Or some other branch? On 04/07/2016 11:34 AM, Steve Ebersole wrote: > As a follow up to this... > > Sanne had a great suggestion on HipChat. What about turning all this work > (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be > 5.2 would include: > > 1. Move to Java 8 > 2. Consolidation of hibernate-entitymanager into hibernate-core > 3. Deprecations, lots of deprecations :) > > > The idea is that then we could start 6.0 off "clean" by removing all the > deprecations and layering in SQM work. > > > > On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > wrote: > >> Hi, >> >> Until the merge is done, I'll take a break integrating the PRs that are >> also relevant to the master branch. >> >> Vlad >> >> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >> wrote: >> >>> I agree that would be best. If everyone agrees to stop pushing to master >>> for the time being to allow me to finish this consolidation then I can not >>> rush it as much >>> >>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: >>> >>>> I have to concur with Sanne, a hold on master pushes until this merge of >>>> artifacts is complete makes the most sense from an all around logistics >>>> perspective. >>>> >>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero >>>> wrote: >>>> >>>>> Sounds reasonable. Do you think it will be unstable, i.e. should we >>>>> temporarily disable complaint emails from Jenkins, or even the full >>>>> build tasks? >>>>> >>>>> Also, this implies that any future backport becomes similarly harder, >>>>> so you could also simply ask others to hold pushing on master, then >>>>> have people forward-port when it's done.. it's the same really but >>>>> that's why I mention it: as the complexity is interchangeable it's a >>>>> fair request, with the difference you have: >>>>> - others help you port the other patches forward rather than doing it >>>> all >>>>> alone >>>>> - the authors of the original patch doing it, that should make it a >>> bit >>>>> simpler >>>>> >>>>> >>>>> >>>>> On 6 April 2016 at 17:15, Steve Ebersole wrote: >>>>>> Obviously consolidating hibernate-entitymanager into hibernate-core >>> is >>>> a >>>>>> fairly big effort. And I am getting concerned about the continuing >>>>> pushes >>>>>> to master in the meantime, many of which I know touch on code I have >>>>>> changed. My concern is obviously getting done all this refactoring >>>> work >>>>>> and then having to sift through all of the changes that have been >>>> pushed >>>>> in >>>>>> the interim and attempting to work out the proper integration >>> strategy. >>>>>> >>>>>> Long story short... I am contemplating pushing to master sooner >>> rather >>>>> than >>>>>> later even though my refactoring may not be completely finished, >>>>> especially >>>>>> as we get towards the end of the week. >>>>>> _______________________________________________ >>>>>> 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 Fri Apr 8 10:38:12 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 8 Apr 2016 15:38:12 +0100 Subject: [hibernate-dev] Master In-Reply-To: <5707BA84.5010307@redhat.com> References: <5707BA84.5010307@redhat.com> Message-ID: On 8 April 2016 at 15:04, Scott Marlow wrote: > I'm curious if Search/OGM master branches would likely align with 5.2? > Or some other branch? Good question, time for an update on these. We'll certainly have a version of Search compatible, at some point. Not sure though about which version that shall be as we want to be feature complete with our Elasticsearch work, and that will take a couple more months at least so we'll see a bit longer than usual gap between stable releases. Generally speaking we need at least a minor release for OGM or Search to happen to upgrade the minor of ORM. Since we didn't release yet, Search is still building with ORM 5.0.x as a target.. we can then decide if we should skip ORM 5.1 and jump to 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As far as I know only some test helpers broke though, so while I couldn't test it all on both versions 5.0 and 5.1 of ORM, I think that they are compatible at runtime and we also expect to be compatible with ORM 5.2. With OGM we're now in candidate release phase for a ORM 5.0 compatible version so not really thinking to bump it to ORM 5.1 yet. OGM tends to release less frequently, so in this case it is possible that we might want to skip ORM 5.1 and go on 5.2 already to catch up, but we can work on aiming a specific version if and when need arises. If you need any of these aligned let us know? Thanks, Sanne > > On 04/07/2016 11:34 AM, Steve Ebersole wrote: >> As a follow up to this... >> >> Sanne had a great suggestion on HipChat. What about turning all this work >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would be >> 5.2 would include: >> >> 1. Move to Java 8 >> 2. Consolidation of hibernate-entitymanager into hibernate-core >> 3. Deprecations, lots of deprecations :) >> >> >> The idea is that then we could start 6.0 off "clean" by removing all the >> deprecations and layering in SQM work. >> >> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea >> wrote: >> >>> Hi, >>> >>> Until the merge is done, I'll take a break integrating the PRs that are >>> also relevant to the master branch. >>> >>> Vlad >>> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >>> wrote: >>> >>>> I agree that would be best. If everyone agrees to stop pushing to master >>>> for the time being to allow me to finish this consolidation then I can not >>>> rush it as much >>>> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford wrote: >>>> >>>>> I have to concur with Sanne, a hold on master pushes until this merge of >>>>> artifacts is complete makes the most sense from an all around logistics >>>>> perspective. >>>>> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero >>>>> wrote: >>>>> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should we >>>>>> temporarily disable complaint emails from Jenkins, or even the full >>>>>> build tasks? >>>>>> >>>>>> Also, this implies that any future backport becomes similarly harder, >>>>>> so you could also simply ask others to hold pushing on master, then >>>>>> have people forward-port when it's done.. it's the same really but >>>>>> that's why I mention it: as the complexity is interchangeable it's a >>>>>> fair request, with the difference you have: >>>>>> - others help you port the other patches forward rather than doing it >>>>> all >>>>>> alone >>>>>> - the authors of the original patch doing it, that should make it a >>>> bit >>>>>> simpler >>>>>> >>>>>> >>>>>> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole wrote: >>>>>>> Obviously consolidating hibernate-entitymanager into hibernate-core >>>> is >>>>> a >>>>>>> fairly big effort. And I am getting concerned about the continuing >>>>>> pushes >>>>>>> to master in the meantime, many of which I know touch on code I have >>>>>>> changed. My concern is obviously getting done all this refactoring >>>>> work >>>>>>> and then having to sift through all of the changes that have been >>>>> pushed >>>>>> in >>>>>>> the interim and attempting to work out the proper integration >>>> strategy. >>>>>>> >>>>>>> Long story short... I am contemplating pushing to master sooner >>>> rather >>>>>> than >>>>>>> later even though my refactoring may not be completely finished, >>>>>> especially >>>>>>> as we get towards the end of the week. >>>>>>> _______________________________________________ >>>>>>> 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 brett at hibernate.org Fri Apr 8 13:49:26 2016 From: brett at hibernate.org (Brett Meyer) Date: Fri, 8 Apr 2016 13:49:26 -0400 Subject: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests In-Reply-To: References: Message-ID: <5707EF26.3030408@hibernate.org> +1 from me as well. As is, we don?t use the existing merge button, so we might as well change it to something we*may* use in a handful of situations. And those situations tend to be squashed anyway... On 04/08/2016 07:46 AM, Davide D'Alto wrote: > +1 > > It seems sensible to me to use it for trivial pull request or where it makes > sense to have a single commit. > > > On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero > wrote: > >> Github now offers an option to not create the "merge commit" when you >> want to merge a PR from the web ui. >> >> It comes at a significant cost though: it will merge the PR but squash >> all commits in one. >> >> While initially thinking that doesn't help us at all, at second >> thought: we really want any non-trivial code change to be checked out >> locally, run the testsuite, and only then push. >> >> But let's say there's a trivial PR fixing some typos in documentation! >> You look at it, looks good and then you really just want to say "go >> ahead" and get back to more important matters. Besides, we have >> Jenkins carefully testing these too and it will grey out the button if >> the build fails, so there's some kind of last defence in case you >> didn't notice that the "docs typo" PR actually sneaks in some real >> problem. >> >> So I'd say we could enable this option with the "squashing" ? >> >> We would still refrain from using the green button for most patches, >> but it could save some "boring process" minutes for those simpler >> patches. >> >> I've enabled this option for Hibernate Search. We can seek team >> consensus before actually using it (you're not supposed to use the >> "green button" at all currently), I might at least have it default to >> the less annoying option: if you do use it by mistake, it will squash >> it all. >> >> The open question remains if we're ok to use it regularly for trivial >> PRs, and if you want this switched on all Hibernate repositories. >> >> 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 Fri Apr 8 15:44:33 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 08 Apr 2016 19:44:33 +0000 Subject: [hibernate-dev] Github offering new options about how the big "green button" to merge Pull Requests In-Reply-To: <5707EF26.3030408@hibernate.org> References: <5707EF26.3030408@hibernate.org> Message-ID: I had the same question as Vlad. Do these have to be forward-only merges to not create the "merge commit"? I would assume so if they are still not supporting rebase of pull requests. In which case this becomes quickly useless unless we dont let these sit. +1 from me either way for ORM. As Brett said it makes the "easy button" something i might possibly maybe use as opposed to something i would never ever use. On Fri, Apr 8, 2016, 12:49 PM Brett Meyer wrote: > +1 from me as well. As is, we don?t use the existing merge button, so we > might as well change it to something we*may* use in a handful of > situations. And those situations tend to be squashed anyway... > > > On 04/08/2016 07:46 AM, Davide D'Alto wrote: > > +1 > > > > It seems sensible to me to use it for trivial pull request or where it > makes > > sense to have a single commit. > > > > > > On Fri, Apr 8, 2016 at 12:30 PM, Sanne Grinovero > > wrote: > > > >> Github now offers an option to not create the "merge commit" when you > >> want to merge a PR from the web ui. > >> > >> It comes at a significant cost though: it will merge the PR but squash > >> all commits in one. > >> > >> While initially thinking that doesn't help us at all, at second > >> thought: we really want any non-trivial code change to be checked out > >> locally, run the testsuite, and only then push. > >> > >> But let's say there's a trivial PR fixing some typos in documentation! > >> You look at it, looks good and then you really just want to say "go > >> ahead" and get back to more important matters. Besides, we have > >> Jenkins carefully testing these too and it will grey out the button if > >> the build fails, so there's some kind of last defence in case you > >> didn't notice that the "docs typo" PR actually sneaks in some real > >> problem. > >> > >> So I'd say we could enable this option with the "squashing" ? > >> > >> We would still refrain from using the green button for most patches, > >> but it could save some "boring process" minutes for those simpler > >> patches. > >> > >> I've enabled this option for Hibernate Search. We can seek team > >> consensus before actually using it (you're not supposed to use the > >> "green button" at all currently), I might at least have it default to > >> the less annoying option: if you do use it by mistake, it will squash > >> it all. > >> > >> The open question remains if we're ok to use it regularly for trivial > >> PRs, and if you want this switched on all Hibernate repositories. > >> > >> 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 > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Mon Apr 11 13:12:48 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 11 Apr 2016 20:12:48 +0300 Subject: [hibernate-dev] Spring Data Hibernate 5 integration struggle Message-ID: Hi, It seems that the Spring Data team is currently struggling with the Hibernate 5.1 integration due to some regression issues they've been documenting in the following Gist: https://github.com/spring-projects/spring-data-examples/commit/eccb39fada199fd021e0dc092568740f229d57bf Can we prioritize these issues so that we can make sure they get fixed in the next 5.1 release? Vlad From andrea at hibernate.org Mon Apr 11 13:19:44 2016 From: andrea at hibernate.org (andrea boriero) Date: Mon, 11 Apr 2016 18:19:44 +0100 Subject: [hibernate-dev] Spring Data Hibernate 5 integration struggle In-Reply-To: References: Message-ID: I'm working on https://hibernate.atlassian.net/browse/HHH-10605; for the https://hibernate.atlassian.net/browse/HHH-10515 I have two different PR: https://github.com/hibernate/hibernate-orm/pull/1264 https://github.com/hibernate/hibernate-orm/pull/1263 Andrea On 11 April 2016 at 18:12, Vlad Mihalcea wrote: > Hi, > > It seems that the Spring Data team is currently struggling with the > Hibernate 5.1 integration due to some regression issues they've been > documenting in the following Gist: > > > https://github.com/spring-projects/spring-data-examples/commit/eccb39fada199fd021e0dc092568740f229d57bf > > Can we prioritize these issues so that we can make sure they get fixed in > the next 5.1 release? > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Tue Apr 12 09:48:17 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 12 Apr 2016 16:48:17 +0300 Subject: [hibernate-dev] SQLite integration Message-ID: Hi, The guys that want to integrate the SQLite Dialect are asking what is the status for this: https://github.com/gwenn/sqlite-dialect/issues/7#issuecomment-208905388 Should there be some discussion between Steve and them to agree if they can commit to maintaining the Dialect? Vlad From mihalcea.vlad at gmail.com Tue Apr 12 09:56:23 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 12 Apr 2016 16:56:23 +0300 Subject: [hibernate-dev] GitHub PR management Message-ID: Hi, Both Andrea and I have been going through the current list of PR, and I think it is a good idea to start labeling them. Some issues are trivial and can be integrated as soon as we can commit on the master. I think we should add the following labels: - Needs CLA - Needs Jira - Needs Test Case - Envers - 4.2 - 4.3 - 5.0 - 5.1 This way we can easily navigate through them. Vlad From andrea at hibernate.org Tue Apr 12 10:08:28 2016 From: andrea at hibernate.org (andrea boriero) Date: Tue, 12 Apr 2016 15:08:28 +0100 Subject: [hibernate-dev] GitHub PR management In-Reply-To: References: Message-ID: +1 On 12 April 2016 at 14:56, Vlad Mihalcea wrote: > Hi, > > Both Andrea and I have been going through the current list of PR, and I > think it is a good idea to start labeling them. > Some issues are trivial and can be integrated as soon as we can commit on > the master. > > I think we should add the following labels: > > - Needs CLA > - Needs Jira > - Needs Test Case > - Envers > - 4.2 > - 4.3 > - 5.0 > - 5.1 > > This way we can easily navigate through them. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Tue Apr 12 14:29:50 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 12 Apr 2016 18:29:50 +0000 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: Just a quick update on my progress. I pretty much have Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out as well as bootstrapping. I am currently working through the different Query hierarchies. Looking at what is left, I hope to be done with all of this by Thursday On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero wrote: > On 8 April 2016 at 15:04, Scott Marlow wrote: > > I'm curious if Search/OGM master branches would likely align with 5.2? > > Or some other branch? > > Good question, time for an update on these. > > We'll certainly have a version of Search compatible, at some point. > Not sure though about which version that shall be as we want to be > feature complete with our Elasticsearch work, and that will take a > couple more months at least so we'll see a bit longer than usual gap > between stable releases. > > Generally speaking we need at least a minor release for OGM or Search > to happen to upgrade the minor of ORM. > Since we didn't release yet, Search is still building with ORM 5.0.x > as a target.. we can then decide if we should skip ORM 5.1 and jump to > 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As > far as I know only some test helpers broke though, so while I couldn't > test it all on both versions 5.0 and 5.1 of ORM, I think that they are > compatible at runtime and we also expect to be compatible with ORM > 5.2. > > With OGM we're now in candidate release phase for a ORM 5.0 compatible > version so not really thinking to bump it to ORM 5.1 yet. > > OGM tends to release less frequently, so in this case it is possible > that we might want to skip ORM 5.1 and go on 5.2 already to catch up, > but we can work on aiming a specific version if and when need arises. > > If you need any of these aligned let us know? > > Thanks, > Sanne > > > > > On 04/07/2016 11:34 AM, Steve Ebersole wrote: > >> As a follow up to this... > >> > >> Sanne had a great suggestion on HipChat. What about turning all this > work > >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would > be > >> 5.2 would include: > >> > >> 1. Move to Java 8 > >> 2. Consolidation of hibernate-entitymanager into hibernate-core > >> 3. Deprecations, lots of deprecations :) > >> > >> > >> The idea is that then we could start 6.0 off "clean" by removing all the > >> deprecations and layering in SQM work. > >> > >> > >> > >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > >> wrote: > >> > >>> Hi, > >>> > >>> Until the merge is done, I'll take a break integrating the PRs that are > >>> also relevant to the master branch. > >>> > >>> Vlad > >>> > >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > >>> wrote: > >>> > >>>> I agree that would be best. If everyone agrees to stop pushing to > master > >>>> for the time being to allow me to finish this consolidation then I > can not > >>>> rush it as much > >>>> > >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > wrote: > >>>> > >>>>> I have to concur with Sanne, a hold on master pushes until this > merge of > >>>>> artifacts is complete makes the most sense from an all around > logistics > >>>>> perspective. > >>>>> > >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero > > >>>>> wrote: > >>>>> > >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should we > >>>>>> temporarily disable complaint emails from Jenkins, or even the full > >>>>>> build tasks? > >>>>>> > >>>>>> Also, this implies that any future backport becomes similarly > harder, > >>>>>> so you could also simply ask others to hold pushing on master, then > >>>>>> have people forward-port when it's done.. it's the same really but > >>>>>> that's why I mention it: as the complexity is interchangeable it's a > >>>>>> fair request, with the difference you have: > >>>>>> - others help you port the other patches forward rather than > doing it > >>>>> all > >>>>>> alone > >>>>>> - the authors of the original patch doing it, that should make it > a > >>>> bit > >>>>>> simpler > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 6 April 2016 at 17:15, Steve Ebersole > wrote: > >>>>>>> Obviously consolidating hibernate-entitymanager into hibernate-core > >>>> is > >>>>> a > >>>>>>> fairly big effort. And I am getting concerned about the continuing > >>>>>> pushes > >>>>>>> to master in the meantime, many of which I know touch on code I > have > >>>>>>> changed. My concern is obviously getting done all this refactoring > >>>>> work > >>>>>>> and then having to sift through all of the changes that have been > >>>>> pushed > >>>>>> in > >>>>>>> the interim and attempting to work out the proper integration > >>>> strategy. > >>>>>>> > >>>>>>> Long story short... I am contemplating pushing to master sooner > >>>> rather > >>>>>> than > >>>>>>> later even though my refactoring may not be completely finished, > >>>>>> especially > >>>>>>> as we get towards the end of the week. > >>>>>>> _______________________________________________ > >>>>>>> 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 steve at hibernate.org Tue Apr 12 18:48:33 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 12 Apr 2016 22:48:33 +0000 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: Another question as I work through Query... Currently both Session and StatelessSession inherit the same query creation methods (returning org.hibernate.Query) via SharedSessionContract (which is the common base type between them). There is therefore an inherent difficulty in having org.hibernate.Query extend from the JPA javax.persistence.Query/TypedQuery when we only want Session to be an EntityManager, not StatelessSession. The simplest solution is to: 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and move all of the existing SharedSessionContract query creation methods returning org.hibernate.Query directly to StatelessSession 2. develop a new org.hibernate.query.Query (prefacing 6.0) that provides some of the "legacy Hibernate query contract" and extends from javax.persistence.Query. Directly on Session we'd write new methods with the same name and args but returning this org.hibernate.query.Query. This would give us 2 distinct Query hierarchies and allow the underlying goal of Session extending EntityManager, but not StatelessSession. We could also flip these based on the knowledge that Session is more widely used (less disruptive). In other words we'd go from both Session and StatelessSession returning org.hibernate.Query via inheriting from SharedSessionContract: public interface SharedSessionContract { ... org.hibernate.Query createQuery(String hql); } to each Session and StatelessSession implementing different methods altogether: public interface StatelessSession { ... org.hibernate.Query createQuery(String hql); } public interface Session { ... org.hibernate.query.Query createQuery(String hql); } Unifying these returns across Session and StatelessSession would require StatelessSession also being an EntityManager. I had decided against that for the same reasons that StatelessSession is distinct from Session. Maybe a hybrid approach would be to break the query creation methods out of SharedSessionContract into a new targeted interface named QueryProducer which both Session and StatelessSession would implement. That would allow unifying the query creation return to something that implements JPA Query contract too, but the source (Session/StatelessSession via QueryProducer) would not necessarily need to implement EntityManager. I think the QueryProducer route is probably the best option in terms of allowing the consolidation but still allowing users to upgrade easily. Thoughts? Other options? Hopefully I explained it well enough :) On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole wrote: > Just a quick update on my progress. I pretty much have > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out as > well as bootstrapping. > > I am currently working through the different Query hierarchies. > > Looking at what is left, I hope to be done with all of this by Thursday > > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero wrote: > >> On 8 April 2016 at 15:04, Scott Marlow wrote: >> > I'm curious if Search/OGM master branches would likely align with 5.2? >> > Or some other branch? >> >> Good question, time for an update on these. >> >> We'll certainly have a version of Search compatible, at some point. >> Not sure though about which version that shall be as we want to be >> feature complete with our Elasticsearch work, and that will take a >> couple more months at least so we'll see a bit longer than usual gap >> between stable releases. >> >> Generally speaking we need at least a minor release for OGM or Search >> to happen to upgrade the minor of ORM. >> Since we didn't release yet, Search is still building with ORM 5.0.x >> as a target.. we can then decide if we should skip ORM 5.1 and jump to >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As >> far as I know only some test helpers broke though, so while I couldn't >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are >> compatible at runtime and we also expect to be compatible with ORM >> 5.2. >> >> With OGM we're now in candidate release phase for a ORM 5.0 compatible >> version so not really thinking to bump it to ORM 5.1 yet. >> >> OGM tends to release less frequently, so in this case it is possible >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, >> but we can work on aiming a specific version if and when need arises. >> >> If you need any of these aligned let us know? >> >> Thanks, >> Sanne >> >> > >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: >> >> As a follow up to this... >> >> >> >> Sanne had a great suggestion on HipChat. What about turning all this >> work >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea would >> be >> >> 5.2 would include: >> >> >> >> 1. Move to Java 8 >> >> 2. Consolidation of hibernate-entitymanager into hibernate-core >> >> 3. Deprecations, lots of deprecations :) >> >> >> >> >> >> The idea is that then we could start 6.0 off "clean" by removing all >> the >> >> deprecations and layering in SQM work. >> >> >> >> >> >> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > > >> >> wrote: >> >> >> >>> Hi, >> >>> >> >>> Until the merge is done, I'll take a break integrating the PRs that >> are >> >>> also relevant to the master branch. >> >>> >> >>> Vlad >> >>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >> >>> wrote: >> >>> >> >>>> I agree that would be best. If everyone agrees to stop pushing to >> master >> >>>> for the time being to allow me to finish this consolidation then I >> can not >> >>>> rush it as much >> >>>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford >> wrote: >> >>>> >> >>>>> I have to concur with Sanne, a hold on master pushes until this >> merge of >> >>>>> artifacts is complete makes the most sense from an all around >> logistics >> >>>>> perspective. >> >>>>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < >> sanne at hibernate.org> >> >>>>> wrote: >> >>>>> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should we >> >>>>>> temporarily disable complaint emails from Jenkins, or even the full >> >>>>>> build tasks? >> >>>>>> >> >>>>>> Also, this implies that any future backport becomes similarly >> harder, >> >>>>>> so you could also simply ask others to hold pushing on master, then >> >>>>>> have people forward-port when it's done.. it's the same really but >> >>>>>> that's why I mention it: as the complexity is interchangeable it's >> a >> >>>>>> fair request, with the difference you have: >> >>>>>> - others help you port the other patches forward rather than >> doing it >> >>>>> all >> >>>>>> alone >> >>>>>> - the authors of the original patch doing it, that should make >> it a >> >>>> bit >> >>>>>> simpler >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole >> wrote: >> >>>>>>> Obviously consolidating hibernate-entitymanager into >> hibernate-core >> >>>> is >> >>>>> a >> >>>>>>> fairly big effort. And I am getting concerned about the >> continuing >> >>>>>> pushes >> >>>>>>> to master in the meantime, many of which I know touch on code I >> have >> >>>>>>> changed. My concern is obviously getting done all this >> refactoring >> >>>>> work >> >>>>>>> and then having to sift through all of the changes that have been >> >>>>> pushed >> >>>>>> in >> >>>>>>> the interim and attempting to work out the proper integration >> >>>> strategy. >> >>>>>>> >> >>>>>>> Long story short... I am contemplating pushing to master sooner >> >>>> rather >> >>>>>> than >> >>>>>>> later even though my refactoring may not be completely finished, >> >>>>>> especially >> >>>>>>> as we get towards the end of the week. >> >>>>>>> _______________________________________________ >> >>>>>>> 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 sanne at hibernate.org Tue Apr 12 19:32:54 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 13 Apr 2016 01:32:54 +0200 Subject: [hibernate-dev] A warmup task: HSEARCH-2207 In-Reply-To: References: Message-ID: Hi Mincong, great start! I've added you to the right groups on JIRA, so now HSEARCH-2207 is assigned to you. To be allowed to send emails to the hibernate dev mailinst list you have to register first: - https://lists.jboss.org/mailman/listinfo/hibernate-dev Thanks, Sanne On 12 April 2016 at 22:55, Mincong Huang wrote: > Hi Sanne ant Gunner, > > Concerned with the issue HSEARCH-2207, I'm studying on it. > > I created a demo and write a blog about boolean query in Apache Lucene. > As for Hibernate Search, I still not start learning it. I'll probably start > this weekend. > For instant, my priority is to understand the index, query and analyzer in > Lucene. > > My JIRA account is mincong.h at gmail.com > > I'm not allowed to send email to hibernate dev list, so it isn't in cc. > > Cheers, > Mincong > > > > > On Sat, Apr 9, 2016 at 8:27 PM, Mincong Huang wrote: >> >> Hi Sanne, >> >> Thanks for your email. No, it won't be boring at all. On the contrary, >> this will be a great beginning ! >> I'll take a look on the issue and keep you informed. As for the JIRA >> account, here's the mine : >> mincong.h at gmail.com >> >> Cheers, >> Mincong >> >> >> On Fri, Apr 8, 2016 at 2:35 PM, Sanne Grinovero >> wrote: >>> >>> Hi Mincong, >>> >>> Gunnar suggested that I find a first task for you to familiarize with >>> the project, and to have you practice the process of creating patches >>> and proposing them for integration over GitHub. >>> >>> I think this issue could be suited: >>> - https://hibernate.atlassian.net/browse/HSEARCH-2207 >>> >>> I hope it's not too boring! It's not just an exercise, we need that >>> done so it would be a valuable contribution already. >>> >>> Do you have an account on our JIRA server? If not create one, then let >>> me know your user id so I can assign the issue to you. >>> >>> Thanks, >>> Sanne >> >> > From gbadner at redhat.com Tue Apr 12 23:40:17 2016 From: gbadner at redhat.com (Gail Badner) Date: Tue, 12 Apr 2016 20:40:17 -0700 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: +1 for QueryProducer On Tue, Apr 12, 2016 at 3:48 PM, Steve Ebersole wrote: > Another question as I work through Query... > > Currently both Session and StatelessSession inherit the same query creation > methods (returning org.hibernate.Query) via SharedSessionContract (which is > the common base type between them). There is therefore an inherent > difficulty in having org.hibernate.Query extend from the JPA > javax.persistence.Query/TypedQuery when we only want Session to be an > EntityManager, not StatelessSession. > > The simplest solution is to: > > 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and > move all of the existing SharedSessionContract query creation methods > returning org.hibernate.Query directly to StatelessSession > 2. develop a new org.hibernate.query.Query (prefacing 6.0) that > provides some of the "legacy Hibernate query contract" and extends > from > javax.persistence.Query. Directly on Session we'd write new methods > with > the same name and args but returning this org.hibernate.query.Query. > > This would give us 2 distinct Query hierarchies and allow the underlying > goal of Session extending EntityManager, but not StatelessSession. We > could also flip these based on the knowledge that Session is more widely > used (less disruptive). > > In other words we'd go from both Session and StatelessSession returning > org.hibernate.Query via inheriting from SharedSessionContract: > > public interface SharedSessionContract { > ... > org.hibernate.Query createQuery(String hql); > } > > > to each Session and StatelessSession implementing different methods > altogether: > > public interface StatelessSession { > ... > org.hibernate.Query createQuery(String hql); > } > > public interface Session { > ... > org.hibernate.query.Query createQuery(String hql); > } > > > Unifying these returns across Session and StatelessSession would require > StatelessSession also being an EntityManager. I had decided against that > for the same reasons that StatelessSession is distinct from Session. > > Maybe a hybrid approach would be to break the query creation methods out of > SharedSessionContract into a new targeted interface named QueryProducer > which both Session and StatelessSession would implement. That would allow > unifying the query creation return to something that implements JPA Query > contract too, but the source (Session/StatelessSession via QueryProducer) > would not necessarily need to implement EntityManager. > > > I think the QueryProducer route is probably the best option in terms of > allowing the consolidation but still allowing users to upgrade easily. > > Thoughts? Other options? Hopefully I explained it well enough :) > > > On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole > wrote: > > > Just a quick update on my progress. I pretty much have > > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out > as > > well as bootstrapping. > > > > I am currently working through the different Query hierarchies. > > > > Looking at what is left, I hope to be done with all of this by Thursday > > > > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero > wrote: > > > >> On 8 April 2016 at 15:04, Scott Marlow wrote: > >> > I'm curious if Search/OGM master branches would likely align with 5.2? > >> > Or some other branch? > >> > >> Good question, time for an update on these. > >> > >> We'll certainly have a version of Search compatible, at some point. > >> Not sure though about which version that shall be as we want to be > >> feature complete with our Elasticsearch work, and that will take a > >> couple more months at least so we'll see a bit longer than usual gap > >> between stable releases. > >> > >> Generally speaking we need at least a minor release for OGM or Search > >> to happen to upgrade the minor of ORM. > >> Since we didn't release yet, Search is still building with ORM 5.0.x > >> as a target.. we can then decide if we should skip ORM 5.1 and jump to > >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As > >> far as I know only some test helpers broke though, so while I couldn't > >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are > >> compatible at runtime and we also expect to be compatible with ORM > >> 5.2. > >> > >> With OGM we're now in candidate release phase for a ORM 5.0 compatible > >> version so not really thinking to bump it to ORM 5.1 yet. > >> > >> OGM tends to release less frequently, so in this case it is possible > >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, > >> but we can work on aiming a specific version if and when need arises. > >> > >> If you need any of these aligned let us know? > >> > >> Thanks, > >> Sanne > >> > >> > > >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: > >> >> As a follow up to this... > >> >> > >> >> Sanne had a great suggestion on HipChat. What about turning all this > >> work > >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea > would > >> be > >> >> 5.2 would include: > >> >> > >> >> 1. Move to Java 8 > >> >> 2. Consolidation of hibernate-entitymanager into hibernate-core > >> >> 3. Deprecations, lots of deprecations :) > >> >> > >> >> > >> >> The idea is that then we could start 6.0 off "clean" by removing all > >> the > >> >> deprecations and layering in SQM work. > >> >> > >> >> > >> >> > >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < > mihalcea.vlad at gmail.com > >> > > >> >> wrote: > >> >> > >> >>> Hi, > >> >>> > >> >>> Until the merge is done, I'll take a break integrating the PRs that > >> are > >> >>> also relevant to the master branch. > >> >>> > >> >>> Vlad > >> >>> > >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > > >> >>> wrote: > >> >>> > >> >>>> I agree that would be best. If everyone agrees to stop pushing to > >> master > >> >>>> for the time being to allow me to finish this consolidation then I > >> can not > >> >>>> rush it as much > >> >>>> > >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > >> wrote: > >> >>>> > >> >>>>> I have to concur with Sanne, a hold on master pushes until this > >> merge of > >> >>>>> artifacts is complete makes the most sense from an all around > >> logistics > >> >>>>> perspective. > >> >>>>> > >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should > we > >> >>>>>> temporarily disable complaint emails from Jenkins, or even the > full > >> >>>>>> build tasks? > >> >>>>>> > >> >>>>>> Also, this implies that any future backport becomes similarly > >> harder, > >> >>>>>> so you could also simply ask others to hold pushing on master, > then > >> >>>>>> have people forward-port when it's done.. it's the same really > but > >> >>>>>> that's why I mention it: as the complexity is interchangeable > it's > >> a > >> >>>>>> fair request, with the difference you have: > >> >>>>>> - others help you port the other patches forward rather than > >> doing it > >> >>>>> all > >> >>>>>> alone > >> >>>>>> - the authors of the original patch doing it, that should make > >> it a > >> >>>> bit > >> >>>>>> simpler > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole > >> wrote: > >> >>>>>>> Obviously consolidating hibernate-entitymanager into > >> hibernate-core > >> >>>> is > >> >>>>> a > >> >>>>>>> fairly big effort. And I am getting concerned about the > >> continuing > >> >>>>>> pushes > >> >>>>>>> to master in the meantime, many of which I know touch on code I > >> have > >> >>>>>>> changed. My concern is obviously getting done all this > >> refactoring > >> >>>>> work > >> >>>>>>> and then having to sift through all of the changes that have > been > >> >>>>> pushed > >> >>>>>> in > >> >>>>>>> the interim and attempting to work out the proper integration > >> >>>> strategy. > >> >>>>>>> > >> >>>>>>> Long story short... I am contemplating pushing to master sooner > >> >>>> rather > >> >>>>>> than > >> >>>>>>> later even though my refactoring may not be completely finished, > >> >>>>>> especially > >> >>>>>>> as we get towards the end of the week. > >> >>>>>>> _______________________________________________ > >> >>>>>>> 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 > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Wed Apr 13 01:27:21 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 13 Apr 2016 08:27:21 +0300 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: QueryProducer seems the way to go for me too. On Wed, Apr 13, 2016 at 1:48 AM, Steve Ebersole wrote: > Another question as I work through Query... > > Currently both Session and StatelessSession inherit the same query creation > methods (returning org.hibernate.Query) via SharedSessionContract (which is > the common base type between them). There is therefore an inherent > difficulty in having org.hibernate.Query extend from the JPA > javax.persistence.Query/TypedQuery when we only want Session to be an > EntityManager, not StatelessSession. > > The simplest solution is to: > > 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and > move all of the existing SharedSessionContract query creation methods > returning org.hibernate.Query directly to StatelessSession > 2. develop a new org.hibernate.query.Query (prefacing 6.0) that > provides some of the "legacy Hibernate query contract" and extends > from > javax.persistence.Query. Directly on Session we'd write new methods > with > the same name and args but returning this org.hibernate.query.Query. > > This would give us 2 distinct Query hierarchies and allow the underlying > goal of Session extending EntityManager, but not StatelessSession. We > could also flip these based on the knowledge that Session is more widely > used (less disruptive). > > In other words we'd go from both Session and StatelessSession returning > org.hibernate.Query via inheriting from SharedSessionContract: > > public interface SharedSessionContract { > ... > org.hibernate.Query createQuery(String hql); > } > > > to each Session and StatelessSession implementing different methods > altogether: > > public interface StatelessSession { > ... > org.hibernate.Query createQuery(String hql); > } > > public interface Session { > ... > org.hibernate.query.Query createQuery(String hql); > } > > > Unifying these returns across Session and StatelessSession would require > StatelessSession also being an EntityManager. I had decided against that > for the same reasons that StatelessSession is distinct from Session. > > Maybe a hybrid approach would be to break the query creation methods out of > SharedSessionContract into a new targeted interface named QueryProducer > which both Session and StatelessSession would implement. That would allow > unifying the query creation return to something that implements JPA Query > contract too, but the source (Session/StatelessSession via QueryProducer) > would not necessarily need to implement EntityManager. > > > I think the QueryProducer route is probably the best option in terms of > allowing the consolidation but still allowing users to upgrade easily. > > Thoughts? Other options? Hopefully I explained it well enough :) > > > On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole > wrote: > > > Just a quick update on my progress. I pretty much have > > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out > as > > well as bootstrapping. > > > > I am currently working through the different Query hierarchies. > > > > Looking at what is left, I hope to be done with all of this by Thursday > > > > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero > wrote: > > > >> On 8 April 2016 at 15:04, Scott Marlow wrote: > >> > I'm curious if Search/OGM master branches would likely align with 5.2? > >> > Or some other branch? > >> > >> Good question, time for an update on these. > >> > >> We'll certainly have a version of Search compatible, at some point. > >> Not sure though about which version that shall be as we want to be > >> feature complete with our Elasticsearch work, and that will take a > >> couple more months at least so we'll see a bit longer than usual gap > >> between stable releases. > >> > >> Generally speaking we need at least a minor release for OGM or Search > >> to happen to upgrade the minor of ORM. > >> Since we didn't release yet, Search is still building with ORM 5.0.x > >> as a target.. we can then decide if we should skip ORM 5.1 and jump to > >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As > >> far as I know only some test helpers broke though, so while I couldn't > >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are > >> compatible at runtime and we also expect to be compatible with ORM > >> 5.2. > >> > >> With OGM we're now in candidate release phase for a ORM 5.0 compatible > >> version so not really thinking to bump it to ORM 5.1 yet. > >> > >> OGM tends to release less frequently, so in this case it is possible > >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, > >> but we can work on aiming a specific version if and when need arises. > >> > >> If you need any of these aligned let us know? > >> > >> Thanks, > >> Sanne > >> > >> > > >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: > >> >> As a follow up to this... > >> >> > >> >> Sanne had a great suggestion on HipChat. What about turning all this > >> work > >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea > would > >> be > >> >> 5.2 would include: > >> >> > >> >> 1. Move to Java 8 > >> >> 2. Consolidation of hibernate-entitymanager into hibernate-core > >> >> 3. Deprecations, lots of deprecations :) > >> >> > >> >> > >> >> The idea is that then we could start 6.0 off "clean" by removing all > >> the > >> >> deprecations and layering in SQM work. > >> >> > >> >> > >> >> > >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < > mihalcea.vlad at gmail.com > >> > > >> >> wrote: > >> >> > >> >>> Hi, > >> >>> > >> >>> Until the merge is done, I'll take a break integrating the PRs that > >> are > >> >>> also relevant to the master branch. > >> >>> > >> >>> Vlad > >> >>> > >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > > >> >>> wrote: > >> >>> > >> >>>> I agree that would be best. If everyone agrees to stop pushing to > >> master > >> >>>> for the time being to allow me to finish this consolidation then I > >> can not > >> >>>> rush it as much > >> >>>> > >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > >> wrote: > >> >>>> > >> >>>>> I have to concur with Sanne, a hold on master pushes until this > >> merge of > >> >>>>> artifacts is complete makes the most sense from an all around > >> logistics > >> >>>>> perspective. > >> >>>>> > >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should > we > >> >>>>>> temporarily disable complaint emails from Jenkins, or even the > full > >> >>>>>> build tasks? > >> >>>>>> > >> >>>>>> Also, this implies that any future backport becomes similarly > >> harder, > >> >>>>>> so you could also simply ask others to hold pushing on master, > then > >> >>>>>> have people forward-port when it's done.. it's the same really > but > >> >>>>>> that's why I mention it: as the complexity is interchangeable > it's > >> a > >> >>>>>> fair request, with the difference you have: > >> >>>>>> - others help you port the other patches forward rather than > >> doing it > >> >>>>> all > >> >>>>>> alone > >> >>>>>> - the authors of the original patch doing it, that should make > >> it a > >> >>>> bit > >> >>>>>> simpler > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole > >> wrote: > >> >>>>>>> Obviously consolidating hibernate-entitymanager into > >> hibernate-core > >> >>>> is > >> >>>>> a > >> >>>>>>> fairly big effort. And I am getting concerned about the > >> continuing > >> >>>>>> pushes > >> >>>>>>> to master in the meantime, many of which I know touch on code I > >> have > >> >>>>>>> changed. My concern is obviously getting done all this > >> refactoring > >> >>>>> work > >> >>>>>>> and then having to sift through all of the changes that have > been > >> >>>>> pushed > >> >>>>>> in > >> >>>>>>> the interim and attempting to work out the proper integration > >> >>>> strategy. > >> >>>>>>> > >> >>>>>>> Long story short... I am contemplating pushing to master sooner > >> >>>> rather > >> >>>>>> than > >> >>>>>>> later even though my refactoring may not be completely finished, > >> >>>>>> especially > >> >>>>>>> as we get towards the end of the week. > >> >>>>>>> _______________________________________________ > >> >>>>>>> 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 > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Wed Apr 13 02:54:42 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 13 Apr 2016 08:54:42 +0200 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: 2016-04-13 0:48 GMT+02:00 Steve Ebersole : > Another question as I work through Query... > > Currently both Session and StatelessSession inherit the same query creation > methods (returning org.hibernate.Query) via SharedSessionContract (which is > the common base type between them). There is therefore an inherent > difficulty in having org.hibernate.Query extend from the JPA > javax.persistence.Query/TypedQuery when we only want Session to be an > EntityManager, not StatelessSession. > > The simplest solution is to: > > 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and > move all of the existing SharedSessionContract query creation methods > returning org.hibernate.Query directly to StatelessSession > 2. develop a new org.hibernate.query.Query (prefacing 6.0) that > provides some of the "legacy Hibernate query contract" and extends > from > javax.persistence.Query. Directly on Session we'd write new methods > with > the same name and args but returning this org.hibernate.query.Query. > > This would give us 2 distinct Query hierarchies and allow the underlying > goal of Session extending EntityManager, but not StatelessSession. We > could also flip these based on the knowledge that Session is more widely > used (less disruptive). > > In other words we'd go from both Session and StatelessSession returning > org.hibernate.Query via inheriting from SharedSessionContract: > > public interface SharedSessionContract { > ... > org.hibernate.Query createQuery(String hql); > } > > > to each Session and StatelessSession implementing different methods > altogether: > > public interface StatelessSession { > ... > org.hibernate.Query createQuery(String hql); > } > > public interface Session { > ... > org.hibernate.query.Query createQuery(String hql); > } > > > Unifying these returns across Session and StatelessSession would require > StatelessSession also being an EntityManager. I had decided against that > for the same reasons that StatelessSession is distinct from Session. > Why would it require StatelessSession to extend EntityManager? Both, StatelessSession and Session could define the same method, also if not being part of the same hierarchy. I'm concerned about the two Query types with the same simple name, users may be easily confused which one to import. Maybe a hybrid approach would be to break the query creation methods out of > SharedSessionContract into a new targeted interface named QueryProducer > which both Session and StatelessSession would implement. That would allow > unifying the query creation return to something that implements JPA Query > contract too, but the source (Session/StatelessSession via QueryProducer) > would not necessarily need to implement EntityManager. > > > I think the QueryProducer route is probably the best option in terms of > allowing the consolidation but still allowing users to upgrade easily. > > Thoughts? Other options? Hopefully I explained it well enough :) > Something related; If you are touching these bits, could you rename createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery? That'd give a much better experience for users of Hibernate OGM which otherwise wonder how SQL queries relate to their chosen NoSQL store. createNativeQuery() makes that smoother. On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole wrote: > > > Just a quick update on my progress. I pretty much have > > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted out > as > > well as bootstrapping. > > > > I am currently working through the different Query hierarchies. > > > > Looking at what is left, I hope to be done with all of this by Thursday > > > > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero > wrote: > > > >> On 8 April 2016 at 15:04, Scott Marlow wrote: > >> > I'm curious if Search/OGM master branches would likely align with 5.2? > >> > Or some other branch? > >> > >> Good question, time for an update on these. > >> > >> We'll certainly have a version of Search compatible, at some point. > >> Not sure though about which version that shall be as we want to be > >> feature complete with our Elasticsearch work, and that will take a > >> couple more months at least so we'll see a bit longer than usual gap > >> between stable releases. > >> > >> Generally speaking we need at least a minor release for OGM or Search > >> to happen to upgrade the minor of ORM. > >> Since we didn't release yet, Search is still building with ORM 5.0.x > >> as a target.. we can then decide if we should skip ORM 5.1 and jump to > >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As > >> far as I know only some test helpers broke though, so while I couldn't > >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are > >> compatible at runtime and we also expect to be compatible with ORM > >> 5.2. > >> > >> With OGM we're now in candidate release phase for a ORM 5.0 compatible > >> version so not really thinking to bump it to ORM 5.1 yet. > >> > >> OGM tends to release less frequently, so in this case it is possible > >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, > >> but we can work on aiming a specific version if and when need arises. > >> > >> If you need any of these aligned let us know? > >> > >> Thanks, > >> Sanne > >> > >> > > >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: > >> >> As a follow up to this... > >> >> > >> >> Sanne had a great suggestion on HipChat. What about turning all this > >> work > >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea > would > >> be > >> >> 5.2 would include: > >> >> > >> >> 1. Move to Java 8 > >> >> 2. Consolidation of hibernate-entitymanager into hibernate-core > >> >> 3. Deprecations, lots of deprecations :) > >> >> > >> >> > >> >> The idea is that then we could start 6.0 off "clean" by removing all > >> the > >> >> deprecations and layering in SQM work. > >> >> > >> >> > >> >> > >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < > mihalcea.vlad at gmail.com > >> > > >> >> wrote: > >> >> > >> >>> Hi, > >> >>> > >> >>> Until the merge is done, I'll take a break integrating the PRs that > >> are > >> >>> also relevant to the master branch. > >> >>> > >> >>> Vlad > >> >>> > >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > > >> >>> wrote: > >> >>> > >> >>>> I agree that would be best. If everyone agrees to stop pushing to > >> master > >> >>>> for the time being to allow me to finish this consolidation then I > >> can not > >> >>>> rush it as much > >> >>>> > >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > >> wrote: > >> >>>> > >> >>>>> I have to concur with Sanne, a hold on master pushes until this > >> merge of > >> >>>>> artifacts is complete makes the most sense from an all around > >> logistics > >> >>>>> perspective. > >> >>>>> > >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > >> sanne at hibernate.org> > >> >>>>> wrote: > >> >>>>> > >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. should > we > >> >>>>>> temporarily disable complaint emails from Jenkins, or even the > full > >> >>>>>> build tasks? > >> >>>>>> > >> >>>>>> Also, this implies that any future backport becomes similarly > >> harder, > >> >>>>>> so you could also simply ask others to hold pushing on master, > then > >> >>>>>> have people forward-port when it's done.. it's the same really > but > >> >>>>>> that's why I mention it: as the complexity is interchangeable > it's > >> a > >> >>>>>> fair request, with the difference you have: > >> >>>>>> - others help you port the other patches forward rather than > >> doing it > >> >>>>> all > >> >>>>>> alone > >> >>>>>> - the authors of the original patch doing it, that should make > >> it a > >> >>>> bit > >> >>>>>> simpler > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole > >> wrote: > >> >>>>>>> Obviously consolidating hibernate-entitymanager into > >> hibernate-core > >> >>>> is > >> >>>>> a > >> >>>>>>> fairly big effort. And I am getting concerned about the > >> continuing > >> >>>>>> pushes > >> >>>>>>> to master in the meantime, many of which I know touch on code I > >> have > >> >>>>>>> changed. My concern is obviously getting done all this > >> refactoring > >> >>>>> work > >> >>>>>>> and then having to sift through all of the changes that have > been > >> >>>>> pushed > >> >>>>>> in > >> >>>>>>> the interim and attempting to work out the proper integration > >> >>>> strategy. > >> >>>>>>> > >> >>>>>>> Long story short... I am contemplating pushing to master sooner > >> >>>> rather > >> >>>>>> than > >> >>>>>>> later even though my refactoring may not be completely finished, > >> >>>>>> especially > >> >>>>>>> as we get towards the end of the week. > >> >>>>>>> _______________________________________________ > >> >>>>>>> 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 > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Wed Apr 13 03:01:18 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 13 Apr 2016 09:01:18 +0200 Subject: [hibernate-dev] A warmup task: HSEARCH-2207 In-Reply-To: References: Message-ID: Hey Mincong, Nice! Looking forward to your pull request for this issue very much. Thanks, --Gunnar 2016-04-13 1:32 GMT+02:00 Sanne Grinovero : > Hi Mincong, > great start! > > I've added you to the right groups on JIRA, so now HSEARCH-2207 is > assigned to you. > > To be allowed to send emails to the hibernate dev mailinst list you > have to register first: > - https://lists.jboss.org/mailman/listinfo/hibernate-dev > > Thanks, > Sanne > > > On 12 April 2016 at 22:55, Mincong Huang wrote: > > Hi Sanne ant Gunner, > > > > Concerned with the issue HSEARCH-2207, I'm studying on it. > > > > I created a demo and write a blog about boolean query in Apache Lucene. > > As for Hibernate Search, I still not start learning it. I'll probably > start > > this weekend. > > For instant, my priority is to understand the index, query and analyzer > in > > Lucene. > > > > My JIRA account is mincong.h at gmail.com > > > > I'm not allowed to send email to hibernate dev list, so it isn't in cc. > > > > Cheers, > > Mincong > > > > > > > > > > On Sat, Apr 9, 2016 at 8:27 PM, Mincong Huang > wrote: > >> > >> Hi Sanne, > >> > >> Thanks for your email. No, it won't be boring at all. On the contrary, > >> this will be a great beginning ! > >> I'll take a look on the issue and keep you informed. As for the JIRA > >> account, here's the mine : > >> mincong.h at gmail.com > >> > >> Cheers, > >> Mincong > >> > >> > >> On Fri, Apr 8, 2016 at 2:35 PM, Sanne Grinovero > >> wrote: > >>> > >>> Hi Mincong, > >>> > >>> Gunnar suggested that I find a first task for you to familiarize with > >>> the project, and to have you practice the process of creating patches > >>> and proposing them for integration over GitHub. > >>> > >>> I think this issue could be suited: > >>> - https://hibernate.atlassian.net/browse/HSEARCH-2207 > >>> > >>> I hope it's not too boring! It's not just an exercise, we need that > >>> done so it would be a valuable contribution already. > >>> > >>> Do you have an account on our JIRA server? If not create one, then let > >>> me know your user id so I can assign the issue to you. > >>> > >>> Thanks, > >>> Sanne > >> > >> > > > From mihalcea.vlad at gmail.com Wed Apr 13 04:52:27 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 13 Apr 2016 11:52:27 +0300 Subject: [hibernate-dev] GitHub PR management In-Reply-To: References: Message-ID: Hi, I went through all PR and applied labels on all items. This way it's much easier to start reviewing issues because they are categorized. Let me know what you think. Vlad On Tue, Apr 12, 2016 at 5:08 PM, andrea boriero wrote: > +1 > > On 12 April 2016 at 14:56, Vlad Mihalcea wrote: > >> Hi, >> >> Both Andrea and I have been going through the current list of PR, and I >> think it is a good idea to start labeling them. >> Some issues are trivial and can be integrated as soon as we can commit on >> the master. >> >> I think we should add the following labels: >> >> - Needs CLA >> - Needs Jira >> - Needs Test Case >> - Envers >> - 4.2 >> - 4.3 >> - 5.0 >> - 5.1 >> >> This way we can easily navigate through them. >> >> Vlad >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From mihalcea.vlad at gmail.com Wed Apr 13 07:18:12 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 13 Apr 2016 14:18:12 +0300 Subject: [hibernate-dev] PR without CLA Message-ID: Hi, I managed to get a list of PR without CLA. I asked them if they signed it, but didn't get any response back. Steve, if you can check them in the system, I'll update the PR status for the ones that have signed the agreement. https://github.com/hibernate/hibernate-orm/labels/Requires%20CLA Otherwise, what shall we do with all those PRs? Vlad From gunnar at hibernate.org Wed Apr 13 09:54:43 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 13 Apr 2016 15:54:43 +0200 Subject: [hibernate-dev] [HSEARCH] Scope of the first version with ES support Message-ID: Hey, I'd like to achieve clarity and agreement on the scope of HSEARCH 5.6, the first release with support for the Elasticsearch indexing backend. I suggest we limit ourselves to the essential things making the backend actually usable and release it as a "technology preview" as of 5.6.0.Final. Everything not needed for that goal I'd move to subsequent releases (5.7, 6.0), the motivation being that we should not kill the vibe and deliver something real soon. Some candidates for moving over I see: * "Define analyzers via the REST API (HSEARCH-2219 )": Users can create the needed analyzers themselves * "Consider using the fields feature of Elasticsearch for properties mapped on several fields" (HSEARCH-2215 ): Seems scheduled as a "reminder" only anways? * "Use the Elasticsearch Scroll API when fetching large result sets" ( HSEARCH-2128 ): Seems not strictly needed * "Map the optimize() operation to Elasticsearch 'force merge' requests" ( HSEARCH-2092 ): Manual requests possible as a work-around * Likely some others Things we *should* do are most mapping-related issues, documentation and apparent perf issues (massing indexing, avoid too frequent refreshing). The public interest in the subject seemed good, so I'd prefer if we can ship a "Final" version soon in MVP-style. As it seems, a "final" tech preview is less scary to people than an Alpha/Beta. Let's hone the bits it in subsequent releases, rather than working on the first Final for a long time. Any thoughts? --Gunnar From mihalcea.vlad at gmail.com Thu Apr 14 04:00:07 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 14 Apr 2016 11:00:07 +0300 Subject: [hibernate-dev] Regarding new Dialects Message-ID: Hi, We have another Dialect coming as a pull request: https://github.com/hibernate/hibernate-orm/pull/1330 In my opinion, we should integrate new Dialects and just document which ones are maintained by us, and which ones are under development by other parties. For the Altibase database, the Dialect was sent by an Altibase employee, so it is their interest to maintain it as well. Vlad From steve at hibernate.org Fri Apr 15 09:30:07 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 15 Apr 2016 13:30:07 +0000 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: So here is what I ended up doing, with one questionable decision which I'll highlight below. First, the existing situation... We have Session and StatelessSession which are largely independent contracts. There is a "shared" bit that is represented by an interface SharedSessionContract. There is also a SessionImplementor contract. Now previously a SessionImplementor could be a Session or a StatelessSession; very poorly named. SessionImplementor is poorly named. Following the normal *Implementor naming convention we follow every else in the code base a SessionImplementor ought to be the internal contract for a Session. But that's not what it is today. Really SessionImplementor as it exists today is the *Implementor for SharedSessionContract. So I normalized this. I created a SharedSessionContractImplementor contract that extends SharedSessionContract. SessionImplementor then extends SharedSessionContractImplementor. However this is the "questionable" part because that means changing an awful lot of SPI methods to accept/return SharedSessionContractImplementor as opposed to SessionImplementor. So in terms of API, we have: SharedSessionContract <- (Session & StatelessSession) In terms of SPI, we have: SharedSessionContractImplementor <- (Session Implementor & StatelessSessionImplementor) As far as Query object creation, SharedSessionContract also fulfills the role of (extends) the QueryProducer contract which defines a unified set of methods that cover the JPA cases without having to implement EntityManager. ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It will still have to deal with procedure/function calls. Eventually in 6.0 it will have to deal with criteria queries as well. Gunnar to your specific question about naming, yes. I had already started on that path actually. So in terms of API contracts we have: - org.hibernate.query.Query - org.hibernate.query.NativeQuery extends org.hibernate.query.Query Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I can't remove them in a 5.2 release. However I have deprecated them as scheduled them for removal in 6.0. This follows the typical "shadow" approach we have followed before for deprecating APIs. org.hibernate.query.Query extends the deprecated org.hibernate.Query and org.hibernate.query.NativeQuery extends the deprecated org.hibernate.SQLQuery. That allows existing code to continue to work with deprecation warnings. Users can chose to migrate to the new contracts in moving to 5.2 or at least know that is a task in upgrading to 6.0. I'd love some votes on the SessionImplementor/SharedSessionContractImplementor point above. There are other, less disruptive ways to do that; I just think this is the most correct way. Some other options include more fully distinguishing between a "stateful" and a "stateless" Session - then SessionImplementor term fits better as we'd have StatefulSessionImplementor and StatelessSessionImplementor variants. I really dislike the phrases stateful and stateless here though. Anyway, let me know what y'all think. On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling wrote: > 2016-04-13 0:48 GMT+02:00 Steve Ebersole : > >> Another question as I work through Query... >> >> Currently both Session and StatelessSession inherit the same query >> creation >> methods (returning org.hibernate.Query) via SharedSessionContract (which >> is >> the common base type between them). There is therefore an inherent >> difficulty in having org.hibernate.Query extend from the JPA >> javax.persistence.Query/TypedQuery when we only want Session to be an >> EntityManager, not StatelessSession. >> >> The simplest solution is to: >> >> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" and > > >> move all of the existing SharedSessionContract query creation >> methods >> returning org.hibernate.Query directly to StatelessSession >> > 2. develop a new org.hibernate.query.Query (prefacing 6.0) that > > >> provides some of the "legacy Hibernate query contract" and extends >> from >> javax.persistence.Query. Directly on Session we'd write new >> methods with >> the same name and args but returning this org.hibernate.query.Query. >> >> This would give us 2 distinct Query hierarchies and allow the underlying >> goal of Session extending EntityManager, but not StatelessSession. We >> could also flip these based on the knowledge that Session is more widely >> used (less disruptive). >> >> In other words we'd go from both Session and StatelessSession returning >> org.hibernate.Query via inheriting from SharedSessionContract: >> >> public interface SharedSessionContract { >> ... >> org.hibernate.Query createQuery(String hql); >> } >> >> >> to each Session and StatelessSession implementing different methods >> altogether: >> >> public interface StatelessSession { >> ... >> org.hibernate.Query createQuery(String hql); >> } >> >> public interface Session { >> ... >> org.hibernate.query.Query createQuery(String hql); >> } >> >> >> Unifying these returns across Session and StatelessSession would require >> StatelessSession also being an EntityManager. I had decided against that >> for the same reasons that StatelessSession is distinct from Session. >> > > Why would it require StatelessSession to extend EntityManager? Both, > StatelessSession and Session could define the same method, also if not > being part of the same hierarchy. > > I'm concerned about the two Query types with the same simple name, users > may be easily confused which one to import. > > Maybe a hybrid approach would be to break the query creation methods out of >> SharedSessionContract into a new targeted interface named QueryProducer >> which both Session and StatelessSession would implement. That would allow >> unifying the query creation return to something that implements JPA Query >> contract too, but the source (Session/StatelessSession via QueryProducer) >> would not necessarily need to implement EntityManager. >> >> >> I think the QueryProducer route is probably the best option in terms of >> allowing the consolidation but still allowing users to upgrade easily. >> >> Thoughts? Other options? Hopefully I explained it well enough :) >> > > Something related; If you are touching these bits, could you rename > createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery? > That'd give a much better experience for users of Hibernate OGM which > otherwise wonder how SQL queries relate to their chosen NoSQL store. > createNativeQuery() makes that smoother. > > On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole >> wrote: >> >> > Just a quick update on my progress. I pretty much have >> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted >> out as >> > well as bootstrapping. >> > >> > I am currently working through the different Query hierarchies. >> > >> > Looking at what is left, I hope to be done with all of this by Thursday >> > >> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero >> wrote: >> > >> >> On 8 April 2016 at 15:04, Scott Marlow wrote: >> >> > I'm curious if Search/OGM master branches would likely align with >> 5.2? >> >> > Or some other branch? >> >> >> >> Good question, time for an update on these. >> >> >> >> We'll certainly have a version of Search compatible, at some point. >> >> Not sure though about which version that shall be as we want to be >> >> feature complete with our Elasticsearch work, and that will take a >> >> couple more months at least so we'll see a bit longer than usual gap >> >> between stable releases. >> >> >> >> Generally speaking we need at least a minor release for OGM or Search >> >> to happen to upgrade the minor of ORM. >> >> Since we didn't release yet, Search is still building with ORM 5.0.x >> >> as a target.. we can then decide if we should skip ORM 5.1 and jump to >> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As >> >> far as I know only some test helpers broke though, so while I couldn't >> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are >> >> compatible at runtime and we also expect to be compatible with ORM >> >> 5.2. >> >> >> >> With OGM we're now in candidate release phase for a ORM 5.0 compatible >> >> version so not really thinking to bump it to ORM 5.1 yet. >> >> >> >> OGM tends to release less frequently, so in this case it is possible >> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, >> >> but we can work on aiming a specific version if and when need arises. >> >> >> >> If you need any of these aligned let us know? >> >> >> >> Thanks, >> >> Sanne >> >> >> >> > >> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: >> >> >> As a follow up to this... >> >> >> >> >> >> Sanne had a great suggestion on HipChat. What about turning all >> this >> >> work >> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea >> would >> >> be >> >> >> 5.2 would include: >> >> >> >> >> >> 1. Move to Java 8 >> >> >> 2. Consolidation of hibernate-entitymanager into hibernate-core >> >> >> 3. Deprecations, lots of deprecations :) >> >> >> >> >> >> >> >> >> The idea is that then we could start 6.0 off "clean" by removing all >> >> the >> >> >> deprecations and layering in SQM work. >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < >> mihalcea.vlad at gmail.com >> >> > >> >> >> wrote: >> >> >> >> >> >>> Hi, >> >> >>> >> >> >>> Until the merge is done, I'll take a break integrating the PRs that >> >> are >> >> >>> also relevant to the master branch. >> >> >>> >> >> >>> Vlad >> >> >>> >> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole < >> steve at hibernate.org> >> >> >>> wrote: >> >> >>> >> >> >>>> I agree that would be best. If everyone agrees to stop pushing to >> >> master >> >> >>>> for the time being to allow me to finish this consolidation then I >> >> can not >> >> >>>> rush it as much >> >> >>>> >> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > > >> >> wrote: >> >> >>>> >> >> >>>>> I have to concur with Sanne, a hold on master pushes until this >> >> merge of >> >> >>>>> artifacts is complete makes the most sense from an all around >> >> logistics >> >> >>>>> perspective. >> >> >>>>> >> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < >> >> sanne at hibernate.org> >> >> >>>>> wrote: >> >> >>>>> >> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. >> should we >> >> >>>>>> temporarily disable complaint emails from Jenkins, or even the >> full >> >> >>>>>> build tasks? >> >> >>>>>> >> >> >>>>>> Also, this implies that any future backport becomes similarly >> >> harder, >> >> >>>>>> so you could also simply ask others to hold pushing on master, >> then >> >> >>>>>> have people forward-port when it's done.. it's the same really >> but >> >> >>>>>> that's why I mention it: as the complexity is interchangeable >> it's >> >> a >> >> >>>>>> fair request, with the difference you have: >> >> >>>>>> - others help you port the other patches forward rather than >> >> doing it >> >> >>>>> all >> >> >>>>>> alone >> >> >>>>>> - the authors of the original patch doing it, that should make >> >> it a >> >> >>>> bit >> >> >>>>>> simpler >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole >> >> wrote: >> >> >>>>>>> Obviously consolidating hibernate-entitymanager into >> >> hibernate-core >> >> >>>> is >> >> >>>>> a >> >> >>>>>>> fairly big effort. And I am getting concerned about the >> >> continuing >> >> >>>>>> pushes >> >> >>>>>>> to master in the meantime, many of which I know touch on code I >> >> have >> >> >>>>>>> changed. My concern is obviously getting done all this >> >> refactoring >> >> >>>>> work >> >> >>>>>>> and then having to sift through all of the changes that have >> been >> >> >>>>> pushed >> >> >>>>>> in >> >> >>>>>>> the interim and attempting to work out the proper integration >> >> >>>> strategy. >> >> >>>>>>> >> >> >>>>>>> Long story short... I am contemplating pushing to master sooner >> >> >>>> rather >> >> >>>>>> than >> >> >>>>>>> later even though my refactoring may not be completely >> finished, >> >> >>>>>> especially >> >> >>>>>>> as we get towards the end of the week. >> >> >>>>>>> _______________________________________________ >> >> >>>>>>> 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 >> >> >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > From andrea at hibernate.org Fri Apr 15 10:33:02 2016 From: andrea at hibernate.org (andrea boriero) Date: Fri, 15 Apr 2016 15:33:02 +0100 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: +1 SharedSessionContractImplementor <- (Session Implementor & StatelessSessionImplementor) On 15 April 2016 at 14:30, Steve Ebersole wrote: > So here is what I ended up doing, with one questionable decision which I'll > highlight below. > > First, the existing situation... We have Session and StatelessSession > which are largely independent contracts. There is a "shared" bit that is > represented by an interface SharedSessionContract. There is also a > SessionImplementor contract. Now previously a SessionImplementor could be > a Session or a StatelessSession; very poorly named. > > SessionImplementor is poorly named. Following the normal *Implementor > naming convention we follow every else in the code base a > SessionImplementor > ought to be the internal contract for a Session. But that's not what it is > today. Really SessionImplementor as it exists today is the *Implementor > for SharedSessionContract. So I normalized this. I created a > SharedSessionContractImplementor > contract that extends SharedSessionContract. SessionImplementor then > extends SharedSessionContractImplementor. However this is the > "questionable" part because that means changing an awful lot of SPI methods > to accept/return SharedSessionContractImplementor as opposed to > SessionImplementor. > > So in terms of API, we have: SharedSessionContract <- (Session & > StatelessSession) > In terms of SPI, we have: SharedSessionContractImplementor <- (Session > Implementor & StatelessSessionImplementor) > > As far as Query object creation, SharedSessionContract also fulfills the > role of (extends) the QueryProducer contract which defines a unified set of > methods that cover the JPA cases without having to implement > EntityManager. ATM QueryProducer covers HQL/JPQL and Native (SQL) > queries. For 5.2 It will still have to deal with procedure/function > calls. Eventually in 6.0 it will have to deal with criteria queries as > well. > > Gunnar to your specific question about naming, yes. I had already started > on that path actually. So in terms of API contracts we have: > > - org.hibernate.query.Query > - org.hibernate.query.NativeQuery extends org.hibernate.query.Query > > Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I > can't remove them in a 5.2 release. However I have deprecated them as > scheduled them for removal in 6.0. This follows the typical "shadow" > approach we have followed before for deprecating APIs. > org.hibernate.query.Query > extends the deprecated org.hibernate.Query and > org.hibernate.query.NativeQuery > extends the deprecated org.hibernate.SQLQuery. That allows existing code > to continue to work with deprecation warnings. Users can chose to migrate > to the new contracts in moving to 5.2 or at least know that is a task in > upgrading to 6.0. > > I'd love some votes on the > SessionImplementor/SharedSessionContractImplementor > point above. There are other, less disruptive ways to do that; I just > think this is the most correct way. Some other options include more fully > distinguishing between a "stateful" and a "stateless" Session - then > SessionImplementor term fits better as we'd have StatefulSessionImplementor > and StatelessSessionImplementor variants. I really dislike the phrases > stateful and stateless here though. Anyway, let me know what y'all think. > > On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling > wrote: > > > 2016-04-13 0:48 GMT+02:00 Steve Ebersole : > > > >> Another question as I work through Query... > >> > >> Currently both Session and StatelessSession inherit the same query > >> creation > >> methods (returning org.hibernate.Query) via SharedSessionContract (which > >> is > >> the common base type between them). There is therefore an inherent > >> difficulty in having org.hibernate.Query extend from the JPA > >> javax.persistence.Query/TypedQuery when we only want Session to be an > >> EntityManager, not StatelessSession. > >> > >> The simplest solution is to: > >> > >> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" > and > > > > > >> move all of the existing SharedSessionContract query creation > >> methods > >> returning org.hibernate.Query directly to StatelessSession > >> > > 2. develop a new org.hibernate.query.Query (prefacing 6.0) that > > > > > >> provides some of the "legacy Hibernate query contract" and extends > >> from > >> javax.persistence.Query. Directly on Session we'd write new > >> methods with > >> the same name and args but returning this > org.hibernate.query.Query. > >> > >> This would give us 2 distinct Query hierarchies and allow the underlying > >> goal of Session extending EntityManager, but not StatelessSession. We > >> could also flip these based on the knowledge that Session is more widely > >> used (less disruptive). > >> > >> In other words we'd go from both Session and StatelessSession returning > >> org.hibernate.Query via inheriting from SharedSessionContract: > >> > >> public interface SharedSessionContract { > >> ... > >> org.hibernate.Query createQuery(String hql); > >> } > >> > >> > >> to each Session and StatelessSession implementing different methods > >> altogether: > >> > >> public interface StatelessSession { > >> ... > >> org.hibernate.Query createQuery(String hql); > >> } > >> > >> public interface Session { > >> ... > >> org.hibernate.query.Query createQuery(String hql); > >> } > >> > >> > >> Unifying these returns across Session and StatelessSession would require > >> StatelessSession also being an EntityManager. I had decided against > that > >> for the same reasons that StatelessSession is distinct from Session. > >> > > > > Why would it require StatelessSession to extend EntityManager? Both, > > StatelessSession and Session could define the same method, also if not > > being part of the same hierarchy. > > > > I'm concerned about the two Query types with the same simple name, users > > may be easily confused which one to import. > > > > Maybe a hybrid approach would be to break the query creation methods out > of > >> SharedSessionContract into a new targeted interface named QueryProducer > >> which both Session and StatelessSession would implement. That would > allow > >> unifying the query creation return to something that implements JPA > Query > >> contract too, but the source (Session/StatelessSession via > QueryProducer) > >> would not necessarily need to implement EntityManager. > >> > >> > >> I think the QueryProducer route is probably the best option in terms of > >> allowing the consolidation but still allowing users to upgrade easily. > >> > >> Thoughts? Other options? Hopefully I explained it well enough :) > >> > > > > Something related; If you are touching these bits, could you rename > > createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery? > > That'd give a much better experience for users of Hibernate OGM which > > otherwise wonder how SQL queries relate to their chosen NoSQL store. > > createNativeQuery() makes that smoother. > > > > On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole > >> wrote: > >> > >> > Just a quick update on my progress. I pretty much have > >> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted > >> out as > >> > well as bootstrapping. > >> > > >> > I am currently working through the different Query hierarchies. > >> > > >> > Looking at what is left, I hope to be done with all of this by > Thursday > >> > > >> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero > >> wrote: > >> > > >> >> On 8 April 2016 at 15:04, Scott Marlow wrote: > >> >> > I'm curious if Search/OGM master branches would likely align with > >> 5.2? > >> >> > Or some other branch? > >> >> > >> >> Good question, time for an update on these. > >> >> > >> >> We'll certainly have a version of Search compatible, at some point. > >> >> Not sure though about which version that shall be as we want to be > >> >> feature complete with our Elasticsearch work, and that will take a > >> >> couple more months at least so we'll see a bit longer than usual gap > >> >> between stable releases. > >> >> > >> >> Generally speaking we need at least a minor release for OGM or Search > >> >> to happen to upgrade the minor of ORM. > >> >> Since we didn't release yet, Search is still building with ORM 5.0.x > >> >> as a target.. we can then decide if we should skip ORM 5.1 and jump > to > >> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As > >> >> far as I know only some test helpers broke though, so while I > couldn't > >> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they > are > >> >> compatible at runtime and we also expect to be compatible with ORM > >> >> 5.2. > >> >> > >> >> With OGM we're now in candidate release phase for a ORM 5.0 > compatible > >> >> version so not really thinking to bump it to ORM 5.1 yet. > >> >> > >> >> OGM tends to release less frequently, so in this case it is possible > >> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, > >> >> but we can work on aiming a specific version if and when need arises. > >> >> > >> >> If you need any of these aligned let us know? > >> >> > >> >> Thanks, > >> >> Sanne > >> >> > >> >> > > >> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: > >> >> >> As a follow up to this... > >> >> >> > >> >> >> Sanne had a great suggestion on HipChat. What about turning all > >> this > >> >> work > >> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea > >> would > >> >> be > >> >> >> 5.2 would include: > >> >> >> > >> >> >> 1. Move to Java 8 > >> >> >> 2. Consolidation of hibernate-entitymanager into > hibernate-core > >> >> >> 3. Deprecations, lots of deprecations :) > >> >> >> > >> >> >> > >> >> >> The idea is that then we could start 6.0 off "clean" by removing > all > >> >> the > >> >> >> deprecations and layering in SQM work. > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea < > >> mihalcea.vlad at gmail.com > >> >> > > >> >> >> wrote: > >> >> >> > >> >> >>> Hi, > >> >> >>> > >> >> >>> Until the merge is done, I'll take a break integrating the PRs > that > >> >> are > >> >> >>> also relevant to the master branch. > >> >> >>> > >> >> >>> Vlad > >> >> >>> > >> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole < > >> steve at hibernate.org> > >> >> >>> wrote: > >> >> >>> > >> >> >>>> I agree that would be best. If everyone agrees to stop pushing > to > >> >> master > >> >> >>>> for the time being to allow me to finish this consolidation > then I > >> >> can not > >> >> >>>> rush it as much > >> >> >>>> > >> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford < > crancran at gmail.com > >> > > >> >> wrote: > >> >> >>>> > >> >> >>>>> I have to concur with Sanne, a hold on master pushes until this > >> >> merge of > >> >> >>>>> artifacts is complete makes the most sense from an all around > >> >> logistics > >> >> >>>>> perspective. > >> >> >>>>> > >> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > >> >> sanne at hibernate.org> > >> >> >>>>> wrote: > >> >> >>>>> > >> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. > >> should we > >> >> >>>>>> temporarily disable complaint emails from Jenkins, or even the > >> full > >> >> >>>>>> build tasks? > >> >> >>>>>> > >> >> >>>>>> Also, this implies that any future backport becomes similarly > >> >> harder, > >> >> >>>>>> so you could also simply ask others to hold pushing on master, > >> then > >> >> >>>>>> have people forward-port when it's done.. it's the same really > >> but > >> >> >>>>>> that's why I mention it: as the complexity is interchangeable > >> it's > >> >> a > >> >> >>>>>> fair request, with the difference you have: > >> >> >>>>>> - others help you port the other patches forward rather than > >> >> doing it > >> >> >>>>> all > >> >> >>>>>> alone > >> >> >>>>>> - the authors of the original patch doing it, that should > make > >> >> it a > >> >> >>>> bit > >> >> >>>>>> simpler > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole > > >> >> wrote: > >> >> >>>>>>> Obviously consolidating hibernate-entitymanager into > >> >> hibernate-core > >> >> >>>> is > >> >> >>>>> a > >> >> >>>>>>> fairly big effort. And I am getting concerned about the > >> >> continuing > >> >> >>>>>> pushes > >> >> >>>>>>> to master in the meantime, many of which I know touch on > code I > >> >> have > >> >> >>>>>>> changed. My concern is obviously getting done all this > >> >> refactoring > >> >> >>>>> work > >> >> >>>>>>> and then having to sift through all of the changes that have > >> been > >> >> >>>>> pushed > >> >> >>>>>> in > >> >> >>>>>>> the interim and attempting to work out the proper integration > >> >> >>>> strategy. > >> >> >>>>>>> > >> >> >>>>>>> Long story short... I am contemplating pushing to master > sooner > >> >> >>>> rather > >> >> >>>>>> than > >> >> >>>>>>> later even though my refactoring may not be completely > >> finished, > >> >> >>>>>> especially > >> >> >>>>>>> as we get towards the end of the week. > >> >> >>>>>>> _______________________________________________ > >> >> >>>>>>> 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 > >> >> > >> > > >> _______________________________________________ > >> 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 Fri Apr 15 10:46:11 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 15 Apr 2016 16:46:11 +0200 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: Do you have a practical need for SharedSessionContract and SharedSessionContractImplementor to exist within the internal contracts of ORM? As a general rule, I don't mind having implementations which implement multiple interfaces. Assuming you need these as a convenience for internal helpers, then I'd propose to treat these as internal interfaces rather than APIs or SPIs. For example, have users deal just with "Session" and "StatelessSession" and not need learning (nor bothering) with more stuff. my 2 cents.. not a strong opinion. Sanne On 15 April 2016 at 15:30, Steve Ebersole wrote: > So here is what I ended up doing, with one questionable decision which I'll > highlight below. > > First, the existing situation... We have Session and StatelessSession which > are largely independent contracts. There is a "shared" bit that is > represented by an interface SharedSessionContract. There is also a > SessionImplementor contract. Now previously a SessionImplementor could be a > Session or a StatelessSession; very poorly named. > > SessionImplementor is poorly named. Following the normal *Implementor > naming convention we follow every else in the code base a SessionImplementor > ought to be the internal contract for a Session. But that's not what it is > today. Really SessionImplementor as it exists today is the *Implementor for > SharedSessionContract. So I normalized this. I created a > SharedSessionContractImplementor contract that extends > SharedSessionContract. SessionImplementor then extends > SharedSessionContractImplementor. However this is the "questionable" part > because that means changing an awful lot of SPI methods to accept/return > SharedSessionContractImplementor as opposed to SessionImplementor. > > So in terms of API, we have: SharedSessionContract <- (Session & > StatelessSession) > In terms of SPI, we have: SharedSessionContractImplementor <- > (SessionImplementor & StatelessSessionImplementor) > > As far as Query object creation, SharedSessionContract also fulfills the > role of (extends) the QueryProducer contract which defines a unified set of > methods that cover the JPA cases without having to implement EntityManager. > ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It will > still have to deal with procedure/function calls. Eventually in 6.0 it will > have to deal with criteria queries as well. > > Gunnar to your specific question about naming, yes. I had already started > on that path actually. So in terms of API contracts we have: > > org.hibernate.query.Query > org.hibernate.query.NativeQuery extends org.hibernate.query.Query > > Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I > can't remove them in a 5.2 release. However I have deprecated them as > scheduled them for removal in 6.0. This follows the typical "shadow" > approach we have followed before for deprecating APIs. > org.hibernate.query.Query extends the deprecated org.hibernate.Query and > org.hibernate.query.NativeQuery extends the deprecated > org.hibernate.SQLQuery. That allows existing code to continue to work with > deprecation warnings. Users can chose to migrate to the new contracts in > moving to 5.2 or at least know that is a task in upgrading to 6.0. > > I'd love some votes on the > SessionImplementor/SharedSessionContractImplementor point above. There are > other, less disruptive ways to do that; I just think this is the most > correct way. Some other options include more fully distinguishing between a > "stateful" and a "stateless" Session - then SessionImplementor term fits > better as we'd have StatefulSessionImplementor and > StatelessSessionImplementor variants. I really dislike the phrases stateful > and stateless here though. Anyway, let me know what y'all think. > > On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling wrote: >> >> 2016-04-13 0:48 GMT+02:00 Steve Ebersole : >>> >>> Another question as I work through Query... >>> >>> Currently both Session and StatelessSession inherit the same query >>> creation >>> methods (returning org.hibernate.Query) via SharedSessionContract (which >>> is >>> the common base type between them). There is therefore an inherent >>> difficulty in having org.hibernate.Query extend from the JPA >>> javax.persistence.Query/TypedQuery when we only want Session to be an >>> EntityManager, not StatelessSession. >>> >>> The simplest solution is to: >>> >>> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" >>> and >>> >>> >>> move all of the existing SharedSessionContract query creation >>> methods >>> returning org.hibernate.Query directly to StatelessSession >>> >>> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that >>> >>> >>> provides some of the "legacy Hibernate query contract" and extends >>> from >>> javax.persistence.Query. Directly on Session we'd write new >>> methods with >>> the same name and args but returning this >>> org.hibernate.query.Query. >>> >>> This would give us 2 distinct Query hierarchies and allow the underlying >>> goal of Session extending EntityManager, but not StatelessSession. We >>> could also flip these based on the knowledge that Session is more widely >>> used (less disruptive). >>> >>> In other words we'd go from both Session and StatelessSession returning >>> org.hibernate.Query via inheriting from SharedSessionContract: >>> >>> public interface SharedSessionContract { >>> ... >>> org.hibernate.Query createQuery(String hql); >>> } >>> >>> >>> to each Session and StatelessSession implementing different methods >>> altogether: >>> >>> public interface StatelessSession { >>> ... >>> org.hibernate.Query createQuery(String hql); >>> } >>> >>> public interface Session { >>> ... >>> org.hibernate.query.Query createQuery(String hql); >>> } >>> >>> >>> Unifying these returns across Session and StatelessSession would require >>> StatelessSession also being an EntityManager. I had decided against that >>> for the same reasons that StatelessSession is distinct from Session. >> >> >> Why would it require StatelessSession to extend EntityManager? Both, >> StatelessSession and Session could define the same method, also if not being >> part of the same hierarchy. >> >> I'm concerned about the two Query types with the same simple name, users >> may be easily confused which one to import. >> >>> Maybe a hybrid approach would be to break the query creation methods out >>> of >>> SharedSessionContract into a new targeted interface named QueryProducer >>> which both Session and StatelessSession would implement. That would >>> allow >>> unifying the query creation return to something that implements JPA Query >>> contract too, but the source (Session/StatelessSession via QueryProducer) >>> would not necessarily need to implement EntityManager. >>> >>> >>> I think the QueryProducer route is probably the best option in terms of >>> allowing the consolidation but still allowing users to upgrade easily. >>> >>> Thoughts? Other options? Hopefully I explained it well enough :) >> >> >> Something related; If you are touching these bits, could you rename >> createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery? >> That'd give a much better experience for users of Hibernate OGM which >> otherwise wonder how SQL queries relate to their chosen NoSQL store. >> createNativeQuery() makes that smoother. >> >>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole >>> wrote: >>> >>> > Just a quick update on my progress. I pretty much have >>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted >>> > out as >>> > well as bootstrapping. >>> > >>> > I am currently working through the different Query hierarchies. >>> > >>> > Looking at what is left, I hope to be done with all of this by Thursday >>> > >>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero >>> > wrote: >>> > >>> >> On 8 April 2016 at 15:04, Scott Marlow wrote: >>> >> > I'm curious if Search/OGM master branches would likely align with >>> >> > 5.2? >>> >> > Or some other branch? >>> >> >>> >> Good question, time for an update on these. >>> >> >>> >> We'll certainly have a version of Search compatible, at some point. >>> >> Not sure though about which version that shall be as we want to be >>> >> feature complete with our Elasticsearch work, and that will take a >>> >> couple more months at least so we'll see a bit longer than usual gap >>> >> between stable releases. >>> >> >>> >> Generally speaking we need at least a minor release for OGM or Search >>> >> to happen to upgrade the minor of ORM. >>> >> Since we didn't release yet, Search is still building with ORM 5.0.x >>> >> as a target.. we can then decide if we should skip ORM 5.1 and jump to >>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As >>> >> far as I know only some test helpers broke though, so while I couldn't >>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they are >>> >> compatible at runtime and we also expect to be compatible with ORM >>> >> 5.2. >>> >> >>> >> With OGM we're now in candidate release phase for a ORM 5.0 compatible >>> >> version so not really thinking to bump it to ORM 5.1 yet. >>> >> >>> >> OGM tends to release less frequently, so in this case it is possible >>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch up, >>> >> but we can work on aiming a specific version if and when need arises. >>> >> >>> >> If you need any of these aligned let us know? >>> >> >>> >> Thanks, >>> >> Sanne >>> >> >>> >> > >>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: >>> >> >> As a follow up to this... >>> >> >> >>> >> >> Sanne had a great suggestion on HipChat. What about turning all >>> >> >> this >>> >> work >>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea >>> >> >> would >>> >> be >>> >> >> 5.2 would include: >>> >> >> >>> >> >> 1. Move to Java 8 >>> >> >> 2. Consolidation of hibernate-entitymanager into hibernate-core >>> >> >> 3. Deprecations, lots of deprecations :) >>> >> >> >>> >> >> >>> >> >> The idea is that then we could start 6.0 off "clean" by removing >>> >> >> all >>> >> the >>> >> >> deprecations and layering in SQM work. >>> >> >> >>> >> >> >>> >> >> >>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea >>> >> >> >> >> > >>> >> >> wrote: >>> >> >> >>> >> >>> Hi, >>> >> >>> >>> >> >>> Until the merge is done, I'll take a break integrating the PRs >>> >> >>> that >>> >> are >>> >> >>> also relevant to the master branch. >>> >> >>> >>> >> >>> Vlad >>> >> >>> >>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >>> >> >>> >>> >> >>> wrote: >>> >> >>> >>> >> >>>> I agree that would be best. If everyone agrees to stop pushing >>> >> >>>> to >>> >> master >>> >> >>>> for the time being to allow me to finish this consolidation then >>> >> >>>> I >>> >> can not >>> >> >>>> rush it as much >>> >> >>>> >>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford >>> >> >>>> >>> >> wrote: >>> >> >>>> >>> >> >>>>> I have to concur with Sanne, a hold on master pushes until this >>> >> merge of >>> >> >>>>> artifacts is complete makes the most sense from an all around >>> >> logistics >>> >> >>>>> perspective. >>> >> >>>>> >>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < >>> >> sanne at hibernate.org> >>> >> >>>>> wrote: >>> >> >>>>> >>> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. >>> >> >>>>>> should we >>> >> >>>>>> temporarily disable complaint emails from Jenkins, or even the >>> >> >>>>>> full >>> >> >>>>>> build tasks? >>> >> >>>>>> >>> >> >>>>>> Also, this implies that any future backport becomes similarly >>> >> harder, >>> >> >>>>>> so you could also simply ask others to hold pushing on master, >>> >> >>>>>> then >>> >> >>>>>> have people forward-port when it's done.. it's the same really >>> >> >>>>>> but >>> >> >>>>>> that's why I mention it: as the complexity is interchangeable >>> >> >>>>>> it's >>> >> a >>> >> >>>>>> fair request, with the difference you have: >>> >> >>>>>> - others help you port the other patches forward rather than >>> >> doing it >>> >> >>>>> all >>> >> >>>>>> alone >>> >> >>>>>> - the authors of the original patch doing it, that should >>> >> >>>>>> make >>> >> it a >>> >> >>>> bit >>> >> >>>>>> simpler >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole >>> >> wrote: >>> >> >>>>>>> Obviously consolidating hibernate-entitymanager into >>> >> hibernate-core >>> >> >>>> is >>> >> >>>>> a >>> >> >>>>>>> fairly big effort. And I am getting concerned about the >>> >> continuing >>> >> >>>>>> pushes >>> >> >>>>>>> to master in the meantime, many of which I know touch on code >>> >> >>>>>>> I >>> >> have >>> >> >>>>>>> changed. My concern is obviously getting done all this >>> >> refactoring >>> >> >>>>> work >>> >> >>>>>>> and then having to sift through all of the changes that have >>> >> >>>>>>> been >>> >> >>>>> pushed >>> >> >>>>>> in >>> >> >>>>>>> the interim and attempting to work out the proper integration >>> >> >>>> strategy. >>> >> >>>>>>> >>> >> >>>>>>> Long story short... I am contemplating pushing to master >>> >> >>>>>>> sooner >>> >> >>>> rather >>> >> >>>>>> than >>> >> >>>>>>> later even though my refactoring may not be completely >>> >> >>>>>>> finished, >>> >> >>>>>> especially >>> >> >>>>>>> as we get towards the end of the week. >>> >> >>>>>>> _______________________________________________ >>> >> >>>>>>> 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 >>> >> >>> > >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Apr 15 11:10:57 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 15 Apr 2016 15:10:57 +0000 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: That's not the intent. Users do deal with Session or StatelessSession. SharedSessionContract simply exists as a convenience for us to make sure Session and StatelessSession implement some of the same signatures. Now, if you are talking about the *Implementor forms those are the same as any of the other *Implementor interfaces used throughout Hibernate. They extend the public API with additional capabilities needed internally. A user would never directly use a SharedSessionContract, a SharedSessionContract Implementor, a SessionImplementor, etc. I am asking this question because it has an impact on integrations (which is expected, it's an SPI) not users On Fri, Apr 15, 2016, 9:46 AM Sanne Grinovero wrote: > Do you have a practical need for SharedSessionContract and > SharedSessionContractImplementor to exist within the internal > contracts of ORM? > > As a general rule, I don't mind having implementations which implement > multiple interfaces. > > Assuming you need these as a convenience for internal helpers, then > I'd propose to treat these as internal interfaces rather than APIs or > SPIs. For example, have users deal just with "Session" and > "StatelessSession" and not need learning (nor bothering) with more > stuff. > > my 2 cents.. not a strong opinion. > Sanne > > > On 15 April 2016 at 15:30, Steve Ebersole wrote: > > So here is what I ended up doing, with one questionable decision which > I'll > > highlight below. > > > > First, the existing situation... We have Session and StatelessSession > which > > are largely independent contracts. There is a "shared" bit that is > > represented by an interface SharedSessionContract. There is also a > > SessionImplementor contract. Now previously a SessionImplementor could > be a > > Session or a StatelessSession; very poorly named. > > > > SessionImplementor is poorly named. Following the normal *Implementor > > naming convention we follow every else in the code base a > SessionImplementor > > ought to be the internal contract for a Session. But that's not what it > is > > today. Really SessionImplementor as it exists today is the *Implementor > for > > SharedSessionContract. So I normalized this. I created a > > SharedSessionContractImplementor contract that extends > > SharedSessionContract. SessionImplementor then extends > > SharedSessionContractImplementor. However this is the "questionable" > part > > because that means changing an awful lot of SPI methods to accept/return > > SharedSessionContractImplementor as opposed to SessionImplementor. > > > > So in terms of API, we have: SharedSessionContract <- (Session & > > StatelessSession) > > In terms of SPI, we have: SharedSessionContractImplementor <- > > (SessionImplementor & StatelessSessionImplementor) > > > > As far as Query object creation, SharedSessionContract also fulfills the > > role of (extends) the QueryProducer contract which defines a unified set > of > > methods that cover the JPA cases without having to implement > EntityManager. > > ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It > will > > still have to deal with procedure/function calls. Eventually in 6.0 it > will > > have to deal with criteria queries as well. > > > > Gunnar to your specific question about naming, yes. I had already > started > > on that path actually. So in terms of API contracts we have: > > > > org.hibernate.query.Query > > org.hibernate.query.NativeQuery extends org.hibernate.query.Query > > > > Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I > > can't remove them in a 5.2 release. However I have deprecated them as > > scheduled them for removal in 6.0. This follows the typical "shadow" > > approach we have followed before for deprecating APIs. > > org.hibernate.query.Query extends the deprecated org.hibernate.Query and > > org.hibernate.query.NativeQuery extends the deprecated > > org.hibernate.SQLQuery. That allows existing code to continue to work > with > > deprecation warnings. Users can chose to migrate to the new contracts in > > moving to 5.2 or at least know that is a task in upgrading to 6.0. > > > > I'd love some votes on the > > SessionImplementor/SharedSessionContractImplementor point above. There > are > > other, less disruptive ways to do that; I just think this is the most > > correct way. Some other options include more fully distinguishing > between a > > "stateful" and a "stateless" Session - then SessionImplementor term fits > > better as we'd have StatefulSessionImplementor and > > StatelessSessionImplementor variants. I really dislike the phrases > stateful > > and stateless here though. Anyway, let me know what y'all think. > > > > On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling > wrote: > >> > >> 2016-04-13 0:48 GMT+02:00 Steve Ebersole : > >>> > >>> Another question as I work through Query... > >>> > >>> Currently both Session and StatelessSession inherit the same query > >>> creation > >>> methods (returning org.hibernate.Query) via SharedSessionContract > (which > >>> is > >>> the common base type between them). There is therefore an inherent > >>> difficulty in having org.hibernate.Query extend from the JPA > >>> javax.persistence.Query/TypedQuery when we only want Session to be an > >>> EntityManager, not StatelessSession. > >>> > >>> The simplest solution is to: > >>> > >>> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" > >>> and > >>> > >>> > >>> move all of the existing SharedSessionContract query creation > >>> methods > >>> returning org.hibernate.Query directly to StatelessSession > >>> > >>> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that > >>> > >>> > >>> provides some of the "legacy Hibernate query contract" and > extends > >>> from > >>> javax.persistence.Query. Directly on Session we'd write new > >>> methods with > >>> the same name and args but returning this > >>> org.hibernate.query.Query. > >>> > >>> This would give us 2 distinct Query hierarchies and allow the > underlying > >>> goal of Session extending EntityManager, but not StatelessSession. We > >>> could also flip these based on the knowledge that Session is more > widely > >>> used (less disruptive). > >>> > >>> In other words we'd go from both Session and StatelessSession returning > >>> org.hibernate.Query via inheriting from SharedSessionContract: > >>> > >>> public interface SharedSessionContract { > >>> ... > >>> org.hibernate.Query createQuery(String hql); > >>> } > >>> > >>> > >>> to each Session and StatelessSession implementing different methods > >>> altogether: > >>> > >>> public interface StatelessSession { > >>> ... > >>> org.hibernate.Query createQuery(String hql); > >>> } > >>> > >>> public interface Session { > >>> ... > >>> org.hibernate.query.Query createQuery(String hql); > >>> } > >>> > >>> > >>> Unifying these returns across Session and StatelessSession would > require > >>> StatelessSession also being an EntityManager. I had decided against > that > >>> for the same reasons that StatelessSession is distinct from Session. > >> > >> > >> Why would it require StatelessSession to extend EntityManager? Both, > >> StatelessSession and Session could define the same method, also if not > being > >> part of the same hierarchy. > >> > >> I'm concerned about the two Query types with the same simple name, users > >> may be easily confused which one to import. > >> > >>> Maybe a hybrid approach would be to break the query creation methods > out > >>> of > >>> SharedSessionContract into a new targeted interface named QueryProducer > >>> which both Session and StatelessSession would implement. That would > >>> allow > >>> unifying the query creation return to something that implements JPA > Query > >>> contract too, but the source (Session/StatelessSession via > QueryProducer) > >>> would not necessarily need to implement EntityManager. > >>> > >>> > >>> I think the QueryProducer route is probably the best option in terms of > >>> allowing the consolidation but still allowing users to upgrade easily. > >>> > >>> Thoughts? Other options? Hopefully I explained it well enough :) > >> > >> > >> Something related; If you are touching these bits, could you rename > >> createSQLQuery() into createNativeQuery() and SQLQuery into NativeQuery? > >> That'd give a much better experience for users of Hibernate OGM which > >> otherwise wonder how SQL queries relate to their chosen NoSQL store. > >> createNativeQuery() makes that smoother. > >> > >>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole > >>> wrote: > >>> > >>> > Just a quick update on my progress. I pretty much have > >>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted > >>> > out as > >>> > well as bootstrapping. > >>> > > >>> > I am currently working through the different Query hierarchies. > >>> > > >>> > Looking at what is left, I hope to be done with all of this by > Thursday > >>> > > >>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero > >>> > wrote: > >>> > > >>> >> On 8 April 2016 at 15:04, Scott Marlow wrote: > >>> >> > I'm curious if Search/OGM master branches would likely align with > >>> >> > 5.2? > >>> >> > Or some other branch? > >>> >> > >>> >> Good question, time for an update on these. > >>> >> > >>> >> We'll certainly have a version of Search compatible, at some point. > >>> >> Not sure though about which version that shall be as we want to be > >>> >> feature complete with our Elasticsearch work, and that will take a > >>> >> couple more months at least so we'll see a bit longer than usual gap > >>> >> between stable releases. > >>> >> > >>> >> Generally speaking we need at least a minor release for OGM or > Search > >>> >> to happen to upgrade the minor of ORM. > >>> >> Since we didn't release yet, Search is still building with ORM 5.0.x > >>> >> as a target.. we can then decide if we should skip ORM 5.1 and jump > to > >>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As > >>> >> far as I know only some test helpers broke though, so while I > couldn't > >>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they > are > >>> >> compatible at runtime and we also expect to be compatible with ORM > >>> >> 5.2. > >>> >> > >>> >> With OGM we're now in candidate release phase for a ORM 5.0 > compatible > >>> >> version so not really thinking to bump it to ORM 5.1 yet. > >>> >> > >>> >> OGM tends to release less frequently, so in this case it is possible > >>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch > up, > >>> >> but we can work on aiming a specific version if and when need > arises. > >>> >> > >>> >> If you need any of these aligned let us know? > >>> >> > >>> >> Thanks, > >>> >> Sanne > >>> >> > >>> >> > > >>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: > >>> >> >> As a follow up to this... > >>> >> >> > >>> >> >> Sanne had a great suggestion on HipChat. What about turning all > >>> >> >> this > >>> >> work > >>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea > >>> >> >> would > >>> >> be > >>> >> >> 5.2 would include: > >>> >> >> > >>> >> >> 1. Move to Java 8 > >>> >> >> 2. Consolidation of hibernate-entitymanager into > hibernate-core > >>> >> >> 3. Deprecations, lots of deprecations :) > >>> >> >> > >>> >> >> > >>> >> >> The idea is that then we could start 6.0 off "clean" by removing > >>> >> >> all > >>> >> the > >>> >> >> deprecations and layering in SQM work. > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea > >>> >> >> >>> >> > > >>> >> >> wrote: > >>> >> >> > >>> >> >>> Hi, > >>> >> >>> > >>> >> >>> Until the merge is done, I'll take a break integrating the PRs > >>> >> >>> that > >>> >> are > >>> >> >>> also relevant to the master branch. > >>> >> >>> > >>> >> >>> Vlad > >>> >> >>> > >>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole > >>> >> >>> > >>> >> >>> wrote: > >>> >> >>> > >>> >> >>>> I agree that would be best. If everyone agrees to stop pushing > >>> >> >>>> to > >>> >> master > >>> >> >>>> for the time being to allow me to finish this consolidation > then > >>> >> >>>> I > >>> >> can not > >>> >> >>>> rush it as much > >>> >> >>>> > >>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford > >>> >> >>>> > >>> >> wrote: > >>> >> >>>> > >>> >> >>>>> I have to concur with Sanne, a hold on master pushes until > this > >>> >> merge of > >>> >> >>>>> artifacts is complete makes the most sense from an all around > >>> >> logistics > >>> >> >>>>> perspective. > >>> >> >>>>> > >>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < > >>> >> sanne at hibernate.org> > >>> >> >>>>> wrote: > >>> >> >>>>> > >>> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. > >>> >> >>>>>> should we > >>> >> >>>>>> temporarily disable complaint emails from Jenkins, or even > the > >>> >> >>>>>> full > >>> >> >>>>>> build tasks? > >>> >> >>>>>> > >>> >> >>>>>> Also, this implies that any future backport becomes similarly > >>> >> harder, > >>> >> >>>>>> so you could also simply ask others to hold pushing on > master, > >>> >> >>>>>> then > >>> >> >>>>>> have people forward-port when it's done.. it's the same > really > >>> >> >>>>>> but > >>> >> >>>>>> that's why I mention it: as the complexity is interchangeable > >>> >> >>>>>> it's > >>> >> a > >>> >> >>>>>> fair request, with the difference you have: > >>> >> >>>>>> - others help you port the other patches forward rather > than > >>> >> doing it > >>> >> >>>>> all > >>> >> >>>>>> alone > >>> >> >>>>>> - the authors of the original patch doing it, that should > >>> >> >>>>>> make > >>> >> it a > >>> >> >>>> bit > >>> >> >>>>>> simpler > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole < > steve at hibernate.org> > >>> >> wrote: > >>> >> >>>>>>> Obviously consolidating hibernate-entitymanager into > >>> >> hibernate-core > >>> >> >>>> is > >>> >> >>>>> a > >>> >> >>>>>>> fairly big effort. And I am getting concerned about the > >>> >> continuing > >>> >> >>>>>> pushes > >>> >> >>>>>>> to master in the meantime, many of which I know touch on > code > >>> >> >>>>>>> I > >>> >> have > >>> >> >>>>>>> changed. My concern is obviously getting done all this > >>> >> refactoring > >>> >> >>>>> work > >>> >> >>>>>>> and then having to sift through all of the changes that have > >>> >> >>>>>>> been > >>> >> >>>>> pushed > >>> >> >>>>>> in > >>> >> >>>>>>> the interim and attempting to work out the proper > integration > >>> >> >>>> strategy. > >>> >> >>>>>>> > >>> >> >>>>>>> Long story short... I am contemplating pushing to master > >>> >> >>>>>>> sooner > >>> >> >>>> rather > >>> >> >>>>>> than > >>> >> >>>>>>> later even though my refactoring may not be completely > >>> >> >>>>>>> finished, > >>> >> >>>>>> especially > >>> >> >>>>>>> as we get towards the end of the week. > >>> >> >>>>>>> _______________________________________________ > >>> >> >>>>>>> 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 > >>> >> > >>> > > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Fri Apr 15 13:10:21 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 15 Apr 2016 19:10:21 +0200 Subject: [hibernate-dev] Master In-Reply-To: References: <5707BA84.5010307@redhat.com> Message-ID: On 15 April 2016 at 17:10, Steve Ebersole wrote: > That's not the intent. Users do deal with Session or StatelessSession. > SharedSessionContract simply exists as a convenience for us to make sure > Session and StatelessSession implement some of the same signatures. Ok, I got it know. Sorry I had interpreted the opposite, just returned from a flight late night and I'm a bit confused I'm afraid :) Looks good then! > > Now, if you are talking about the *Implementor forms those are the same as > any of the other *Implementor interfaces used throughout Hibernate. They > extend the public API with additional capabilities needed internally. A > user would never directly use a SharedSessionContract, a > SharedSessionContract Implementor, a SessionImplementor, etc. > > I am asking this question because it has an impact on integrations (which is > expected, it's an SPI) not users > > > On Fri, Apr 15, 2016, 9:46 AM Sanne Grinovero wrote: >> >> Do you have a practical need for SharedSessionContract and >> SharedSessionContractImplementor to exist within the internal >> contracts of ORM? >> >> As a general rule, I don't mind having implementations which implement >> multiple interfaces. >> >> Assuming you need these as a convenience for internal helpers, then >> I'd propose to treat these as internal interfaces rather than APIs or >> SPIs. For example, have users deal just with "Session" and >> "StatelessSession" and not need learning (nor bothering) with more >> stuff. >> >> my 2 cents.. not a strong opinion. >> Sanne >> >> >> On 15 April 2016 at 15:30, Steve Ebersole wrote: >> > So here is what I ended up doing, with one questionable decision which >> > I'll >> > highlight below. >> > >> > First, the existing situation... We have Session and StatelessSession >> > which >> > are largely independent contracts. There is a "shared" bit that is >> > represented by an interface SharedSessionContract. There is also a >> > SessionImplementor contract. Now previously a SessionImplementor could >> > be a >> > Session or a StatelessSession; very poorly named. >> > >> > SessionImplementor is poorly named. Following the normal *Implementor >> > naming convention we follow every else in the code base a >> > SessionImplementor >> > ought to be the internal contract for a Session. But that's not what it >> > is >> > today. Really SessionImplementor as it exists today is the *Implementor >> > for >> > SharedSessionContract. So I normalized this. I created a >> > SharedSessionContractImplementor contract that extends >> > SharedSessionContract. SessionImplementor then extends >> > SharedSessionContractImplementor. However this is the "questionable" >> > part >> > because that means changing an awful lot of SPI methods to accept/return >> > SharedSessionContractImplementor as opposed to SessionImplementor. >> > >> > So in terms of API, we have: SharedSessionContract <- (Session & >> > StatelessSession) >> > In terms of SPI, we have: SharedSessionContractImplementor <- >> > (SessionImplementor & StatelessSessionImplementor) >> > >> > As far as Query object creation, SharedSessionContract also fulfills the >> > role of (extends) the QueryProducer contract which defines a unified set >> > of >> > methods that cover the JPA cases without having to implement >> > EntityManager. >> > ATM QueryProducer covers HQL/JPQL and Native (SQL) queries. For 5.2 It >> > will >> > still have to deal with procedure/function calls. Eventually in 6.0 it >> > will >> > have to deal with criteria queries as well. >> > >> > Gunnar to your specific question about naming, yes. I had already >> > started >> > on that path actually. So in terms of API contracts we have: >> > >> > org.hibernate.query.Query >> > org.hibernate.query.NativeQuery extends org.hibernate.query.Query >> > >> > Additionally I left org.hibernate.Query and org.hibernate.SQLQuery as I >> > can't remove them in a 5.2 release. However I have deprecated them as >> > scheduled them for removal in 6.0. This follows the typical "shadow" >> > approach we have followed before for deprecating APIs. >> > org.hibernate.query.Query extends the deprecated org.hibernate.Query and >> > org.hibernate.query.NativeQuery extends the deprecated >> > org.hibernate.SQLQuery. That allows existing code to continue to work >> > with >> > deprecation warnings. Users can chose to migrate to the new contracts >> > in >> > moving to 5.2 or at least know that is a task in upgrading to 6.0. >> > >> > I'd love some votes on the >> > SessionImplementor/SharedSessionContractImplementor point above. There >> > are >> > other, less disruptive ways to do that; I just think this is the most >> > correct way. Some other options include more fully distinguishing >> > between a >> > "stateful" and a "stateless" Session - then SessionImplementor term fits >> > better as we'd have StatefulSessionImplementor and >> > StatelessSessionImplementor variants. I really dislike the phrases >> > stateful >> > and stateless here though. Anyway, let me know what y'all think. >> > >> > On Wed, Apr 13, 2016 at 1:54 AM Gunnar Morling >> > wrote: >> >> >> >> 2016-04-13 0:48 GMT+02:00 Steve Ebersole : >> >>> >> >>> Another question as I work through Query... >> >>> >> >>> Currently both Session and StatelessSession inherit the same query >> >>> creation >> >>> methods (returning org.hibernate.Query) via SharedSessionContract >> >>> (which >> >>> is >> >>> the common base type between them). There is therefore an inherent >> >>> difficulty in having org.hibernate.Query extend from the JPA >> >>> javax.persistence.Query/TypedQuery when we only want Session to be an >> >>> EntityManager, not StatelessSession. >> >>> >> >>> The simplest solution is to: >> >>> >> >>> 1. Leave org.hibernate.Query as a "legacy Hibernate query contract" >> >>> and >> >>> >> >>> >> >>> move all of the existing SharedSessionContract query creation >> >>> methods >> >>> returning org.hibernate.Query directly to StatelessSession >> >>> >> >>> 2. develop a new org.hibernate.query.Query (prefacing 6.0) that >> >>> >> >>> >> >>> provides some of the "legacy Hibernate query contract" and >> >>> extends >> >>> from >> >>> javax.persistence.Query. Directly on Session we'd write new >> >>> methods with >> >>> the same name and args but returning this >> >>> org.hibernate.query.Query. >> >>> >> >>> This would give us 2 distinct Query hierarchies and allow the >> >>> underlying >> >>> goal of Session extending EntityManager, but not StatelessSession. We >> >>> could also flip these based on the knowledge that Session is more >> >>> widely >> >>> used (less disruptive). >> >>> >> >>> In other words we'd go from both Session and StatelessSession >> >>> returning >> >>> org.hibernate.Query via inheriting from SharedSessionContract: >> >>> >> >>> public interface SharedSessionContract { >> >>> ... >> >>> org.hibernate.Query createQuery(String hql); >> >>> } >> >>> >> >>> >> >>> to each Session and StatelessSession implementing different methods >> >>> altogether: >> >>> >> >>> public interface StatelessSession { >> >>> ... >> >>> org.hibernate.Query createQuery(String hql); >> >>> } >> >>> >> >>> public interface Session { >> >>> ... >> >>> org.hibernate.query.Query createQuery(String hql); >> >>> } >> >>> >> >>> >> >>> Unifying these returns across Session and StatelessSession would >> >>> require >> >>> StatelessSession also being an EntityManager. I had decided against >> >>> that >> >>> for the same reasons that StatelessSession is distinct from Session. >> >> >> >> >> >> Why would it require StatelessSession to extend EntityManager? Both, >> >> StatelessSession and Session could define the same method, also if not >> >> being >> >> part of the same hierarchy. >> >> >> >> I'm concerned about the two Query types with the same simple name, >> >> users >> >> may be easily confused which one to import. >> >> >> >>> Maybe a hybrid approach would be to break the query creation methods >> >>> out >> >>> of >> >>> SharedSessionContract into a new targeted interface named >> >>> QueryProducer >> >>> which both Session and StatelessSession would implement. That would >> >>> allow >> >>> unifying the query creation return to something that implements JPA >> >>> Query >> >>> contract too, but the source (Session/StatelessSession via >> >>> QueryProducer) >> >>> would not necessarily need to implement EntityManager. >> >>> >> >>> >> >>> I think the QueryProducer route is probably the best option in terms >> >>> of >> >>> allowing the consolidation but still allowing users to upgrade easily. >> >>> >> >>> Thoughts? Other options? Hopefully I explained it well enough :) >> >> >> >> >> >> Something related; If you are touching these bits, could you rename >> >> createSQLQuery() into createNativeQuery() and SQLQuery into >> >> NativeQuery? >> >> That'd give a much better experience for users of Hibernate OGM which >> >> otherwise wonder how SQL queries relate to their chosen NoSQL store. >> >> createNativeQuery() makes that smoother. >> >> >> >>> On Tue, Apr 12, 2016 at 1:29 PM Steve Ebersole >> >>> wrote: >> >>> >> >>> > Just a quick update on my progress. I pretty much have >> >>> > Session/EntityManager and SessionFactory/EntiytManagerFactory sorted >> >>> > out as >> >>> > well as bootstrapping. >> >>> > >> >>> > I am currently working through the different Query hierarchies. >> >>> > >> >>> > Looking at what is left, I hope to be done with all of this by >> >>> > Thursday >> >>> > >> >>> > On Fri, Apr 8, 2016, 9:38 AM Sanne Grinovero >> >>> > wrote: >> >>> > >> >>> >> On 8 April 2016 at 15:04, Scott Marlow wrote: >> >>> >> > I'm curious if Search/OGM master branches would likely align with >> >>> >> > 5.2? >> >>> >> > Or some other branch? >> >>> >> >> >>> >> Good question, time for an update on these. >> >>> >> >> >>> >> We'll certainly have a version of Search compatible, at some point. >> >>> >> Not sure though about which version that shall be as we want to be >> >>> >> feature complete with our Elasticsearch work, and that will take a >> >>> >> couple more months at least so we'll see a bit longer than usual >> >>> >> gap >> >>> >> between stable releases. >> >>> >> >> >>> >> Generally speaking we need at least a minor release for OGM or >> >>> >> Search >> >>> >> to happen to upgrade the minor of ORM. >> >>> >> Since we didn't release yet, Search is still building with ORM >> >>> >> 5.0.x >> >>> >> as a target.. we can then decide if we should skip ORM 5.1 and jump >> >>> >> to >> >>> >> 5.2 when we'll be closer to the 5.6.0.Final release (of Search). As >> >>> >> far as I know only some test helpers broke though, so while I >> >>> >> couldn't >> >>> >> test it all on both versions 5.0 and 5.1 of ORM, I think that they >> >>> >> are >> >>> >> compatible at runtime and we also expect to be compatible with ORM >> >>> >> 5.2. >> >>> >> >> >>> >> With OGM we're now in candidate release phase for a ORM 5.0 >> >>> >> compatible >> >>> >> version so not really thinking to bump it to ORM 5.1 yet. >> >>> >> >> >>> >> OGM tends to release less frequently, so in this case it is >> >>> >> possible >> >>> >> that we might want to skip ORM 5.1 and go on 5.2 already to catch >> >>> >> up, >> >>> >> but we can work on aiming a specific version if and when need >> >>> >> arises. >> >>> >> >> >>> >> If you need any of these aligned let us know? >> >>> >> >> >>> >> Thanks, >> >>> >> Sanne >> >>> >> >> >>> >> > >> >>> >> > On 04/07/2016 11:34 AM, Steve Ebersole wrote: >> >>> >> >> As a follow up to this... >> >>> >> >> >> >>> >> >> Sanne had a great suggestion on HipChat. What about turning all >> >>> >> >> this >> >>> >> work >> >>> >> >> (sans SQM, etc) into a 5.2 as an "end of line for 5.0. The idea >> >>> >> >> would >> >>> >> be >> >>> >> >> 5.2 would include: >> >>> >> >> >> >>> >> >> 1. Move to Java 8 >> >>> >> >> 2. Consolidation of hibernate-entitymanager into >> >>> >> >> hibernate-core >> >>> >> >> 3. Deprecations, lots of deprecations :) >> >>> >> >> >> >>> >> >> >> >>> >> >> The idea is that then we could start 6.0 off "clean" by removing >> >>> >> >> all >> >>> >> the >> >>> >> >> deprecations and layering in SQM work. >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> On Thu, Apr 7, 2016 at 10:01 AM Vlad Mihalcea >> >>> >> >> > >>> >> > >> >>> >> >> wrote: >> >>> >> >> >> >>> >> >>> Hi, >> >>> >> >>> >> >>> >> >>> Until the merge is done, I'll take a break integrating the PRs >> >>> >> >>> that >> >>> >> are >> >>> >> >>> also relevant to the master branch. >> >>> >> >>> >> >>> >> >>> Vlad >> >>> >> >>> >> >>> >> >>> On Thu, Apr 7, 2016 at 5:57 PM, Steve Ebersole >> >>> >> >>> >> >>> >> >>> wrote: >> >>> >> >>> >> >>> >> >>>> I agree that would be best. If everyone agrees to stop >> >>> >> >>>> pushing >> >>> >> >>>> to >> >>> >> master >> >>> >> >>>> for the time being to allow me to finish this consolidation >> >>> >> >>>> then >> >>> >> >>>> I >> >>> >> can not >> >>> >> >>>> rush it as much >> >>> >> >>>> >> >>> >> >>>> On Wed, Apr 6, 2016 at 4:48 PM Chris Cranford >> >>> >> >>>> >> >>> >> wrote: >> >>> >> >>>> >> >>> >> >>>>> I have to concur with Sanne, a hold on master pushes until >> >>> >> >>>>> this >> >>> >> merge of >> >>> >> >>>>> artifacts is complete makes the most sense from an all around >> >>> >> logistics >> >>> >> >>>>> perspective. >> >>> >> >>>>> >> >>> >> >>>>> On Wed, Apr 6, 2016 at 4:04 PM, Sanne Grinovero < >> >>> >> sanne at hibernate.org> >> >>> >> >>>>> wrote: >> >>> >> >>>>> >> >>> >> >>>>>> Sounds reasonable. Do you think it will be unstable, i.e. >> >>> >> >>>>>> should we >> >>> >> >>>>>> temporarily disable complaint emails from Jenkins, or even >> >>> >> >>>>>> the >> >>> >> >>>>>> full >> >>> >> >>>>>> build tasks? >> >>> >> >>>>>> >> >>> >> >>>>>> Also, this implies that any future backport becomes >> >>> >> >>>>>> similarly >> >>> >> harder, >> >>> >> >>>>>> so you could also simply ask others to hold pushing on >> >>> >> >>>>>> master, >> >>> >> >>>>>> then >> >>> >> >>>>>> have people forward-port when it's done.. it's the same >> >>> >> >>>>>> really >> >>> >> >>>>>> but >> >>> >> >>>>>> that's why I mention it: as the complexity is >> >>> >> >>>>>> interchangeable >> >>> >> >>>>>> it's >> >>> >> a >> >>> >> >>>>>> fair request, with the difference you have: >> >>> >> >>>>>> - others help you port the other patches forward rather >> >>> >> >>>>>> than >> >>> >> doing it >> >>> >> >>>>> all >> >>> >> >>>>>> alone >> >>> >> >>>>>> - the authors of the original patch doing it, that should >> >>> >> >>>>>> make >> >>> >> it a >> >>> >> >>>> bit >> >>> >> >>>>>> simpler >> >>> >> >>>>>> >> >>> >> >>>>>> >> >>> >> >>>>>> >> >>> >> >>>>>> On 6 April 2016 at 17:15, Steve Ebersole >> >>> >> >>>>>> >> >>> >> wrote: >> >>> >> >>>>>>> Obviously consolidating hibernate-entitymanager into >> >>> >> hibernate-core >> >>> >> >>>> is >> >>> >> >>>>> a >> >>> >> >>>>>>> fairly big effort. And I am getting concerned about the >> >>> >> continuing >> >>> >> >>>>>> pushes >> >>> >> >>>>>>> to master in the meantime, many of which I know touch on >> >>> >> >>>>>>> code >> >>> >> >>>>>>> I >> >>> >> have >> >>> >> >>>>>>> changed. My concern is obviously getting done all this >> >>> >> refactoring >> >>> >> >>>>> work >> >>> >> >>>>>>> and then having to sift through all of the changes that >> >>> >> >>>>>>> have >> >>> >> >>>>>>> been >> >>> >> >>>>> pushed >> >>> >> >>>>>> in >> >>> >> >>>>>>> the interim and attempting to work out the proper >> >>> >> >>>>>>> integration >> >>> >> >>>> strategy. >> >>> >> >>>>>>> >> >>> >> >>>>>>> Long story short... I am contemplating pushing to master >> >>> >> >>>>>>> sooner >> >>> >> >>>> rather >> >>> >> >>>>>> than >> >>> >> >>>>>>> later even though my refactoring may not be completely >> >>> >> >>>>>>> finished, >> >>> >> >>>>>> especially >> >>> >> >>>>>>> as we get towards the end of the week. >> >>> >> >>>>>>> _______________________________________________ >> >>> >> >>>>>>> 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 >> >>> >> >> >>> > >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev From karel at geovise.com Sun Apr 17 10:12:04 2016 From: karel at geovise.com (Karel Maesen) Date: Sun, 17 Apr 2016 16:12:04 +0200 Subject: [hibernate-dev] http://www.hibernatespatial.org/ In-Reply-To: <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> References: <954A7731-4E9E-41B7-9875-992A1E70CC92@geovise.com> <6D9F66D9-9BC9-4AA8-9D84-2BDC1A313598@geovise.com> <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> Message-ID: Hi Vlad, I've created a PR (#1334) that contains a number of corrections and additions for the User Guide. Regards, Karel On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen wrote: > Hi Vlad, > > Thanks for doing this already. It?s a good starting point. I?ll suggest a > number of changes using a PR on the asciidoc and unit test sources in the > coming weeks. > > Regards, > > Karel > > > > On 25 Feb 2016, at 10:52, Vlad Mihalcea wrote: > > > > Hi Karel, > > > > I pushed the first version of the Spatial chapter into the new User > Guide. > > I basically integrated the hibernatespatial.org documentation and > changed all examples to match the current API in Hibernate 5. > > > > You can build the User Guide as follows: > > > > $ cd documentation > > $ gradle rUG > > $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html > > > > Let me know what you think and what else do you suggest we should add. > > > > Thanks, > > Vlad > > > > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea > wrote: > > Hi, > > > > I already started the Spatial chapter in the new User Guide. > > I'm using your documentation as a starting point and build on top of > that. > > > > All examples are built as unit tests so we are notified when things will > change. > > I'll integrate it when I'm done and I'll send you an email with some > steps to build the User Guide. > > After you review it, I'll collect all your findings improve it further. > > > > Vlad > > > > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen wrote: > > Hi Vlad, > > > > I think this is a good idea. I?m away on conference the second week of > March, but afterwards I can make some time to help you write it up. > > > > Regards, > > > > Karel > > > > > On 20 Feb 2016, at 22:22, Vlad Mihalcea > wrote: > > > > > > Hi Karel, > > > > > > Next week, I'm going to finish the SQL native chapter and then I have > just the OSGI and Envers chapters to review. > > > But since Hibernate Spatial is not covered at all, I think it's good > to start with Hibernate Spatial right after I'm done with the SQL native > one. > > > > > > What do you think of this? > > > > > > Vlad > > > > > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen > wrote: > > > HI all, > > > > > > First, there seems to be a problem with the hibernate-spatial mailing > list that I was unaware of. The user in question reached out to me > yesterday. I will investigate shortly. > > > > > > Fair point about the website not mentioning the move to Hibernate 5. I > will put up a message for this on the site. > > > > > > For the near future what I?m hoping for is that first, we can have the > hibernate spatial tutorial updated to version 5, and integrated into the > Hibernate User Guide. After that I can have the hibernatespatial.org > URL?s redirect to that chapter. To support users of the older versions (3.x > and 4.x), we should also make sure that users can download older versions > of hibernate-spatial jars, and can consult older versions of the spatial > tutorial from the hibernate.org website. > > > > > > As for the mailing lists, I plan on announcing shortly that they will > be discontinued by end of year, and that questions should be asked on the > usual hibernate channels. Btw, how can I be notified about questions about > Spatial on the hibernate forums? > > > > > > Vlad, have you some idea about time frame for starting on the > Hibernate Spatial chapter? > > > > > > Regards, > > > > > > Karel > > > > > > > > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea > wrote: > > > > > > > > I also plan on writing a Hibernate Spatial Chapter in the new User > Guide so > > > > we can complete the migration. > > > > But first, I need to finish the remaining chapters from the current > User > > > > Guide. > > > > > > > > Vlad > > > > > > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto < > daltodavide at gmail.com> > > > > wrote: > > > > > > > >> The user registered to the hibernate-spatial mailing list but none > of his > > > >> messages > > > >> appeared in the archive. > > > >> > > > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole < > steve at hibernate.org> > > > >> wrote: > > > >> > > > >>> Karel, a user was asking about problems using the hibernate-spatial > > > >> mailing > > > >>> list on IRC which precipitated a discussion about how we want deal > with > > > >>> these things moving forward. For example, the > > > >>> http://www.hibernatespatial.org/ site is still up and running and > really > > > >>> has no indication that the move to integrate Spatial into Hibernate > > > >> proper > > > >>> was completed. What do you want to have happen with that > website/URL? > > > >>> > > > >>> As for other infrastructure, what would you like to have happen? > It > > > >> seems > > > >>> like hibernate-spatial is a more user-focused mailing list, as > opposed > > > >> to a > > > >>> dev mailing list? If so, Hibernate does not really do user mailing > > > >> lists. > > > >>> We prefer the forums or StackOverflow for user questions, so there > is > > > >> not a > > > >>> straight "migration". You can obviously keep the hibernate-spatial > > > >> mailing > > > >>> list running too, but we should have some idea how to help users > who are > > > >>> having trouble with it on the website (which website depends on > what you > > > >>> decide to do with http://www.hibernatespatial.org/. > > > >>> > > > >>> Any other things we should discuss in terms of infrastructure? > > > >>> > > > >>> Davide, what was the exact problem the user on IRC was complaining > about > > > >>> wrt the hibernate-spatial mailing list? > > > >>> _______________________________________________ > > > >>> 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 mihalcea.vlad at gmail.com Sun Apr 17 13:43:36 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Sun, 17 Apr 2016 20:43:36 +0300 Subject: [hibernate-dev] http://www.hibernatespatial.org/ In-Reply-To: References: <954A7731-4E9E-41B7-9875-992A1E70CC92@geovise.com> <6D9F66D9-9BC9-4AA8-9D84-2BDC1A313598@geovise.com> <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> Message-ID: Hi, Thanks for the update. I'm going to integrate it next week after the Session->EntityFactory merge. Vlad On Sun, Apr 17, 2016 at 5:12 PM, Karel Maesen wrote: > Hi Vlad, > > I've created a PR (#1334) that contains a number of corrections and > additions for the User Guide. > > Regards, > > Karel > > On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen wrote: > >> Hi Vlad, >> >> Thanks for doing this already. It?s a good starting point. I?ll suggest a >> number of changes using a PR on the asciidoc and unit test sources in the >> coming weeks. >> >> Regards, >> >> Karel >> >> >> > On 25 Feb 2016, at 10:52, Vlad Mihalcea >> wrote: >> > >> > Hi Karel, >> > >> > I pushed the first version of the Spatial chapter into the new User >> Guide. >> > I basically integrated the hibernatespatial.org documentation and >> changed all examples to match the current API in Hibernate 5. >> > >> > You can build the User Guide as follows: >> > >> > $ cd documentation >> > $ gradle rUG >> > $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html >> > >> > Let me know what you think and what else do you suggest we should add. >> > >> > Thanks, >> > Vlad >> > >> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea >> wrote: >> > Hi, >> > >> > I already started the Spatial chapter in the new User Guide. >> > I'm using your documentation as a starting point and build on top of >> that. >> > >> > All examples are built as unit tests so we are notified when things >> will change. >> > I'll integrate it when I'm done and I'll send you an email with some >> steps to build the User Guide. >> > After you review it, I'll collect all your findings improve it further. >> > >> > Vlad >> > >> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen >> wrote: >> > Hi Vlad, >> > >> > I think this is a good idea. I?m away on conference the second week of >> March, but afterwards I can make some time to help you write it up. >> > >> > Regards, >> > >> > Karel >> > >> > > On 20 Feb 2016, at 22:22, Vlad Mihalcea >> wrote: >> > > >> > > Hi Karel, >> > > >> > > Next week, I'm going to finish the SQL native chapter and then I have >> just the OSGI and Envers chapters to review. >> > > But since Hibernate Spatial is not covered at all, I think it's good >> to start with Hibernate Spatial right after I'm done with the SQL native >> one. >> > > >> > > What do you think of this? >> > > >> > > Vlad >> > > >> > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen >> wrote: >> > > HI all, >> > > >> > > First, there seems to be a problem with the hibernate-spatial mailing >> list that I was unaware of. The user in question reached out to me >> yesterday. I will investigate shortly. >> > > >> > > Fair point about the website not mentioning the move to Hibernate 5. >> I will put up a message for this on the site. >> > > >> > > For the near future what I?m hoping for is that first, we can have >> the hibernate spatial tutorial updated to version 5, and integrated into >> the Hibernate User Guide. After that I can have the hibernatespatial.org >> URL?s redirect to that chapter. To support users of the older versions (3.x >> and 4.x), we should also make sure that users can download older versions >> of hibernate-spatial jars, and can consult older versions of the spatial >> tutorial from the hibernate.org website. >> > > >> > > As for the mailing lists, I plan on announcing shortly that they will >> be discontinued by end of year, and that questions should be asked on the >> usual hibernate channels. Btw, how can I be notified about questions about >> Spatial on the hibernate forums? >> > > >> > > Vlad, have you some idea about time frame for starting on the >> Hibernate Spatial chapter? >> > > >> > > Regards, >> > > >> > > Karel >> > > >> > > >> > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea >> wrote: >> > > > >> > > > I also plan on writing a Hibernate Spatial Chapter in the new User >> Guide so >> > > > we can complete the migration. >> > > > But first, I need to finish the remaining chapters from the current >> User >> > > > Guide. >> > > > >> > > > Vlad >> > > > >> > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto < >> daltodavide at gmail.com> >> > > > wrote: >> > > > >> > > >> The user registered to the hibernate-spatial mailing list but none >> of his >> > > >> messages >> > > >> appeared in the archive. >> > > >> >> > > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole < >> steve at hibernate.org> >> > > >> wrote: >> > > >> >> > > >>> Karel, a user was asking about problems using the >> hibernate-spatial >> > > >> mailing >> > > >>> list on IRC which precipitated a discussion about how we want >> deal with >> > > >>> these things moving forward. For example, the >> > > >>> http://www.hibernatespatial.org/ site is still up and running >> and really >> > > >>> has no indication that the move to integrate Spatial into >> Hibernate >> > > >> proper >> > > >>> was completed. What do you want to have happen with that >> website/URL? >> > > >>> >> > > >>> As for other infrastructure, what would you like to have happen? >> It >> > > >> seems >> > > >>> like hibernate-spatial is a more user-focused mailing list, as >> opposed >> > > >> to a >> > > >>> dev mailing list? If so, Hibernate does not really do user >> mailing >> > > >> lists. >> > > >>> We prefer the forums or StackOverflow for user questions, so >> there is >> > > >> not a >> > > >>> straight "migration". You can obviously keep the >> hibernate-spatial >> > > >> mailing >> > > >>> list running too, but we should have some idea how to help users >> who are >> > > >>> having trouble with it on the website (which website depends on >> what you >> > > >>> decide to do with http://www.hibernatespatial.org/. >> > > >>> >> > > >>> Any other things we should discuss in terms of infrastructure? >> > > >>> >> > > >>> Davide, what was the exact problem the user on IRC was >> complaining about >> > > >>> wrt the hibernate-spatial mailing list? >> > > >>> _______________________________________________ >> > > >>> 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 mincong.h at gmail.com Mon Apr 18 05:05:56 2016 From: mincong.h at gmail.com (Mincong Huang) Date: Mon, 18 Apr 2016 11:05:56 +0200 Subject: [hibernate-dev] A warmup task: HSEARCH-2207 In-Reply-To: References: Message-ID: Hi Sanne and Gunnar, I've made my first pull request to Hibernate Search : https://github.com/hibernate/hibernate-search/pull/1065 Cheers, Mincong On Sun, Apr 17, 2016 at 12:35 AM, Mincong Huang wrote: > Hi Sanne and Gunnar, > > I've read some docs and understand better about Apache Lucene and > Hibernate Search now. > > Concerned about the HSEARCH-2207, I'm working on it. You can see my blog > - Starting Hibernate Search > > > for advances. I'll try to commit tomorrow or maybe Monday. This email is > just keep you informed :) > > By the way, is there any way to boost maven install ? It takes me 7 min to > run the project. > I use the following command line (1 thread by processor) > > $ mvn clean install -s settings-example.xml -T 1C > > But "-T 1C" does not really help much. > > Good night, > Mincong > > On Wed, Apr 13, 2016 at 11:36 PM, Mincong Huang > wrote: > >> Thanks for your encouragement, I'll keep working on it :) >> >> Mincong >> >> On Wed, Apr 13, 2016 at 9:01 AM, Gunnar Morling >> wrote: >> >>> Hey Mincong, >>> >>> Nice! Looking forward to your pull request for this issue very much. >>> >>> Thanks, >>> >>> --Gunnar >>> >>> >>> >>> 2016-04-13 1:32 GMT+02:00 Sanne Grinovero : >>> >>>> Hi Mincong, >>>> great start! >>>> >>>> I've added you to the right groups on JIRA, so now HSEARCH-2207 is >>>> assigned to you. >>>> >>>> To be allowed to send emails to the hibernate dev mailinst list you >>>> have to register first: >>>> - https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> Thanks, >>>> Sanne >>>> >>>> >>>> On 12 April 2016 at 22:55, Mincong Huang wrote: >>>> > Hi Sanne ant Gunner, >>>> > >>>> > Concerned with the issue HSEARCH-2207, I'm studying on it. >>>> > >>>> > I created a demo and write a blog about boolean query in Apache >>>> Lucene. >>>> > As for Hibernate Search, I still not start learning it. I'll probably >>>> start >>>> > this weekend. >>>> > For instant, my priority is to understand the index, query and >>>> analyzer in >>>> > Lucene. >>>> > >>>> > My JIRA account is mincong.h at gmail.com >>>> > >>>> > I'm not allowed to send email to hibernate dev list, so it isn't in >>>> cc. >>>> > >>>> > Cheers, >>>> > Mincong >>>> > >>>> > >>>> > >>>> > >>>> > On Sat, Apr 9, 2016 at 8:27 PM, Mincong Huang >>>> wrote: >>>> >> >>>> >> Hi Sanne, >>>> >> >>>> >> Thanks for your email. No, it won't be boring at all. On the >>>> contrary, >>>> >> this will be a great beginning ! >>>> >> I'll take a look on the issue and keep you informed. As for the JIRA >>>> >> account, here's the mine : >>>> >> mincong.h at gmail.com >>>> >> >>>> >> Cheers, >>>> >> Mincong >>>> >> >>>> >> >>>> >> On Fri, Apr 8, 2016 at 2:35 PM, Sanne Grinovero >>> > >>>> >> wrote: >>>> >>> >>>> >>> Hi Mincong, >>>> >>> >>>> >>> Gunnar suggested that I find a first task for you to familiarize >>>> with >>>> >>> the project, and to have you practice the process of creating >>>> patches >>>> >>> and proposing them for integration over GitHub. >>>> >>> >>>> >>> I think this issue could be suited: >>>> >>> - https://hibernate.atlassian.net/browse/HSEARCH-2207 >>>> >>> >>>> >>> I hope it's not too boring! It's not just an exercise, we need that >>>> >>> done so it would be a valuable contribution already. >>>> >>> >>>> >>> Do you have an account on our JIRA server? If not create one, then >>>> let >>>> >>> me know your user id so I can assign the issue to you. >>>> >>> >>>> >>> Thanks, >>>> >>> Sanne >>>> >> >>>> >> >>>> > >>>> >>> >>> >> > From gunnar at hibernate.org Mon Apr 18 05:09:19 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 18 Apr 2016 11:09:19 +0200 Subject: [hibernate-dev] A warmup task: HSEARCH-2207 In-Reply-To: References: Message-ID: Thanks, that's very nice. Going to look into it soon! 2016-04-18 11:05 GMT+02:00 Mincong Huang : > Hi Sanne and Gunnar, > > I've made my first pull request to Hibernate Search : > https://github.com/hibernate/hibernate-search/pull/1065 > > Cheers, > Mincong > > On Sun, Apr 17, 2016 at 12:35 AM, Mincong Huang > wrote: > >> Hi Sanne and Gunnar, >> >> I've read some docs and understand better about Apache Lucene and >> Hibernate Search now. >> >> Concerned about the HSEARCH-2207, I'm working on it. You can see my blog >> - Starting Hibernate Search >> >> >> for advances. I'll try to commit tomorrow or maybe Monday. This email is >> just keep you informed :) >> >> By the way, is there any way to boost maven install ? It takes me 7 min >> to run the project. >> I use the following command line (1 thread by processor) >> >> $ mvn clean install -s settings-example.xml -T 1C >> >> But "-T 1C" does not really help much. >> >> Good night, >> Mincong >> >> On Wed, Apr 13, 2016 at 11:36 PM, Mincong Huang >> wrote: >> >>> Thanks for your encouragement, I'll keep working on it :) >>> >>> Mincong >>> >>> On Wed, Apr 13, 2016 at 9:01 AM, Gunnar Morling >>> wrote: >>> >>>> Hey Mincong, >>>> >>>> Nice! Looking forward to your pull request for this issue very much. >>>> >>>> Thanks, >>>> >>>> --Gunnar >>>> >>>> >>>> >>>> 2016-04-13 1:32 GMT+02:00 Sanne Grinovero : >>>> >>>>> Hi Mincong, >>>>> great start! >>>>> >>>>> I've added you to the right groups on JIRA, so now HSEARCH-2207 is >>>>> assigned to you. >>>>> >>>>> To be allowed to send emails to the hibernate dev mailinst list you >>>>> have to register first: >>>>> - https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>> >>>>> Thanks, >>>>> Sanne >>>>> >>>>> >>>>> On 12 April 2016 at 22:55, Mincong Huang wrote: >>>>> > Hi Sanne ant Gunner, >>>>> > >>>>> > Concerned with the issue HSEARCH-2207, I'm studying on it. >>>>> > >>>>> > I created a demo and write a blog about boolean query in Apache >>>>> Lucene. >>>>> > As for Hibernate Search, I still not start learning it. I'll >>>>> probably start >>>>> > this weekend. >>>>> > For instant, my priority is to understand the index, query and >>>>> analyzer in >>>>> > Lucene. >>>>> > >>>>> > My JIRA account is mincong.h at gmail.com >>>>> > >>>>> > I'm not allowed to send email to hibernate dev list, so it isn't in >>>>> cc. >>>>> > >>>>> > Cheers, >>>>> > Mincong >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > On Sat, Apr 9, 2016 at 8:27 PM, Mincong Huang >>>>> wrote: >>>>> >> >>>>> >> Hi Sanne, >>>>> >> >>>>> >> Thanks for your email. No, it won't be boring at all. On the >>>>> contrary, >>>>> >> this will be a great beginning ! >>>>> >> I'll take a look on the issue and keep you informed. As for the JIRA >>>>> >> account, here's the mine : >>>>> >> mincong.h at gmail.com >>>>> >> >>>>> >> Cheers, >>>>> >> Mincong >>>>> >> >>>>> >> >>>>> >> On Fri, Apr 8, 2016 at 2:35 PM, Sanne Grinovero < >>>>> sanne at hibernate.org> >>>>> >> wrote: >>>>> >>> >>>>> >>> Hi Mincong, >>>>> >>> >>>>> >>> Gunnar suggested that I find a first task for you to familiarize >>>>> with >>>>> >>> the project, and to have you practice the process of creating >>>>> patches >>>>> >>> and proposing them for integration over GitHub. >>>>> >>> >>>>> >>> I think this issue could be suited: >>>>> >>> - https://hibernate.atlassian.net/browse/HSEARCH-2207 >>>>> >>> >>>>> >>> I hope it's not too boring! It's not just an exercise, we need that >>>>> >>> done so it would be a valuable contribution already. >>>>> >>> >>>>> >>> Do you have an account on our JIRA server? If not create one, then >>>>> let >>>>> >>> me know your user id so I can assign the issue to you. >>>>> >>> >>>>> >>> Thanks, >>>>> >>> Sanne >>>>> >> >>>>> >> >>>>> > >>>>> >>>> >>>> >>> >> > From mincong.h at gmail.com Mon Apr 18 05:50:43 2016 From: mincong.h at gmail.com (Mincong Huang) Date: Mon, 18 Apr 2016 11:50:43 +0200 Subject: [hibernate-dev] A warmup task: HSEARCH-2207 In-Reply-To: References: Message-ID: The test result looks good :) On Mon, Apr 18, 2016 at 11:09 AM, Gunnar Morling wrote: > Thanks, that's very nice. Going to look into it soon! > > 2016-04-18 11:05 GMT+02:00 Mincong Huang : > >> Hi Sanne and Gunnar, >> >> I've made my first pull request to Hibernate Search : >> https://github.com/hibernate/hibernate-search/pull/1065 >> >> Cheers, >> Mincong >> >> On Sun, Apr 17, 2016 at 12:35 AM, Mincong Huang >> wrote: >> >>> Hi Sanne and Gunnar, >>> >>> I've read some docs and understand better about Apache Lucene and >>> Hibernate Search now. >>> >>> Concerned about the HSEARCH-2207, I'm working on it. You can see my blog >>> - Starting Hibernate Search >>> >>> >>> for advances. I'll try to commit tomorrow or maybe Monday. This email is >>> just keep you informed :) >>> >>> By the way, is there any way to boost maven install ? It takes me 7 min >>> to run the project. >>> I use the following command line (1 thread by processor) >>> >>> $ mvn clean install -s settings-example.xml -T 1C >>> >>> But "-T 1C" does not really help much. >>> >>> Good night, >>> Mincong >>> >>> On Wed, Apr 13, 2016 at 11:36 PM, Mincong Huang >>> wrote: >>> >>>> Thanks for your encouragement, I'll keep working on it :) >>>> >>>> Mincong >>>> >>>> On Wed, Apr 13, 2016 at 9:01 AM, Gunnar Morling >>>> wrote: >>>> >>>>> Hey Mincong, >>>>> >>>>> Nice! Looking forward to your pull request for this issue very much. >>>>> >>>>> Thanks, >>>>> >>>>> --Gunnar >>>>> >>>>> >>>>> >>>>> 2016-04-13 1:32 GMT+02:00 Sanne Grinovero : >>>>> >>>>>> Hi Mincong, >>>>>> great start! >>>>>> >>>>>> I've added you to the right groups on JIRA, so now HSEARCH-2207 is >>>>>> assigned to you. >>>>>> >>>>>> To be allowed to send emails to the hibernate dev mailinst list you >>>>>> have to register first: >>>>>> - https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> >>>>>> >>>>>> On 12 April 2016 at 22:55, Mincong Huang wrote: >>>>>> > Hi Sanne ant Gunner, >>>>>> > >>>>>> > Concerned with the issue HSEARCH-2207, I'm studying on it. >>>>>> > >>>>>> > I created a demo and write a blog about boolean query in Apache >>>>>> Lucene. >>>>>> > As for Hibernate Search, I still not start learning it. I'll >>>>>> probably start >>>>>> > this weekend. >>>>>> > For instant, my priority is to understand the index, query and >>>>>> analyzer in >>>>>> > Lucene. >>>>>> > >>>>>> > My JIRA account is mincong.h at gmail.com >>>>>> > >>>>>> > I'm not allowed to send email to hibernate dev list, so it isn't in >>>>>> cc. >>>>>> > >>>>>> > Cheers, >>>>>> > Mincong >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Sat, Apr 9, 2016 at 8:27 PM, Mincong Huang >>>>>> wrote: >>>>>> >> >>>>>> >> Hi Sanne, >>>>>> >> >>>>>> >> Thanks for your email. No, it won't be boring at all. On the >>>>>> contrary, >>>>>> >> this will be a great beginning ! >>>>>> >> I'll take a look on the issue and keep you informed. As for the >>>>>> JIRA >>>>>> >> account, here's the mine : >>>>>> >> mincong.h at gmail.com >>>>>> >> >>>>>> >> Cheers, >>>>>> >> Mincong >>>>>> >> >>>>>> >> >>>>>> >> On Fri, Apr 8, 2016 at 2:35 PM, Sanne Grinovero < >>>>>> sanne at hibernate.org> >>>>>> >> wrote: >>>>>> >>> >>>>>> >>> Hi Mincong, >>>>>> >>> >>>>>> >>> Gunnar suggested that I find a first task for you to familiarize >>>>>> with >>>>>> >>> the project, and to have you practice the process of creating >>>>>> patches >>>>>> >>> and proposing them for integration over GitHub. >>>>>> >>> >>>>>> >>> I think this issue could be suited: >>>>>> >>> - https://hibernate.atlassian.net/browse/HSEARCH-2207 >>>>>> >>> >>>>>> >>> I hope it's not too boring! It's not just an exercise, we need >>>>>> that >>>>>> >>> done so it would be a valuable contribution already. >>>>>> >>> >>>>>> >>> Do you have an account on our JIRA server? If not create one, >>>>>> then let >>>>>> >>> me know your user id so I can assign the issue to you. >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> Sanne >>>>>> >> >>>>>> >> >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> > From sanne at hibernate.org Mon Apr 18 06:25:08 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 18 Apr 2016 12:25:08 +0200 Subject: [hibernate-dev] http://www.hibernatespatial.org/ In-Reply-To: References: <954A7731-4E9E-41B7-9875-992A1E70CC92@geovise.com> <6D9F66D9-9BC9-4AA8-9D84-2BDC1A313598@geovise.com> <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> Message-ID: On 17 April 2016 at 19:43, Vlad Mihalcea wrote: > Hi, > > Thanks for the update. I'm going to integrate it next week after the > Session->EntityFactory merge. Best to double-check with Steve, but I believe updates to the user guide might not need to wait for his refactoring work to be completed? > > Vlad > > On Sun, Apr 17, 2016 at 5:12 PM, Karel Maesen wrote: > >> Hi Vlad, >> >> I've created a PR (#1334) that contains a number of corrections and >> additions for the User Guide. >> >> Regards, >> >> Karel >> >> On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen wrote: >> >>> Hi Vlad, >>> >>> Thanks for doing this already. It?s a good starting point. I?ll suggest a >>> number of changes using a PR on the asciidoc and unit test sources in the >>> coming weeks. >>> >>> Regards, >>> >>> Karel >>> >>> >>> > On 25 Feb 2016, at 10:52, Vlad Mihalcea >>> wrote: >>> > >>> > Hi Karel, >>> > >>> > I pushed the first version of the Spatial chapter into the new User >>> Guide. >>> > I basically integrated the hibernatespatial.org documentation and >>> changed all examples to match the current API in Hibernate 5. >>> > >>> > You can build the User Guide as follows: >>> > >>> > $ cd documentation >>> > $ gradle rUG >>> > $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html >>> > >>> > Let me know what you think and what else do you suggest we should add. >>> > >>> > Thanks, >>> > Vlad >>> > >>> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea >>> wrote: >>> > Hi, >>> > >>> > I already started the Spatial chapter in the new User Guide. >>> > I'm using your documentation as a starting point and build on top of >>> that. >>> > >>> > All examples are built as unit tests so we are notified when things >>> will change. >>> > I'll integrate it when I'm done and I'll send you an email with some >>> steps to build the User Guide. >>> > After you review it, I'll collect all your findings improve it further. >>> > >>> > Vlad >>> > >>> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen >>> wrote: >>> > Hi Vlad, >>> > >>> > I think this is a good idea. I?m away on conference the second week of >>> March, but afterwards I can make some time to help you write it up. >>> > >>> > Regards, >>> > >>> > Karel >>> > >>> > > On 20 Feb 2016, at 22:22, Vlad Mihalcea >>> wrote: >>> > > >>> > > Hi Karel, >>> > > >>> > > Next week, I'm going to finish the SQL native chapter and then I have >>> just the OSGI and Envers chapters to review. >>> > > But since Hibernate Spatial is not covered at all, I think it's good >>> to start with Hibernate Spatial right after I'm done with the SQL native >>> one. >>> > > >>> > > What do you think of this? >>> > > >>> > > Vlad >>> > > >>> > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen >>> wrote: >>> > > HI all, >>> > > >>> > > First, there seems to be a problem with the hibernate-spatial mailing >>> list that I was unaware of. The user in question reached out to me >>> yesterday. I will investigate shortly. >>> > > >>> > > Fair point about the website not mentioning the move to Hibernate 5. >>> I will put up a message for this on the site. >>> > > >>> > > For the near future what I?m hoping for is that first, we can have >>> the hibernate spatial tutorial updated to version 5, and integrated into >>> the Hibernate User Guide. After that I can have the hibernatespatial.org >>> URL?s redirect to that chapter. To support users of the older versions (3.x >>> and 4.x), we should also make sure that users can download older versions >>> of hibernate-spatial jars, and can consult older versions of the spatial >>> tutorial from the hibernate.org website. >>> > > >>> > > As for the mailing lists, I plan on announcing shortly that they will >>> be discontinued by end of year, and that questions should be asked on the >>> usual hibernate channels. Btw, how can I be notified about questions about >>> Spatial on the hibernate forums? >>> > > >>> > > Vlad, have you some idea about time frame for starting on the >>> Hibernate Spatial chapter? >>> > > >>> > > Regards, >>> > > >>> > > Karel >>> > > >>> > > >>> > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea >>> wrote: >>> > > > >>> > > > I also plan on writing a Hibernate Spatial Chapter in the new User >>> Guide so >>> > > > we can complete the migration. >>> > > > But first, I need to finish the remaining chapters from the current >>> User >>> > > > Guide. >>> > > > >>> > > > Vlad >>> > > > >>> > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto < >>> daltodavide at gmail.com> >>> > > > wrote: >>> > > > >>> > > >> The user registered to the hibernate-spatial mailing list but none >>> of his >>> > > >> messages >>> > > >> appeared in the archive. >>> > > >> >>> > > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole < >>> steve at hibernate.org> >>> > > >> wrote: >>> > > >> >>> > > >>> Karel, a user was asking about problems using the >>> hibernate-spatial >>> > > >> mailing >>> > > >>> list on IRC which precipitated a discussion about how we want >>> deal with >>> > > >>> these things moving forward. For example, the >>> > > >>> http://www.hibernatespatial.org/ site is still up and running >>> and really >>> > > >>> has no indication that the move to integrate Spatial into >>> Hibernate >>> > > >> proper >>> > > >>> was completed. What do you want to have happen with that >>> website/URL? >>> > > >>> >>> > > >>> As for other infrastructure, what would you like to have happen? >>> It >>> > > >> seems >>> > > >>> like hibernate-spatial is a more user-focused mailing list, as >>> opposed >>> > > >> to a >>> > > >>> dev mailing list? If so, Hibernate does not really do user >>> mailing >>> > > >> lists. >>> > > >>> We prefer the forums or StackOverflow for user questions, so >>> there is >>> > > >> not a >>> > > >>> straight "migration". You can obviously keep the >>> hibernate-spatial >>> > > >> mailing >>> > > >>> list running too, but we should have some idea how to help users >>> who are >>> > > >>> having trouble with it on the website (which website depends on >>> what you >>> > > >>> decide to do with http://www.hibernatespatial.org/. >>> > > >>> >>> > > >>> Any other things we should discuss in terms of infrastructure? >>> > > >>> >>> > > >>> Davide, what was the exact problem the user on IRC was >>> complaining about >>> > > >>> wrt the hibernate-spatial mailing list? >>> > > >>> _______________________________________________ >>> > > >>> 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 Mon Apr 18 08:15:01 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 18 Apr 2016 13:15:01 +0100 Subject: [hibernate-dev] To require or not to require a JIRA for a small-typo kind of commit Message-ID: This question came up again on github; seems Gunnar, Davide and myself would agree on preferring a little more flexibility on the no-orm projects than ORM's guidelines: - https://github.com/hibernate/hibernate-search/pull/1064#issuecomment-211320931 This flexibility would be a perk for regular contributors only so I don't feel a need to move our conclusions to a formal document, yet I'm bringing it up here so you can all see it, and voice concerns / approval now :) Thanks, Sanne From guillaume.smet at gmail.com Mon Apr 18 08:48:42 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 18 Apr 2016 14:48:42 +0200 Subject: [hibernate-dev] To require or not to require a JIRA for a small-typo kind of commit In-Reply-To: References: Message-ID: OK for me too. That's what I was told when I asked the question a while ago :). On Mon, Apr 18, 2016 at 2:15 PM, Sanne Grinovero wrote: > This question came up again on github; seems Gunnar, Davide and myself > would agree on preferring a little more flexibility on the no-orm > projects than ORM's guidelines: > > - > https://github.com/hibernate/hibernate-search/pull/1064#issuecomment-211320931 > > > This flexibility would be a perk for regular contributors only so I > don't feel a need to move our conclusions to a formal document, yet > I'm bringing it up here so you can all see it, and voice concerns / > approval now :) > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Mon Apr 18 08:54:16 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 18 Apr 2016 15:54:16 +0300 Subject: [hibernate-dev] To require or not to require a JIRA for a small-typo kind of commit In-Reply-To: References: Message-ID: +1 Vlad On Mon, Apr 18, 2016 at 3:48 PM, Guillaume Smet wrote: > OK for me too. That's what I was told when I asked the question a while ago > :). > > On Mon, Apr 18, 2016 at 2:15 PM, Sanne Grinovero > wrote: > > > This question came up again on github; seems Gunnar, Davide and myself > > would agree on preferring a little more flexibility on the no-orm > > projects than ORM's guidelines: > > > > - > > > https://github.com/hibernate/hibernate-search/pull/1064#issuecomment-211320931 > > > > > > This flexibility would be a perk for regular contributors only so I > > don't feel a need to move our conclusions to a formal document, yet > > I'm bringing it up here so you can all see it, and voice concerns / > > approval now :) > > > > 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 Apr 18 11:19:52 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 18 Apr 2016 15:19:52 +0000 Subject: [hibernate-dev] http://www.hibernatespatial.org/ In-Reply-To: References: <954A7731-4E9E-41B7-9875-992A1E70CC92@geovise.com> <6D9F66D9-9BC9-4AA8-9D84-2BDC1A313598@geovise.com> <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> Message-ID: The User Guide will definitely need some updates for 5.2, but none of my changed so far have touched User Guide sources. On Mon, Apr 18, 2016 at 5:25 AM Sanne Grinovero wrote: > On 17 April 2016 at 19:43, Vlad Mihalcea wrote: > > Hi, > > > > Thanks for the update. I'm going to integrate it next week after the > > Session->EntityFactory merge. > > Best to double-check with Steve, but I believe updates to the user > guide might not need to wait for his refactoring work to be completed? > > > > > Vlad > > > > On Sun, Apr 17, 2016 at 5:12 PM, Karel Maesen wrote: > > > >> Hi Vlad, > >> > >> I've created a PR (#1334) that contains a number of corrections and > >> additions for the User Guide. > >> > >> Regards, > >> > >> Karel > >> > >> On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen > wrote: > >> > >>> Hi Vlad, > >>> > >>> Thanks for doing this already. It?s a good starting point. I?ll > suggest a > >>> number of changes using a PR on the asciidoc and unit test sources in > the > >>> coming weeks. > >>> > >>> Regards, > >>> > >>> Karel > >>> > >>> > >>> > On 25 Feb 2016, at 10:52, Vlad Mihalcea > >>> wrote: > >>> > > >>> > Hi Karel, > >>> > > >>> > I pushed the first version of the Spatial chapter into the new User > >>> Guide. > >>> > I basically integrated the hibernatespatial.org documentation and > >>> changed all examples to match the current API in Hibernate 5. > >>> > > >>> > You can build the User Guide as follows: > >>> > > >>> > $ cd documentation > >>> > $ gradle rUG > >>> > $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html > >>> > > >>> > Let me know what you think and what else do you suggest we should > add. > >>> > > >>> > Thanks, > >>> > Vlad > >>> > > >>> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea < > mihalcea.vlad at gmail.com> > >>> wrote: > >>> > Hi, > >>> > > >>> > I already started the Spatial chapter in the new User Guide. > >>> > I'm using your documentation as a starting point and build on top of > >>> that. > >>> > > >>> > All examples are built as unit tests so we are notified when things > >>> will change. > >>> > I'll integrate it when I'm done and I'll send you an email with some > >>> steps to build the User Guide. > >>> > After you review it, I'll collect all your findings improve it > further. > >>> > > >>> > Vlad > >>> > > >>> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen > >>> wrote: > >>> > Hi Vlad, > >>> > > >>> > I think this is a good idea. I?m away on conference the second week > of > >>> March, but afterwards I can make some time to help you write it up. > >>> > > >>> > Regards, > >>> > > >>> > Karel > >>> > > >>> > > On 20 Feb 2016, at 22:22, Vlad Mihalcea > >>> wrote: > >>> > > > >>> > > Hi Karel, > >>> > > > >>> > > Next week, I'm going to finish the SQL native chapter and then I > have > >>> just the OSGI and Envers chapters to review. > >>> > > But since Hibernate Spatial is not covered at all, I think it's > good > >>> to start with Hibernate Spatial right after I'm done with the SQL > native > >>> one. > >>> > > > >>> > > What do you think of this? > >>> > > > >>> > > Vlad > >>> > > > >>> > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen > >>> wrote: > >>> > > HI all, > >>> > > > >>> > > First, there seems to be a problem with the hibernate-spatial > mailing > >>> list that I was unaware of. The user in question reached out to me > >>> yesterday. I will investigate shortly. > >>> > > > >>> > > Fair point about the website not mentioning the move to Hibernate > 5. > >>> I will put up a message for this on the site. > >>> > > > >>> > > For the near future what I?m hoping for is that first, we can have > >>> the hibernate spatial tutorial updated to version 5, and integrated > into > >>> the Hibernate User Guide. After that I can have the > hibernatespatial.org > >>> URL?s redirect to that chapter. To support users of the older versions > (3.x > >>> and 4.x), we should also make sure that users can download older > versions > >>> of hibernate-spatial jars, and can consult older versions of the > spatial > >>> tutorial from the hibernate.org website. > >>> > > > >>> > > As for the mailing lists, I plan on announcing shortly that they > will > >>> be discontinued by end of year, and that questions should be asked on > the > >>> usual hibernate channels. Btw, how can I be notified about questions > about > >>> Spatial on the hibernate forums? > >>> > > > >>> > > Vlad, have you some idea about time frame for starting on the > >>> Hibernate Spatial chapter? > >>> > > > >>> > > Regards, > >>> > > > >>> > > Karel > >>> > > > >>> > > > >>> > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea > > >>> wrote: > >>> > > > > >>> > > > I also plan on writing a Hibernate Spatial Chapter in the new > User > >>> Guide so > >>> > > > we can complete the migration. > >>> > > > But first, I need to finish the remaining chapters from the > current > >>> User > >>> > > > Guide. > >>> > > > > >>> > > > Vlad > >>> > > > > >>> > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto < > >>> daltodavide at gmail.com> > >>> > > > wrote: > >>> > > > > >>> > > >> The user registered to the hibernate-spatial mailing list but > none > >>> of his > >>> > > >> messages > >>> > > >> appeared in the archive. > >>> > > >> > >>> > > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole < > >>> steve at hibernate.org> > >>> > > >> wrote: > >>> > > >> > >>> > > >>> Karel, a user was asking about problems using the > >>> hibernate-spatial > >>> > > >> mailing > >>> > > >>> list on IRC which precipitated a discussion about how we want > >>> deal with > >>> > > >>> these things moving forward. For example, the > >>> > > >>> http://www.hibernatespatial.org/ site is still up and running > >>> and really > >>> > > >>> has no indication that the move to integrate Spatial into > >>> Hibernate > >>> > > >> proper > >>> > > >>> was completed. What do you want to have happen with that > >>> website/URL? > >>> > > >>> > >>> > > >>> As for other infrastructure, what would you like to have > happen? > >>> It > >>> > > >> seems > >>> > > >>> like hibernate-spatial is a more user-focused mailing list, as > >>> opposed > >>> > > >> to a > >>> > > >>> dev mailing list? If so, Hibernate does not really do user > >>> mailing > >>> > > >> lists. > >>> > > >>> We prefer the forums or StackOverflow for user questions, so > >>> there is > >>> > > >> not a > >>> > > >>> straight "migration". You can obviously keep the > >>> hibernate-spatial > >>> > > >> mailing > >>> > > >>> list running too, but we should have some idea how to help > users > >>> who are > >>> > > >>> having trouble with it on the website (which website depends on > >>> what you > >>> > > >>> decide to do with http://www.hibernatespatial.org/. > >>> > > >>> > >>> > > >>> Any other things we should discuss in terms of infrastructure? > >>> > > >>> > >>> > > >>> Davide, what was the exact problem the user on IRC was > >>> complaining about > >>> > > >>> wrt the hibernate-spatial mailing list? > >>> > > >>> _______________________________________________ > >>> > > >>> 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 Mon Apr 18 11:32:11 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 18 Apr 2016 16:32:11 +0100 Subject: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module? In-Reply-To: References: Message-ID: I think there was some confusion in this thread, probably it wasn't clear that WildFly 10 already does inject automatically OGM, and that ship sailed so we have to keep in mind what Jipijapa is going to do by default: The current state in WildFly 10's deployers is very simple: if it "sees" that the persistence.xml is defining a Persistence Provider named "org.hibernate.ogm.jpa.HibernateOgmPersistence", then it will look for a module named "org.hibernate.ogm" and inject this to the classpath. That does imply slot "main" is expected to be available. This logic can be overriden, but it requires the user to specify - and know about - additional configuration properties. We can try deciding what we want WildFly 11+ to do better in the future, but we need to decide at high priority what approach to use for OGM 5.0.0.Final, given the WildFly-was-released restriction. Now to reiterate the problem I mentioned in the first email of this thread: having just the right version of "org.hibernate.ogm" isn't good enough as one needs the specific dialect modules too. I asked (teasing) if you all could see the specific dialect options as power-user extensions, but it seems the consensus is that these are not really optional. So I guess I agree with Gunnar and Davide: [in current WildFly] one will need to use the jboss-deployment-structure.xml or the Manifest to make use of OGM, and we'll have to ignore the fact that when one of these is missing the WildFly deployer will get mad as OGM:main can't be found. More inline: On 31 March 2016 at 11:48, Gunnar Morling wrote: > So I think for the time being I'd be fine if WF didn't add anything > implicitly at all for OGM. Too late, hope that's clear now. > The reason being, that OGM is not (yet) part of WF, the user needs to put in > the modules from the ZIP themselves. So it seems acceptable to me to add the > dependencies to the required modules by hand (matching the slot of the > modules they unzipped). Yes, acceptable for the time being, but for a future version of WF it would be nice to not have users create (and learn about) yet another configuration file. > Should WF do it automatically, some logic along these lines would be needed: > > * If OGM is the persistence provider and there is only one set of OGM > modules available, add all the OGM modules actually present (e.g. the user > could have unzipped only core and one of the backends); Optionally, only add > those backend(s) actually in use as per the configuration > * If more than one set of OGM modules is available, require the user to > explicitly specify the slot > > How about doing this once OGM actually is part of WF? Then one could default > to the provided version, requiring the override only if the user wishes to > use (and provides) another version. +1 but to eventually allow WF to pick a specific OGM slot, we should first release versioned modules. I initially thought that we could provide an alias module "main -> current release" to have the jipijapa integration work in certain circumstances, but realising that the dialect-specific modules are needed too, I guess this would be pointless. So my plan is to simply switch our released modules to a specific slot, then update the documentation accordingly. Not sure how far jipijapa will try to stop me :) we might need additional JPA properties too to override it. Thanks, Sanne > > --Gunnar > > > From mihalcea.vlad at gmail.com Mon Apr 18 11:40:44 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 18 Apr 2016 18:40:44 +0300 Subject: [hibernate-dev] http://www.hibernatespatial.org/ In-Reply-To: References: <954A7731-4E9E-41B7-9875-992A1E70CC92@geovise.com> <6D9F66D9-9BC9-4AA8-9D84-2BDC1A313598@geovise.com> <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> Message-ID: I'm going to integrate it in master, 5.1, and 5.0 since theHibernate Spatial module is the same for all three, right? Vlad On Mon, Apr 18, 2016 at 6:19 PM, Steve Ebersole wrote: > The User Guide will definitely need some updates for 5.2, but none of my > changed so far have touched User Guide sources. > > On Mon, Apr 18, 2016 at 5:25 AM Sanne Grinovero > wrote: > >> On 17 April 2016 at 19:43, Vlad Mihalcea wrote: >> > Hi, >> > >> > Thanks for the update. I'm going to integrate it next week after the >> > Session->EntityFactory merge. >> >> Best to double-check with Steve, but I believe updates to the user >> guide might not need to wait for his refactoring work to be completed? >> >> > >> > Vlad >> > >> > On Sun, Apr 17, 2016 at 5:12 PM, Karel Maesen >> wrote: >> > >> >> Hi Vlad, >> >> >> >> I've created a PR (#1334) that contains a number of corrections and >> >> additions for the User Guide. >> >> >> >> Regards, >> >> >> >> Karel >> >> >> >> On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen >> wrote: >> >> >> >>> Hi Vlad, >> >>> >> >>> Thanks for doing this already. It?s a good starting point. I?ll >> suggest a >> >>> number of changes using a PR on the asciidoc and unit test sources in >> the >> >>> coming weeks. >> >>> >> >>> Regards, >> >>> >> >>> Karel >> >>> >> >>> >> >>> > On 25 Feb 2016, at 10:52, Vlad Mihalcea >> >>> wrote: >> >>> > >> >>> > Hi Karel, >> >>> > >> >>> > I pushed the first version of the Spatial chapter into the new User >> >>> Guide. >> >>> > I basically integrated the hibernatespatial.org documentation and >> >>> changed all examples to match the current API in Hibernate 5. >> >>> > >> >>> > You can build the User Guide as follows: >> >>> > >> >>> > $ cd documentation >> >>> > $ gradle rUG >> >>> > $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html >> >>> > >> >>> > Let me know what you think and what else do you suggest we should >> add. >> >>> > >> >>> > Thanks, >> >>> > Vlad >> >>> > >> >>> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea < >> mihalcea.vlad at gmail.com> >> >>> wrote: >> >>> > Hi, >> >>> > >> >>> > I already started the Spatial chapter in the new User Guide. >> >>> > I'm using your documentation as a starting point and build on top of >> >>> that. >> >>> > >> >>> > All examples are built as unit tests so we are notified when things >> >>> will change. >> >>> > I'll integrate it when I'm done and I'll send you an email with some >> >>> steps to build the User Guide. >> >>> > After you review it, I'll collect all your findings improve it >> further. >> >>> > >> >>> > Vlad >> >>> > >> >>> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen >> >>> wrote: >> >>> > Hi Vlad, >> >>> > >> >>> > I think this is a good idea. I?m away on conference the second week >> of >> >>> March, but afterwards I can make some time to help you write it up. >> >>> > >> >>> > Regards, >> >>> > >> >>> > Karel >> >>> > >> >>> > > On 20 Feb 2016, at 22:22, Vlad Mihalcea >> >>> wrote: >> >>> > > >> >>> > > Hi Karel, >> >>> > > >> >>> > > Next week, I'm going to finish the SQL native chapter and then I >> have >> >>> just the OSGI and Envers chapters to review. >> >>> > > But since Hibernate Spatial is not covered at all, I think it's >> good >> >>> to start with Hibernate Spatial right after I'm done with the SQL >> native >> >>> one. >> >>> > > >> >>> > > What do you think of this? >> >>> > > >> >>> > > Vlad >> >>> > > >> >>> > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen >> >>> wrote: >> >>> > > HI all, >> >>> > > >> >>> > > First, there seems to be a problem with the hibernate-spatial >> mailing >> >>> list that I was unaware of. The user in question reached out to me >> >>> yesterday. I will investigate shortly. >> >>> > > >> >>> > > Fair point about the website not mentioning the move to Hibernate >> 5. >> >>> I will put up a message for this on the site. >> >>> > > >> >>> > > For the near future what I?m hoping for is that first, we can have >> >>> the hibernate spatial tutorial updated to version 5, and integrated >> into >> >>> the Hibernate User Guide. After that I can have the >> hibernatespatial.org >> >>> URL?s redirect to that chapter. To support users of the older >> versions (3.x >> >>> and 4.x), we should also make sure that users can download older >> versions >> >>> of hibernate-spatial jars, and can consult older versions of the >> spatial >> >>> tutorial from the hibernate.org website. >> >>> > > >> >>> > > As for the mailing lists, I plan on announcing shortly that they >> will >> >>> be discontinued by end of year, and that questions should be asked on >> the >> >>> usual hibernate channels. Btw, how can I be notified about questions >> about >> >>> Spatial on the hibernate forums? >> >>> > > >> >>> > > Vlad, have you some idea about time frame for starting on the >> >>> Hibernate Spatial chapter? >> >>> > > >> >>> > > Regards, >> >>> > > >> >>> > > Karel >> >>> > > >> >>> > > >> >>> > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea < >> mihalcea.vlad at gmail.com> >> >>> wrote: >> >>> > > > >> >>> > > > I also plan on writing a Hibernate Spatial Chapter in the new >> User >> >>> Guide so >> >>> > > > we can complete the migration. >> >>> > > > But first, I need to finish the remaining chapters from the >> current >> >>> User >> >>> > > > Guide. >> >>> > > > >> >>> > > > Vlad >> >>> > > > >> >>> > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto < >> >>> daltodavide at gmail.com> >> >>> > > > wrote: >> >>> > > > >> >>> > > >> The user registered to the hibernate-spatial mailing list but >> none >> >>> of his >> >>> > > >> messages >> >>> > > >> appeared in the archive. >> >>> > > >> >> >>> > > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole < >> >>> steve at hibernate.org> >> >>> > > >> wrote: >> >>> > > >> >> >>> > > >>> Karel, a user was asking about problems using the >> >>> hibernate-spatial >> >>> > > >> mailing >> >>> > > >>> list on IRC which precipitated a discussion about how we want >> >>> deal with >> >>> > > >>> these things moving forward. For example, the >> >>> > > >>> http://www.hibernatespatial.org/ site is still up and running >> >>> and really >> >>> > > >>> has no indication that the move to integrate Spatial into >> >>> Hibernate >> >>> > > >> proper >> >>> > > >>> was completed. What do you want to have happen with that >> >>> website/URL? >> >>> > > >>> >> >>> > > >>> As for other infrastructure, what would you like to have >> happen? >> >>> It >> >>> > > >> seems >> >>> > > >>> like hibernate-spatial is a more user-focused mailing list, as >> >>> opposed >> >>> > > >> to a >> >>> > > >>> dev mailing list? If so, Hibernate does not really do user >> >>> mailing >> >>> > > >> lists. >> >>> > > >>> We prefer the forums or StackOverflow for user questions, so >> >>> there is >> >>> > > >> not a >> >>> > > >>> straight "migration". You can obviously keep the >> >>> hibernate-spatial >> >>> > > >> mailing >> >>> > > >>> list running too, but we should have some idea how to help >> users >> >>> who are >> >>> > > >>> having trouble with it on the website (which website depends >> on >> >>> what you >> >>> > > >>> decide to do with http://www.hibernatespatial.org/. >> >>> > > >>> >> >>> > > >>> Any other things we should discuss in terms of infrastructure? >> >>> > > >>> >> >>> > > >>> Davide, what was the exact problem the user on IRC was >> >>> complaining about >> >>> > > >>> wrt the hibernate-spatial mailing list? >> >>> > > >>> _______________________________________________ >> >>> > > >>> 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 karel at geovise.com Mon Apr 18 11:45:21 2016 From: karel at geovise.com (Karel Maesen) Date: Mon, 18 Apr 2016 17:45:21 +0200 Subject: [hibernate-dev] http://www.hibernatespatial.org/ In-Reply-To: References: <954A7731-4E9E-41B7-9875-992A1E70CC92@geovise.com> <6D9F66D9-9BC9-4AA8-9D84-2BDC1A313598@geovise.com> <0C66469D-1124-4850-8F9C-8A73DD7C1C8D@geovise.com> Message-ID: That is correct. Karel On Mon, Apr 18, 2016 at 5:40 PM, Vlad Mihalcea wrote: > I'm going to integrate it in master, 5.1, and 5.0 since theHibernate > Spatial module is the same for all three, right? > > Vlad > > On Mon, Apr 18, 2016 at 6:19 PM, Steve Ebersole > wrote: > > > The User Guide will definitely need some updates for 5.2, but none of my > > changed so far have touched User Guide sources. > > > > On Mon, Apr 18, 2016 at 5:25 AM Sanne Grinovero > > wrote: > > > >> On 17 April 2016 at 19:43, Vlad Mihalcea > wrote: > >> > Hi, > >> > > >> > Thanks for the update. I'm going to integrate it next week after the > >> > Session->EntityFactory merge. > >> > >> Best to double-check with Steve, but I believe updates to the user > >> guide might not need to wait for his refactoring work to be completed? > >> > >> > > >> > Vlad > >> > > >> > On Sun, Apr 17, 2016 at 5:12 PM, Karel Maesen > >> wrote: > >> > > >> >> Hi Vlad, > >> >> > >> >> I've created a PR (#1334) that contains a number of corrections and > >> >> additions for the User Guide. > >> >> > >> >> Regards, > >> >> > >> >> Karel > >> >> > >> >> On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen > >> wrote: > >> >> > >> >>> Hi Vlad, > >> >>> > >> >>> Thanks for doing this already. It?s a good starting point. I?ll > >> suggest a > >> >>> number of changes using a PR on the asciidoc and unit test sources > in > >> the > >> >>> coming weeks. > >> >>> > >> >>> Regards, > >> >>> > >> >>> Karel > >> >>> > >> >>> > >> >>> > On 25 Feb 2016, at 10:52, Vlad Mihalcea > >> >>> wrote: > >> >>> > > >> >>> > Hi Karel, > >> >>> > > >> >>> > I pushed the first version of the Spatial chapter into the new > User > >> >>> Guide. > >> >>> > I basically integrated the hibernatespatial.org documentation and > >> >>> changed all examples to match the current API in Hibernate 5. > >> >>> > > >> >>> > You can build the User Guide as follows: > >> >>> > > >> >>> > $ cd documentation > >> >>> > $ gradle rUG > >> >>> > $ ls > target/asciidoc/userguide/html_single/Hibernate_User_Guide.html > >> >>> > > >> >>> > Let me know what you think and what else do you suggest we should > >> add. > >> >>> > > >> >>> > Thanks, > >> >>> > Vlad > >> >>> > > >> >>> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea < > >> mihalcea.vlad at gmail.com> > >> >>> wrote: > >> >>> > Hi, > >> >>> > > >> >>> > I already started the Spatial chapter in the new User Guide. > >> >>> > I'm using your documentation as a starting point and build on top > of > >> >>> that. > >> >>> > > >> >>> > All examples are built as unit tests so we are notified when > things > >> >>> will change. > >> >>> > I'll integrate it when I'm done and I'll send you an email with > some > >> >>> steps to build the User Guide. > >> >>> > After you review it, I'll collect all your findings improve it > >> further. > >> >>> > > >> >>> > Vlad > >> >>> > > >> >>> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen > >> >>> wrote: > >> >>> > Hi Vlad, > >> >>> > > >> >>> > I think this is a good idea. I?m away on conference the second > week > >> of > >> >>> March, but afterwards I can make some time to help you write it up. > >> >>> > > >> >>> > Regards, > >> >>> > > >> >>> > Karel > >> >>> > > >> >>> > > On 20 Feb 2016, at 22:22, Vlad Mihalcea < > mihalcea.vlad at gmail.com> > >> >>> wrote: > >> >>> > > > >> >>> > > Hi Karel, > >> >>> > > > >> >>> > > Next week, I'm going to finish the SQL native chapter and then I > >> have > >> >>> just the OSGI and Envers chapters to review. > >> >>> > > But since Hibernate Spatial is not covered at all, I think it's > >> good > >> >>> to start with Hibernate Spatial right after I'm done with the SQL > >> native > >> >>> one. > >> >>> > > > >> >>> > > What do you think of this? > >> >>> > > > >> >>> > > Vlad > >> >>> > > > >> >>> > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen < > karel at geovise.com> > >> >>> wrote: > >> >>> > > HI all, > >> >>> > > > >> >>> > > First, there seems to be a problem with the hibernate-spatial > >> mailing > >> >>> list that I was unaware of. The user in question reached out to me > >> >>> yesterday. I will investigate shortly. > >> >>> > > > >> >>> > > Fair point about the website not mentioning the move to > Hibernate > >> 5. > >> >>> I will put up a message for this on the site. > >> >>> > > > >> >>> > > For the near future what I?m hoping for is that first, we can > have > >> >>> the hibernate spatial tutorial updated to version 5, and integrated > >> into > >> >>> the Hibernate User Guide. After that I can have the > >> hibernatespatial.org > >> >>> URL?s redirect to that chapter. To support users of the older > >> versions (3.x > >> >>> and 4.x), we should also make sure that users can download older > >> versions > >> >>> of hibernate-spatial jars, and can consult older versions of the > >> spatial > >> >>> tutorial from the hibernate.org website. > >> >>> > > > >> >>> > > As for the mailing lists, I plan on announcing shortly that they > >> will > >> >>> be discontinued by end of year, and that questions should be asked > on > >> the > >> >>> usual hibernate channels. Btw, how can I be notified about questions > >> about > >> >>> Spatial on the hibernate forums? > >> >>> > > > >> >>> > > Vlad, have you some idea about time frame for starting on the > >> >>> Hibernate Spatial chapter? > >> >>> > > > >> >>> > > Regards, > >> >>> > > > >> >>> > > Karel > >> >>> > > > >> >>> > > > >> >>> > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea < > >> mihalcea.vlad at gmail.com> > >> >>> wrote: > >> >>> > > > > >> >>> > > > I also plan on writing a Hibernate Spatial Chapter in the new > >> User > >> >>> Guide so > >> >>> > > > we can complete the migration. > >> >>> > > > But first, I need to finish the remaining chapters from the > >> current > >> >>> User > >> >>> > > > Guide. > >> >>> > > > > >> >>> > > > Vlad > >> >>> > > > > >> >>> > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto < > >> >>> daltodavide at gmail.com> > >> >>> > > > wrote: > >> >>> > > > > >> >>> > > >> The user registered to the hibernate-spatial mailing list but > >> none > >> >>> of his > >> >>> > > >> messages > >> >>> > > >> appeared in the archive. > >> >>> > > >> > >> >>> > > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole < > >> >>> steve at hibernate.org> > >> >>> > > >> wrote: > >> >>> > > >> > >> >>> > > >>> Karel, a user was asking about problems using the > >> >>> hibernate-spatial > >> >>> > > >> mailing > >> >>> > > >>> list on IRC which precipitated a discussion about how we > want > >> >>> deal with > >> >>> > > >>> these things moving forward. For example, the > >> >>> > > >>> http://www.hibernatespatial.org/ site is still up and > running > >> >>> and really > >> >>> > > >>> has no indication that the move to integrate Spatial into > >> >>> Hibernate > >> >>> > > >> proper > >> >>> > > >>> was completed. What do you want to have happen with that > >> >>> website/URL? > >> >>> > > >>> > >> >>> > > >>> As for other infrastructure, what would you like to have > >> happen? > >> >>> It > >> >>> > > >> seems > >> >>> > > >>> like hibernate-spatial is a more user-focused mailing list, > as > >> >>> opposed > >> >>> > > >> to a > >> >>> > > >>> dev mailing list? If so, Hibernate does not really do user > >> >>> mailing > >> >>> > > >> lists. > >> >>> > > >>> We prefer the forums or StackOverflow for user questions, so > >> >>> there is > >> >>> > > >> not a > >> >>> > > >>> straight "migration". You can obviously keep the > >> >>> hibernate-spatial > >> >>> > > >> mailing > >> >>> > > >>> list running too, but we should have some idea how to help > >> users > >> >>> who are > >> >>> > > >>> having trouble with it on the website (which website depends > >> on > >> >>> what you > >> >>> > > >>> decide to do with http://www.hibernatespatial.org/. > >> >>> > > >>> > >> >>> > > >>> Any other things we should discuss in terms of > infrastructure? > >> >>> > > >>> > >> >>> > > >>> Davide, what was the exact problem the user on IRC was > >> >>> complaining about > >> >>> > > >>> wrt the hibernate-spatial mailing list? > >> >>> > > >>> _______________________________________________ > >> >>> > > >>> 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 Mon Apr 18 13:08:06 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 18 Apr 2016 18:08:06 +0100 Subject: [hibernate-dev] [HSEARCH] Scope of the first version with ES support In-Reply-To: References: Message-ID: Hi, thanks for starting this discussion: agreed on the need to release something soon! One word of caution though: it looks like media are picking up on this work with interest so I expect a good amount of people to try the first "preview" out; yet the expectations will probably be higher than usual. +1 to identify a MVP and to make it very clear what's not done yet, as we know that people won't easily forgive and some will not give us a second chance with a 5.7. Your list looks good; [BTW I thought that HSEARCH-2092 was very easy?]. You're all very welcome to mark things "blocker" when the user experience is not good, for example I just raised Emmanuel's feedback HSEARCH-2213 to blocker. After Beta1 we'll start to explicitly mark issues for 5.7, unless you feel the need to mark some already? I'd rather mark some as lower priority, and we all keep in mind that if you have time you should pick a higher-priority task, I just don't feel like moving low-hanging fruits out yet if there's a chance to implement some of these as well. Speaking of Beta1 .. I hope soon (10 days?) but that will have to wait on feature completeness of our list, we can do time-boxing for the next milestone but I think the major ones need to be all done, so no timeboxing for the specific Beta1, CR and Final. +1 for a quick CR & Final after Beta phase.. as you say, people don't really provide much feedback until it's "final tech preview" ;) Thanks, Sanne On 13 April 2016 at 14:54, Gunnar Morling wrote: > Hey, > > I'd like to achieve clarity and agreement on the scope of HSEARCH 5.6, the > first release with support for the Elasticsearch indexing backend. > > I suggest we limit ourselves to the essential things making the backend > actually usable and release it as a "technology preview" as of 5.6.0.Final. > Everything not needed for that goal I'd move to subsequent releases (5.7, > 6.0), the motivation being that we should not kill the vibe and deliver > something real soon. > > Some candidates for moving over I see: > > * "Define analyzers via the REST API (HSEARCH-2219 > )": Users can create > the needed analyzers themselves > * "Consider using the fields feature of Elasticsearch for properties mapped > on several fields" (HSEARCH-2215 > ): Seems scheduled as > a "reminder" only anways? > * "Use the Elasticsearch Scroll API when fetching large result sets" ( > HSEARCH-2128 ): Seems > not strictly needed > * "Map the optimize() operation to Elasticsearch 'force merge' requests" ( > HSEARCH-2092 ): Manual > requests possible as a work-around > * Likely some others > > Things we *should* do are most mapping-related issues, documentation and > apparent perf issues (massing indexing, avoid too frequent refreshing). > > The public interest in the subject seemed good, so I'd prefer if we can > ship a "Final" version soon in MVP-style. As it seems, a "final" tech > preview is less scary to people than an Alpha/Beta. Let's hone the bits it > in subsequent releases, rather than working on the first Final for a long > time. > > Any thoughts? > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gbadner at redhat.com Mon Apr 18 13:38:01 2016 From: gbadner at redhat.com (Gail Badner) Date: Mon, 18 Apr 2016 10:38:01 -0700 Subject: [hibernate-dev] To require or not to require a JIRA for a small-typo kind of commit In-Reply-To: References: Message-ID: I have no problem if you want to do this for non-ORM; however, I've seen bugs get introduced by "clean up" commits in ORM. Fixing these regressions are easier to find and track if there is a "clean up" jira. On Mon, Apr 18, 2016 at 5:54 AM, Vlad Mihalcea wrote: > +1 > > Vlad > > On Mon, Apr 18, 2016 at 3:48 PM, Guillaume Smet > wrote: > > > OK for me too. That's what I was told when I asked the question a while > ago > > :). > > > > On Mon, Apr 18, 2016 at 2:15 PM, Sanne Grinovero > > wrote: > > > > > This question came up again on github; seems Gunnar, Davide and myself > > > would agree on preferring a little more flexibility on the no-orm > > > projects than ORM's guidelines: > > > > > > - > > > > > > https://github.com/hibernate/hibernate-search/pull/1064#issuecomment-211320931 > > > > > > > > > This flexibility would be a perk for regular contributors only so I > > > don't feel a need to move our conclusions to a formal document, yet > > > I'm bringing it up here so you can all see it, and voice concerns / > > > approval now :) > > > > > > 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 > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Apr 18 13:50:59 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 18 Apr 2016 17:50:59 +0000 Subject: [hibernate-dev] To require or not to require a JIRA for a small-typo kind of commit In-Reply-To: References: Message-ID: I tend to agree with Gail in regards to ORM. Even if it is just fixing a small typo, just use the original Jira key that introduced the typo IMO On Mon, Apr 18, 2016 at 12:38 PM Gail Badner wrote: > I have no problem if you want to do this for non-ORM; however, I've seen > bugs get introduced by "clean up" commits in ORM. Fixing these regressions > are easier to find and track if there is a "clean up" jira. > > On Mon, Apr 18, 2016 at 5:54 AM, Vlad Mihalcea > wrote: > > > +1 > > > > Vlad > > > > On Mon, Apr 18, 2016 at 3:48 PM, Guillaume Smet < > guillaume.smet at gmail.com> > > wrote: > > > > > OK for me too. That's what I was told when I asked the question a while > > ago > > > :). > > > > > > On Mon, Apr 18, 2016 at 2:15 PM, Sanne Grinovero > > > wrote: > > > > > > > This question came up again on github; seems Gunnar, Davide and > myself > > > > would agree on preferring a little more flexibility on the no-orm > > > > projects than ORM's guidelines: > > > > > > > > - > > > > > > > > > > https://github.com/hibernate/hibernate-search/pull/1064#issuecomment-211320931 > > > > > > > > > > > > This flexibility would be a perk for regular contributors only so I > > > > don't feel a need to move our conclusions to a formal document, yet > > > > I'm bringing it up here so you can all see it, and voice concerns / > > > > approval now :) > > > > > > > > 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 > > > > > _______________________________________________ > > 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 brett at hibernate.org Mon Apr 18 14:02:35 2016 From: brett at hibernate.org (Brett Meyer) Date: Mon, 18 Apr 2016 14:02:35 -0400 Subject: [hibernate-dev] Regarding new Dialects In-Reply-To: References: Message-ID: <5715213B.6070800@hibernate.org> Hey Vlad, our approach had been to accept new Dialects only if: 1. Someone or some entity is willing to develop it 2. Someone or some entity is willing to maintain it *long term* 3. The community demands it (either through the ML, JIRA votes, noise on the forums or externally, etc.) Too often, Dialects are created and abandoned. Even worse, a Dialect in ORM is used as an advertisement of sorts for the DB vendor. If they want to create the Dialect, fantastic. But unless #2 and #3 are true, we typically ask that they release the Dialect on their own, outside of the core ORM project. So, the next step would be to create a JIRA, gauge the community need, and start a discussion with Altibase to find out if this is a long term commitment for them... On 04/14/2016 04:00 AM, Vlad Mihalcea wrote: > Hi, > > We have another Dialect coming as a pull request: > > https://github.com/hibernate/hibernate-orm/pull/1330 > > In my opinion, we should integrate new Dialects and just document which > ones are maintained by us, and which ones are under development by other > parties. > For the Altibase database, the Dialect was sent by an Altibase employee, so > it is their interest to maintain it as well. > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From davide at hibernate.org Wed Apr 20 13:21:30 2016 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 20 Apr 2016 18:21:30 +0100 Subject: [hibernate-dev] HipChat integrations Message-ID: Hi, I've enabled the preview of the JIRA issue when there is a JIRA ID in the chat, let me know if it causes some problems. There are also some other addons that might be helpful and I would like to add if there are no objections: Standup: https://hibernate.hipchat.com/addons/hc-standup?room=-1 Google hangout: https://hibernate.hipchat.com/addons/com.atlassian.hipchat.hangouts?room=2237794 Guest history: https://hibernate.hipchat.com/addons/hipchat-guest-history?room=-1 Pingmonit (might be useful to monitor hibernate.org, in relation.to, and ci.hibernate.org): https://hibernate.hipchat.com/addons/com.pingmonit.addons.hipchat?room=2237794 If you guys disagree or have previous experience with these addons, let me know. I haven't tested them yet. Cheers, Davide From davide at hibernate.org Wed Apr 20 13:25:42 2016 From: davide at hibernate.org (Davide D'Alto) Date: Wed, 20 Apr 2016 18:25:42 +0100 Subject: [hibernate-dev] HipChat integrations In-Reply-To: References: Message-ID: This one might be nice as well: Hipchat to issue: https://marketplace.atlassian.com/plugins/com.keplerrominfo.plugins.hipchat.hipchatissue/cloud/overview On Wed, Apr 20, 2016 at 6:21 PM, Davide D'Alto wrote: > Hi, > I've enabled the preview of the JIRA issue when there is a JIRA ID in the > chat, let me know if it causes some problems. > > There are also some other addons that might be helpful and I would like to > add if there are no objections: > > Standup: > https://hibernate.hipchat.com/addons/hc-standup?room=-1 > > Google hangout: > > https://hibernate.hipchat.com/addons/com.atlassian.hipchat.hangouts?room=2237794 > > Guest history: > https://hibernate.hipchat.com/addons/hipchat-guest-history?room=-1 > > Pingmonit (might be useful to monitor hibernate.org, in relation.to, and > ci.hibernate.org): > > https://hibernate.hipchat.com/addons/com.pingmonit.addons.hipchat?room=2237794 > > If you guys disagree or have previous experience with these addons, let me > know. > > I haven't tested them yet. > > Cheers, > Davide > From guillaume.smet at gmail.com Wed Apr 20 13:44:41 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Wed, 20 Apr 2016 19:44:41 +0200 Subject: [hibernate-dev] HipChat integrations In-Reply-To: References: Message-ID: Hi Davide, On Wed, Apr 20, 2016 at 7:21 PM, Davide D'Alto wrote: > Standup: > https://hibernate.hipchat.com/addons/hc-standup?room=-1 +1 > Google hangout: > > https://hibernate.hipchat.com/addons/com.atlassian.hipchat.hangouts?room=2237794 +1 , would be very useful > Guest history: > https://hibernate.hipchat.com/addons/hipchat-guest-history?room=-1 +1 > Pingmonit (might be useful to monitor hibernate.org, in relation.to, and > ci.hibernate.org): > > https://hibernate.hipchat.com/addons/com.pingmonit.addons.hipchat?room=2237794 +1 if it doesn't generate too much false positives. > Hipchat to issue: > https://marketplace.atlassian.com/plugins/com.keplerrominfo.plugins.hipchat.hipchatissue/cloud/overview Hmmm, not sure it's a good idea. It might integrate some noise in the issues if people are discussing different subjects. -- Guillaume From sanne at hibernate.org Wed Apr 20 16:21:56 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 20 Apr 2016 21:21:56 +0100 Subject: [hibernate-dev] HSEARCH: Coexisting of Lucene and Elasticsearch backends vs polymorphism & co Message-ID: In the context of implementing Elasticsearch support for Hibernate Search, there's a recurring need to transform the domain model to the "Document" representation using a strategy which depends on the storage choice, i.e. Lucene vs Elasticsearch. For example Guillaume working on HSEARCH-2067 needs to associate the entities document builder with a FieldBridge choice which needs to know if the output document will be indexed in ES, rather than Lucene. The choice of FieldBridge implementation affects the DocumentBuilder bound to each type; this implies that we're "tainting" the DocumentBuilder for all instance of a type. The abstraction of "IndexManager" is meant to initialize and manage an *index* - but remember that there's no guarantee that a single type is bound to a single index (and so to a single IndexManager). - We have the case of a single type being spread out on multiple indexes, using Sharding. - We also have the opposite, of multiple different types sharing and index - Subtypes of indexed types can opt to be indexed in a different type - All of two above can be mixed freely, as there's a clear distinction between type (identified by a Class) and index (identified by a String) [I'm not stating that the above facts are necessarily all required, just that they are currently supported.. so we could in theory discuss taking away some of this flexibility now, but implementing such restrictions would need to wait for version 6.0.] When a Query is run on a type A, we're transparently running the query on all indexes of shards containing A, and also its indexed subtypes on different indexes. We're also filtering out incompatible types transparently, if any of these sub-indexes are shared with other types. We also allow running a FullTextQuery on multiple, unrelated types and the same rules apply. To perform such a Query on multiple indexes, the trick currently used with Lucene based backends is the usage of MultiReaders: we wrap multiple indexes and present them as one index reader to the query engine, it's a "unified view" on which the query is performed. For obvious reasons we can not wrap a MultiReader across both Lucene indexes and Elasticsearch's query capabilities (or maybe we could eventually, but that's a whole lot of R&D to be done for questionable usefulness). So, we need to introduce a new concept: something like "index families" to properly abstract the boundaries as clearly some indexes can work together better within the same kind than with indexes of other kind. Stuff indexed in Lucene embedded would belong to a family A, stuff in the Elasticsearch cluster would be family B, and I guess one might have a secondary independent Elasticsearch cluster which would need to be in a different family C, or eventually a Solr cluster in yet another separated family. Such an "index family" would give us: - a place were the connection settings, connections pools are handled for Elasticsearch - clear boundaries about which types can be queried "as one": only the types in the same family, and subtypes might be allowed a different index but it must live in the same family. Same for Sharding. - a reasonable place to query for which "kind of storage" is being used for a specific type - An Analyzer might exist only within a family (Defined on one ES cluster, not on the other) - We have a long standing issue with Similarity: you can only have one in a group of indexes, but the group concept is undefined (and only loosely validatable) - And "index family" could have a type, therefore define what kind of FieldBridge(s) need to be generated I'm not saying that this is all blocking for 5.6. My proposal is to see if we agree on such a design as a longer term objective (set some foundation in 5.7, finalize for 6). For 5.6 I'd be happy enough to essentially document that there's only one family allowed, which allows us to cut some corners like: - single set of Analyzers to validate - know that the Search instance is fully using ES exclusively, or Lucene exclusively - know that all IndexManagers are connected to the same set of ES nodes (if using ES) So not much changing.. just hope this helps in shaping our internals with an eye on the next step, and make sure that the listed limitations which we've been accepting already can be clearly documented. It would be great to already have the basics for index families in place, for example to define the proper API to read metadata for a type (like Guillaume is needing), and to cleanup some things, such as make the Similarity definition clearly associated to such a thing. Naming: index family ? index groups? Not sure if there's need to add anything to the configuration properties; for now it could simply reflect our interpretation of the existing configuration, yet expose useful and clean metadata to the internal components which need this. Thanks for any comments! Sanne From gunnar at hibernate.org Thu Apr 21 03:09:19 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 21 Apr 2016 09:09:19 +0200 Subject: [hibernate-dev] HSEARCH: Coexisting of Lucene and Elasticsearch backends vs polymorphism & co In-Reply-To: References: Message-ID: Hey, +1 for the concept of index families in the long run. As you say, I don't think there is an immediate need for action as of 5.6. When you say > know that the Search instance is fully using ES exclusively, or > Lucene exclusively do you mean "Hibernate Search" instance, or just a specific query? It's possible to use Lucene and ES for different entities already if you know the limitations. E.g. no queries crossing the family border, no sharding crossing the family border (which seems questionable anyways, so I think we could disallow that to begin with). How about this: Let's bring support for multiple ES clusters into 5.7, which should allow us to lay the grounds for "index families" as we'll learn what needs to be done for different settings per cluster etc. --Gunnar 2016-04-20 22:21 GMT+02:00 Sanne Grinovero : > In the context of implementing Elasticsearch support for Hibernate > Search, there's a recurring need to transform the domain model to the > "Document" representation using a strategy which depends on the > storage choice, i.e. Lucene vs Elasticsearch. > > For example Guillaume working on HSEARCH-2067 needs to associate the > entities document builder with a FieldBridge choice which needs to > know if the output document will be indexed in ES, rather than Lucene. > > The choice of FieldBridge implementation affects the DocumentBuilder > bound to each type; this implies that we're "tainting" the > DocumentBuilder for all instance of a type. > > The abstraction of "IndexManager" is meant to initialize and manage an > *index* - but remember that there's no guarantee that a single type is > bound to a single index (and so to a single IndexManager). > > - We have the case of a single type being spread out on multiple > indexes, using Sharding. > - We also have the opposite, of multiple different types sharing and index > - Subtypes of indexed types can opt to be indexed in a different type > - All of two above can be mixed freely, as there's a clear > distinction between type (identified by a Class) and index (identified > by a String) > > [I'm not stating that the above facts are necessarily all required, > just that they are currently supported.. so we could in theory discuss > taking away some of this flexibility now, but implementing such > restrictions would need to wait for version 6.0.] > > When a Query is run on a type A, we're transparently running the query > on all indexes of shards containing A, and also its indexed subtypes > on different indexes. We're also filtering out incompatible types > transparently, if any of these sub-indexes are shared with other > types. > We also allow running a FullTextQuery on multiple, unrelated types and > the same rules apply. > > To perform such a Query on multiple indexes, the trick currently used > with Lucene based backends is the usage of MultiReaders: we wrap > multiple indexes and present them as one index reader to the query > engine, it's a "unified view" on which the query is performed. > > For obvious reasons we can not wrap a MultiReader across both Lucene > indexes and Elasticsearch's query capabilities (or maybe we could > eventually, but that's a whole lot of R&D to be done for questionable > usefulness). > > So, we need to introduce a new concept: something like "index > families" to properly abstract the boundaries as clearly some indexes > can work together better within the same kind than with indexes of > other kind. > Stuff indexed in Lucene embedded would belong to a family A, stuff in > the Elasticsearch cluster would be family B, and I guess one might > have a secondary independent Elasticsearch cluster which would need to > be in a different family C, or eventually a Solr cluster in yet > another separated family. > > Such an "index family" would give us: > - a place were the connection settings, connections pools are handled > for Elasticsearch > - clear boundaries about which types can be queried "as one": only > the types in the same family, and subtypes might be allowed a > different index but it must live in the same family. Same for > Sharding. > - a reasonable place to query for which "kind of storage" is being > used for a specific type > - An Analyzer might exist only within a family (Defined on one ES > cluster, not on the other) > - We have a long standing issue with Similarity: you can only have > one in a group of indexes, but the group concept is undefined (and > only loosely validatable) > - And "index family" could have a type, therefore define what kind of > FieldBridge(s) need to be generated > > I'm not saying that this is all blocking for 5.6. My proposal is to > see if we agree on such a design as a longer term objective (set some > foundation in 5.7, finalize for 6). > > For 5.6 I'd be happy enough to essentially document that there's only > one family allowed, which allows us to cut some corners like: > - single set of Analyzers to validate > - know that the Search instance is fully using ES exclusively, or > Lucene exclusively > - know that all IndexManagers are connected to the same set of ES > nodes (if using ES) > > So not much changing.. just hope this helps in shaping our internals > with an eye on the next step, and make sure that the listed > limitations which we've been accepting already can be clearly > documented. > > It would be great to already have the basics for index families in > place, for example to define the proper API to read metadata for a > type (like Guillaume is needing), and to cleanup some things, such as > make the Similarity definition clearly associated to such a thing. > > Naming: index family ? index groups? > Not sure if there's need to add anything to the configuration > properties; for now it could simply reflect our interpretation of the > existing configuration, yet expose useful and clean metadata to the > internal components which need this. > > Thanks for any comments! > > 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 Apr 21 07:04:24 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 21 Apr 2016 13:04:24 +0200 Subject: [hibernate-dev] HSEARCH: Coexisting of Lucene and Elasticsearch backends vs polymorphism & co In-Reply-To: References: Message-ID: On 21 April 2016 at 09:09, Gunnar Morling wrote: > Hey, > > +1 for the concept of index families in the long run. As you say, I don't > think there is an immediate need for action as of 5.6. Cool. Right, no immediate changes but it should allow us to better understand which kind of limitations we aim at "by design", and to clearly express them in docs. I do expect it to set drive some of the new SPIs though, e.g. - https://github.com/hibernate/hibernate-search/pull/1068#issuecomment-212591419 > > When you say > >> know that the Search instance is fully using ES exclusively, or >> Lucene exclusively > > do you mean "Hibernate Search" instance, or just a specific query? It's > possible to use Lucene and ES for different entities already if you know the > limitations. E.g. no queries crossing the family border, no sharding > crossing the family border (which seems questionable anyways, so I think we > could disallow that to begin with). I meant the whole instance. We took some shortcuts, like the DateBridge being affected (even though Guillaume solved it), but also e.g. for Analyzer validation. These limitations will get relaxed while we work, but will never be able to "cross families": in terms of defining a MVP for 5.6 I think we can aim at one type. > > How about this: Let's bring support for multiple ES clusters into 5.7, which > should allow us to lay the grounds for "index families" as we'll learn what > needs to be done for different settings per cluster etc. Exactly. But also I'd move the option of Lucene embedded + ES to 5.7. Not to say that we shouldn't explore these, just not considering them blockers. Thanks, Sanne > > --Gunnar > > > 2016-04-20 22:21 GMT+02:00 Sanne Grinovero : >> >> In the context of implementing Elasticsearch support for Hibernate >> Search, there's a recurring need to transform the domain model to the >> "Document" representation using a strategy which depends on the >> storage choice, i.e. Lucene vs Elasticsearch. >> >> For example Guillaume working on HSEARCH-2067 needs to associate the >> entities document builder with a FieldBridge choice which needs to >> know if the output document will be indexed in ES, rather than Lucene. >> >> The choice of FieldBridge implementation affects the DocumentBuilder >> bound to each type; this implies that we're "tainting" the >> DocumentBuilder for all instance of a type. >> >> The abstraction of "IndexManager" is meant to initialize and manage an >> *index* - but remember that there's no guarantee that a single type is >> bound to a single index (and so to a single IndexManager). >> >> - We have the case of a single type being spread out on multiple >> indexes, using Sharding. >> - We also have the opposite, of multiple different types sharing and >> index >> - Subtypes of indexed types can opt to be indexed in a different type >> - All of two above can be mixed freely, as there's a clear >> distinction between type (identified by a Class) and index (identified >> by a String) >> >> [I'm not stating that the above facts are necessarily all required, >> just that they are currently supported.. so we could in theory discuss >> taking away some of this flexibility now, but implementing such >> restrictions would need to wait for version 6.0.] >> >> When a Query is run on a type A, we're transparently running the query >> on all indexes of shards containing A, and also its indexed subtypes >> on different indexes. We're also filtering out incompatible types >> transparently, if any of these sub-indexes are shared with other >> types. >> We also allow running a FullTextQuery on multiple, unrelated types and >> the same rules apply. >> >> To perform such a Query on multiple indexes, the trick currently used >> with Lucene based backends is the usage of MultiReaders: we wrap >> multiple indexes and present them as one index reader to the query >> engine, it's a "unified view" on which the query is performed. >> >> For obvious reasons we can not wrap a MultiReader across both Lucene >> indexes and Elasticsearch's query capabilities (or maybe we could >> eventually, but that's a whole lot of R&D to be done for questionable >> usefulness). >> >> So, we need to introduce a new concept: something like "index >> families" to properly abstract the boundaries as clearly some indexes >> can work together better within the same kind than with indexes of >> other kind. >> Stuff indexed in Lucene embedded would belong to a family A, stuff in >> the Elasticsearch cluster would be family B, and I guess one might >> have a secondary independent Elasticsearch cluster which would need to >> be in a different family C, or eventually a Solr cluster in yet >> another separated family. >> >> Such an "index family" would give us: >> - a place were the connection settings, connections pools are handled >> for Elasticsearch >> - clear boundaries about which types can be queried "as one": only >> the types in the same family, and subtypes might be allowed a >> different index but it must live in the same family. Same for >> Sharding. >> - a reasonable place to query for which "kind of storage" is being >> used for a specific type >> - An Analyzer might exist only within a family (Defined on one ES >> cluster, not on the other) >> - We have a long standing issue with Similarity: you can only have >> one in a group of indexes, but the group concept is undefined (and >> only loosely validatable) >> - And "index family" could have a type, therefore define what kind of >> FieldBridge(s) need to be generated >> >> I'm not saying that this is all blocking for 5.6. My proposal is to >> see if we agree on such a design as a longer term objective (set some >> foundation in 5.7, finalize for 6). >> >> For 5.6 I'd be happy enough to essentially document that there's only >> one family allowed, which allows us to cut some corners like: >> - single set of Analyzers to validate >> - know that the Search instance is fully using ES exclusively, or >> Lucene exclusively >> - know that all IndexManagers are connected to the same set of ES >> nodes (if using ES) >> >> So not much changing.. just hope this helps in shaping our internals >> with an eye on the next step, and make sure that the listed >> limitations which we've been accepting already can be clearly >> documented. >> >> It would be great to already have the basics for index families in >> place, for example to define the proper API to read metadata for a >> type (like Guillaume is needing), and to cleanup some things, such as >> make the Similarity definition clearly associated to such a thing. >> >> Naming: index family ? index groups? >> Not sure if there's need to add anything to the configuration >> properties; for now it could simply reflect our interpretation of the >> existing configuration, yet expose useful and clean metadata to the >> internal components which need this. >> >> Thanks for any comments! >> >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From smarlow at redhat.com Thu Apr 21 09:59:25 2016 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 21 Apr 2016 09:59:25 -0400 Subject: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module? In-Reply-To: References: Message-ID: <5718DCBD.3050003@redhat.com> On 04/18/2016 11:32 AM, Sanne Grinovero wrote: > I think there was some confusion in this thread, probably it wasn't > clear that WildFly 10 already does inject automatically OGM, and that > ship sailed so we have to keep in mind what Jipijapa is going to do by > default: > > The current state in WildFly 10's deployers is very simple: if it > "sees" that the persistence.xml is defining a Persistence Provider > named "org.hibernate.ogm.jpa.HibernateOgmPersistence", then it will > look for a module named "org.hibernate.ogm" and inject this to the > classpath. That does imply slot "main" is expected to be available. > This logic can be overriden, but it requires the user to specify - and > know about - additional configuration properties. If the slot is not "main", the application will use "jboss.as.jpa.providerModule" to specify the corrected module name. If users need a "jboss.as.jpa.providerModuleSlot" option, that could be added. > > We can try deciding what we want WildFly 11+ to do better in the > future, but we need to decide at high priority what approach to use > for OGM 5.0.0.Final, given the WildFly-was-released restriction. Is there going to be one static OGM module for all targeted backends? Will the one static OGM module have its own ORM jars or depend on the ORM jars that WildFly packages? From our previous discussion, there are some OGM dependencies expected to leak into the application as well (perhaps via a Jipijapa extension, if we need a OGM integration layer in WildFly). > > Now to reiterate the problem I mentioned in the first email of this > thread: having just the right version of "org.hibernate.ogm" isn't > good enough as one needs the specific dialect modules too. > I asked (teasing) if you all could see the specific dialect options as > power-user extensions, but it seems the consensus is that these are > not really optional. > > So I guess I agree with Gunnar and Davide: [in current WildFly] one > will need to use the jboss-deployment-structure.xml or the Manifest to > make use of OGM, and we'll have to ignore the fact that when one of > these is missing the WildFly deployer will get mad as OGM:main can't > be found. > > More inline: > > On 31 March 2016 at 11:48, Gunnar Morling wrote: >> So I think for the time being I'd be fine if WF didn't add anything >> implicitly at all for OGM. > > Too late, hope that's clear now. > >> The reason being, that OGM is not (yet) part of WF, the user needs to put in >> the modules from the ZIP themselves. So it seems acceptable to me to add the >> dependencies to the required modules by hand (matching the slot of the >> modules they unzipped). > > Yes, acceptable for the time being, but for a future version of WF it > would be nice to not have users create (and learn about) yet another > configuration file. > >> Should WF do it automatically, some logic along these lines would be needed: >> >> * If OGM is the persistence provider and there is only one set of OGM >> modules available, add all the OGM modules actually present (e.g. the user >> could have unzipped only core and one of the backends); Optionally, only add >> those backend(s) actually in use as per the configuration >> * If more than one set of OGM modules is available, require the user to >> explicitly specify the slot >> >> How about doing this once OGM actually is part of WF? Then one could default >> to the provided version, requiring the override only if the user wishes to >> use (and provides) another version. > > +1 but to eventually allow WF to pick a specific OGM slot, we should > first release versioned modules. > > I initially thought that we could provide an alias module "main -> > current release" to have the jipijapa integration work in certain > circumstances, but realising that the dialect-specific modules are > needed too, I guess this would be pointless. > > So my plan is to simply switch our released modules to a specific > slot, then update the documentation accordingly. Not sure how far > jipijapa will try to stop me :) we might need additional JPA > properties too to override it. > > Thanks, > Sanne > > > >> >> --Gunnar >> >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From sanne at hibernate.org Thu Apr 21 10:20:18 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 21 Apr 2016 16:20:18 +0200 Subject: [hibernate-dev] [HSEARCH] Scope of the first version with ES support In-Reply-To: References: Message-ID: I flushed 52 issues out which were clogging our pipeline. 25 open issues to go for a 5.6.0.Beta1; these more important ones are flagged "fixVersion" = 5.6. The ones I moved are now marked for 5.6.0.Beta2; they might eventually end up being moved to 5.7 but we can review that later. So please focus on the ones marked for "5.6" first. This doesn't mean that the ones I've moved out are not important and should not be looked at: some of them are annoying bugs, but I simply don't consider them blockers for the first beta supporting Elasticsearch as we had them in the past too.. if you happen to want to fix one, we can of course change the fixVersion back. Thanks, Sanne On 18 April 2016 at 19:08, Sanne Grinovero wrote: > Hi, > thanks for starting this discussion: agreed on the need to release > something soon! > > One word of caution though: it looks like media are picking up on this > work with interest so I expect a good amount of people to try the > first "preview" out; yet the expectations will probably be higher than > usual. > > +1 to identify a MVP and to make it very clear what's not done yet, as > we know that people won't easily forgive and some will not give us a > second chance with a 5.7. > > Your list looks good; [BTW I thought that HSEARCH-2092 was very easy?]. > > You're all very welcome to mark things "blocker" when the user > experience is not good, for example I just raised Emmanuel's feedback > HSEARCH-2213 to blocker. > > After Beta1 we'll start to explicitly mark issues for 5.7, unless you > feel the need to mark some already? I'd rather mark some as lower > priority, and we all keep in mind that if you have time you should > pick a higher-priority task, I just don't feel like moving low-hanging > fruits out yet if there's a chance to implement some of these as well. > > Speaking of Beta1 .. I hope soon (10 days?) but that will have to wait > on feature completeness of our list, we can do time-boxing for the > next milestone but I think the major ones need to be all done, so no > timeboxing for the specific Beta1, CR and Final. > > +1 for a quick CR & Final after Beta phase.. as you say, people don't > really provide much feedback until it's "final tech preview" ;) > > Thanks, > Sanne > > > > > On 13 April 2016 at 14:54, Gunnar Morling wrote: >> Hey, >> >> I'd like to achieve clarity and agreement on the scope of HSEARCH 5.6, the >> first release with support for the Elasticsearch indexing backend. >> >> I suggest we limit ourselves to the essential things making the backend >> actually usable and release it as a "technology preview" as of 5.6.0.Final. >> Everything not needed for that goal I'd move to subsequent releases (5.7, >> 6.0), the motivation being that we should not kill the vibe and deliver >> something real soon. >> >> Some candidates for moving over I see: >> >> * "Define analyzers via the REST API (HSEARCH-2219 >> )": Users can create >> the needed analyzers themselves >> * "Consider using the fields feature of Elasticsearch for properties mapped >> on several fields" (HSEARCH-2215 >> ): Seems scheduled as >> a "reminder" only anways? >> * "Use the Elasticsearch Scroll API when fetching large result sets" ( >> HSEARCH-2128 ): Seems >> not strictly needed >> * "Map the optimize() operation to Elasticsearch 'force merge' requests" ( >> HSEARCH-2092 ): Manual >> requests possible as a work-around >> * Likely some others >> >> Things we *should* do are most mapping-related issues, documentation and >> apparent perf issues (massing indexing, avoid too frequent refreshing). >> >> The public interest in the subject seemed good, so I'd prefer if we can >> ship a "Final" version soon in MVP-style. As it seems, a "final" tech >> preview is less scary to people than an Alpha/Beta. Let's hone the bits it >> in subsequent releases, rather than working on the first Final for a long >> time. >> >> Any thoughts? >> >> --Gunnar >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Thu Apr 21 13:35:47 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 21 Apr 2016 19:35:47 +0200 Subject: [hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider Message-ID: Hi, As IndexShardingStrategy is deprecated, I thought I'd use ShardIdentifierProvider and friends in new code I write. It's not clear to me though, how it's meant to be used. Some questions: * Is it correct that EntityIndexBinding#getShardIdentifierProvider() returns null is sharding is not used for this entity? I suppose in that case I simply can use EntityIndexBinding.getIndexManagers()[0]? * What's the envisioned way to get the IM for a given shard once I know the shard id? I found IndexManagerHolder.getOrCreateIndexManager(), but this expects a *DynamicSharding*EntityIndexBinding, so how would it work for non-dynamic sharding? It's tough to see how the pieces are meant to fit together, now that IndexShardingStrategy and ShardIdentifierProvider are there. I hope we can get rid of the former soon, simplifying the code a bit? Thanks, --Gunnar From steve at hibernate.org Thu Apr 21 13:36:07 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 21 Apr 2016 17:36:07 +0000 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link Message-ID: I have started maintaining[1] the ORM Roadmap external to hibernate.org itself. I'd like to adjust the link to when under orm/ to point to this external URL rather than the parameterized {project}/roadmap target. Is that possible? And if so, how? [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap From steve at hibernate.org Thu Apr 21 13:38:12 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 21 Apr 2016 17:38:12 +0000 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Chris just point out that the roadmap target URL is part of the site config. So I can just update that for ORM. Disregard :) On Thu, Apr 21, 2016 at 12:36 PM Steve Ebersole wrote: > I have started maintaining[1] the ORM Roadmap external to hibernate.org > itself. I'd like to adjust the link to when under orm/ to point to this > external URL rather than the parameterized {project}/roadmap target. Is > that possible? And if so, how? > > [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap > From gunnar at hibernate.org Thu Apr 21 13:42:11 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 21 Apr 2016 19:42:11 +0200 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Hey, What's the reason for maintaining the roadmap in the wiki rather than hibernate.org itself? I hoped we'd centralize this kind of information on hibernate.org; Looks a tad more professional to have everything with the same look & field rather than pointing to other resources as the wiki... Also searchability benefits, should we once have a site search. --Gunnar 2016-04-21 19:36 GMT+02:00 Steve Ebersole : > I have started maintaining[1] the ORM Roadmap external to hibernate.org > itself. I'd like to adjust the link to when under orm/ to point to this > external URL rather than the parameterized {project}/roadmap target. Is > that possible? And if so, how? > > [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Thu Apr 21 16:00:47 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 21 Apr 2016 20:00:47 +0000 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Because I find it incredibly easier to work with GitHub wiki as opposed to hibernate.org for authoring. On Thu, Apr 21, 2016, 12:42 PM Gunnar Morling wrote: > Hey, > > What's the reason for maintaining the roadmap in the wiki rather than > hibernate.org itself? > > I hoped we'd centralize this kind of information on hibernate.org; Looks > a tad more professional to have everything with the same look & field > rather than pointing to other resources as the wiki... Also searchability > benefits, should we once have a site search. > > --Gunnar > > > > 2016-04-21 19:36 GMT+02:00 Steve Ebersole : > >> I have started maintaining[1] the ORM Roadmap external to hibernate.org >> itself. I'd like to adjust the link to when under orm/ to point to this >> external URL rather than the parameterized {project}/roadmap target. Is >> that possible? And if so, how? >> >> [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From daltodavide at gmail.com Thu Apr 21 18:57:21 2016 From: daltodavide at gmail.com (Davide D'Alto) Date: Thu, 21 Apr 2016 23:57:21 +0100 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Hi Steve, what problems are you having with hibernate.org? I agree with Gunnar that we should try to stick with one look & feel if possible. On Thu, Apr 21, 2016 at 9:00 PM, Steve Ebersole wrote: > Because I find it incredibly easier to work with GitHub wiki as opposed to > hibernate.org for authoring. > > On Thu, Apr 21, 2016, 12:42 PM Gunnar Morling > wrote: > > > Hey, > > > > What's the reason for maintaining the roadmap in the wiki rather than > > hibernate.org itself? > > > > I hoped we'd centralize this kind of information on hibernate.org; Looks > > a tad more professional to have everything with the same look & field > > rather than pointing to other resources as the wiki... Also searchability > > benefits, should we once have a site search. > > > > --Gunnar > > > > > > > > 2016-04-21 19:36 GMT+02:00 Steve Ebersole : > > > >> I have started maintaining[1] the ORM Roadmap external to hibernate.org > >> itself. I'd like to adjust the link to when under orm/ to point to this > >> external URL rather than the parameterized {project}/roadmap target. Is > >> that possible? And if so, how? > >> > >> [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap > >> > > _______________________________________________ > >> 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 Fri Apr 22 06:30:21 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Apr 2016 11:30:21 +0100 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: There's a middle-ground strategy which might be cool to try. Go here: - https://github.com/hibernate/hibernate.org/edit/production/orm/roadmap.adoc edit the doc within the browser, confirm the changes with a brief commit message and CI should pick it up, then publish within 5 minutes. I just did this for the Search roadmap, although I opted for the 'staging' branch to try it out.. and because I regularly screw up the syntax. -- Sanne On 21 April 2016 at 23:57, Davide D'Alto wrote: > Hi Steve, > what problems are you having with hibernate.org? > I agree with Gunnar that we should try to stick with one look & feel if > possible. > > On Thu, Apr 21, 2016 at 9:00 PM, Steve Ebersole wrote: > >> Because I find it incredibly easier to work with GitHub wiki as opposed to >> hibernate.org for authoring. >> >> On Thu, Apr 21, 2016, 12:42 PM Gunnar Morling >> wrote: >> >> > Hey, >> > >> > What's the reason for maintaining the roadmap in the wiki rather than >> > hibernate.org itself? >> > >> > I hoped we'd centralize this kind of information on hibernate.org; Looks >> > a tad more professional to have everything with the same look & field >> > rather than pointing to other resources as the wiki... Also searchability >> > benefits, should we once have a site search. >> > >> > --Gunnar >> > >> > >> > >> > 2016-04-21 19:36 GMT+02:00 Steve Ebersole : >> > >> >> I have started maintaining[1] the ORM Roadmap external to hibernate.org >> >> itself. I'd like to adjust the link to when under orm/ to point to this >> >> external URL rather than the parameterized {project}/roadmap target. Is >> >> that possible? And if so, how? >> >> >> >> [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap >> >> >> > _______________________________________________ >> >> 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 Fri Apr 22 06:55:21 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Apr 2016 11:55:21 +0100 Subject: [hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider In-Reply-To: References: Message-ID: On 21 April 2016 at 18:35, Gunnar Morling wrote: > Hi, > > As IndexShardingStrategy is deprecated, I thought I'd use > ShardIdentifierProvider and friends in new code I write. It's not clear to > me though, how it's meant to be used. > > Some questions: > > * Is it correct that EntityIndexBinding#getShardIdentifierProvider() > returns null is sharding is not used for this entity? Yes, as the javadoc suggests. I don't like to return "null"s so if > I suppose in that > case I simply can use EntityIndexBinding.getIndexManagers()[0]? I'm not understanding how this related to the previous question. What are you up to? N.B. the intent of the sharding strategies is not to give end users a reference to the IndexManagers. So the `ShardIdentifierProvider` contract lets people identify the target indexes by naming them. > * What's the envisioned way to get the IM for a given shard once I know the > shard id? I found IndexManagerHolder.getOrCreateIndexManager(), but this > expects a *DynamicSharding*EntityIndexBinding, so how would it work for > non-dynamic sharding? The envisioned way is that the user doesn't get a reference to the IndexManager, what he needs is to identify the indexes - not act on them. > > It's tough to see how the pieces are meant to fit together, now that > IndexShardingStrategy and ShardIdentifierProvider are there. I hope we can > get rid of the former soon, simplifying the code a bit? Yes. It has been deprecated for long enough, we could give a shot of removing the old one if this helps something you're doing? I wouldn't remove it yet if it's not in the way of our 5.6 requirements. BTW the contract "IndexShardingStrategy" is deprecated so that users of sharding move to the new API, but that interface still is the foundation of the implementation even for dynamic sharding.. it's not being removed from internals. The new contract just enables us to add new shards dynamically, but you can see this also as a removal of the previous limitation. The high level concept can keep the generic name "index sharding strategy" as it's still fitting. You can see this as a plan to not have users to choose between two ways to express the same thing. Thanks, Sanne > > Thanks, > > --Gunnar > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From steve at hibernate.org Fri Apr 22 11:15:35 2016 From: steve at hibernate.org (Steve Ebersole) Date: Fri, 22 Apr 2016 15:15:35 +0000 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Right, this is actually exactly what I end up doing for any dealing with hibernate.org or in.relation.to... Keep in mind I just want to author come content :) Personally I find the whole process just gets in the way. Generally right out of the chute we have to deal with forced pushes on staging and getting that all straightened out. Then I have to locally fight docker, etc to get the site built and hosted. It just feels like a lot (to me) to author some content. On Fri, Apr 22, 2016 at 5:30 AM Sanne Grinovero wrote: > There's a middle-ground strategy which might be cool to try. > > Go here: > - > https://github.com/hibernate/hibernate.org/edit/production/orm/roadmap.adoc > > edit the doc within the browser, confirm the changes with a brief > commit message and CI should pick it up, then publish within 5 > minutes. > > I just did this for the Search roadmap, although I opted for the > 'staging' branch to try it out.. and because I regularly screw up the > syntax. > > -- Sanne > > > On 21 April 2016 at 23:57, Davide D'Alto wrote: > > Hi Steve, > > what problems are you having with hibernate.org? > > I agree with Gunnar that we should try to stick with one look & feel if > > possible. > > > > On Thu, Apr 21, 2016 at 9:00 PM, Steve Ebersole > wrote: > > > >> Because I find it incredibly easier to work with GitHub wiki as opposed > to > >> hibernate.org for authoring. > >> > >> On Thu, Apr 21, 2016, 12:42 PM Gunnar Morling > >> wrote: > >> > >> > Hey, > >> > > >> > What's the reason for maintaining the roadmap in the wiki rather than > >> > hibernate.org itself? > >> > > >> > I hoped we'd centralize this kind of information on hibernate.org; > Looks > >> > a tad more professional to have everything with the same look & field > >> > rather than pointing to other resources as the wiki... Also > searchability > >> > benefits, should we once have a site search. > >> > > >> > --Gunnar > >> > > >> > > >> > > >> > 2016-04-21 19:36 GMT+02:00 Steve Ebersole : > >> > > >> >> I have started maintaining[1] the ORM Roadmap external to > hibernate.org > >> >> itself. I'd like to adjust the link to when under orm/ to point to > this > >> >> external URL rather than the parameterized {project}/roadmap > target. Is > >> >> that possible? And if so, how? > >> >> > >> >> [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap > >> >> > >> > _______________________________________________ > >> >> 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 Fri Apr 22 11:34:36 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Fri, 22 Apr 2016 16:34:36 +0100 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Hi Steve, yes I understand you just want to write some content. But then why not give the approach I just mentioned a try? You can totally skip the staging branch and docker stuff. I will *personally* keep using staging when I'm not sure about formatting and/or am working on something which I want to shape visually. I wouldn't have this option on github pages as its support for style is way more limited, but having more options doesn't seem like a drawback. If you just want to update some text, go ahead on production directly. Heck, worst case a mistake can be fixed or reverted.. at least it's versioned ;) On 22 Apr 2016 16:15, "Steve Ebersole" wrote: > Right, this is actually exactly what I end up doing for any dealing with > hibernate.org or in.relation.to... > > Keep in mind I just want to author come content :) > > Personally I find the whole process just gets in the way. Generally right > out of the chute we have to deal with forced pushes on staging and getting > that all straightened out. Then I have to locally fight docker, etc to get > the site built and hosted. It just feels like a lot (to me) to author some > content. > > > On Fri, Apr 22, 2016 at 5:30 AM Sanne Grinovero > wrote: > >> There's a middle-ground strategy which might be cool to try. >> >> Go here: >> - >> https://github.com/hibernate/hibernate.org/edit/production/orm/roadmap.adoc >> >> edit the doc within the browser, confirm the changes with a brief >> commit message and CI should pick it up, then publish within 5 >> minutes. >> >> I just did this for the Search roadmap, although I opted for the >> 'staging' branch to try it out.. and because I regularly screw up the >> syntax. >> >> -- Sanne >> >> >> On 21 April 2016 at 23:57, Davide D'Alto wrote: >> > Hi Steve, >> > what problems are you having with hibernate.org? >> > I agree with Gunnar that we should try to stick with one look & feel if >> > possible. >> > >> > On Thu, Apr 21, 2016 at 9:00 PM, Steve Ebersole >> wrote: >> > >> >> Because I find it incredibly easier to work with GitHub wiki as >> opposed to >> >> hibernate.org for authoring. >> >> >> >> On Thu, Apr 21, 2016, 12:42 PM Gunnar Morling >> >> wrote: >> >> >> >> > Hey, >> >> > >> >> > What's the reason for maintaining the roadmap in the wiki rather than >> >> > hibernate.org itself? >> >> > >> >> > I hoped we'd centralize this kind of information on hibernate.org; >> Looks >> >> > a tad more professional to have everything with the same look & field >> >> > rather than pointing to other resources as the wiki... Also >> searchability >> >> > benefits, should we once have a site search. >> >> > >> >> > --Gunnar >> >> > >> >> > >> >> > >> >> > 2016-04-21 19:36 GMT+02:00 Steve Ebersole : >> >> > >> >> >> I have started maintaining[1] the ORM Roadmap external to >> hibernate.org >> >> >> itself. I'd like to adjust the link to when under orm/ to point to >> this >> >> >> external URL rather than the parameterized {project}/roadmap >> target. Is >> >> >> that possible? And if so, how? >> >> >> >> >> >> [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap >> >> >> >> >> > _______________________________________________ >> >> >> 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 mincong.h at gmail.com Fri Apr 22 17:20:13 2016 From: mincong.h at gmail.com (Mincong Huang) Date: Fri, 22 Apr 2016 23:20:13 +0200 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: <001a113f7d24b49bcf053117c9ba@google.com> References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Hi everybody, Thanks for accepting my application of GSoC !! Really excited to having chance to work the hibernate team. I'm so happy to see this email. It's just like a dream, can't believe it is true !! Thanks for choosing me. I'll try my best to accomplish this mission !! Happy coding and good night :-) Cheers, Mincong On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < summerofcode-noreply at google.com> wrote: > [image: Google Summer of Code] > > Hi mincongh, > > Welcome to GSoC 2016! > > Your proposal Hibernate Search: JSR 352 batch job for re-indexing entities > > has been accepted! > > We look forward to seeing the great things you will accomplish this summer > with JBoss Community. > > This email contains important information about your participation in GSoC > this year. Please read it carefully. > > Over the next month you will take part in the Community Bonding period > with your organization. This period is for you to become familiar with the > organization's code base, version control and other infrastructure. You > will be getting to know the community and its practices, as well as working > with your mentor on milestones for the summer. > > Complete all of these steps as soon as you can: > > 1. Read the Accepted Student Information > > 2. Upload your tax > form *before May 16, 2016 at 19:00 UTC* > 3. Read the Student Payment Information > > 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC > 5. Verify your shipping address, promotional materials, and t-shirt > information on your profile > . > > If you have questions about anything in this email, please email the > Google GSoC support team at gsoc-support at google.com. Don?t email the > student list with tax or payment issues. > > Have a great summer! > > Google Open Source Programs team > > This email was sent to mincong.h at gmail.com. > > You are receiving this email because of your participation in Google > Summer of Code 2016. > https://summerofcode.withgoogle.com > > To leave the program and stop receiving all emails, you can go to your > profile and > request deletion of your program profile. > > For any questions, please contact gsoc-support at google.com. Replies to > this message go to an unmonitored mailbox. > > ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, > USA > From gunnar at hibernate.org Sat Apr 23 04:39:09 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 23 Apr 2016 10:39:09 +0200 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Hi Mincong, Congrats and welcome to this year's GSoC! Looking forward to the project and your contributions very much! @Everyone: Please join me in welcoming Mincong to the team! He is a student living in France and as part of Google Summer of Code he will be working on an alternative for mass indexing entities in Hibernate Search based on the JSR 352 for batch applications (see [1] for the project proposal). I'll be mentoring him. @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend before the action begins and then let's get a discussion on the details started. Onwards, --Gunnar [1] https://summerofcode.withgoogle.com/serve/5594702887780352/ 2016-04-22 23:20 GMT+02:00 Mincong Huang : > Hi everybody, > > Thanks for accepting my application of GSoC !! Really excited to having > chance to work the hibernate team. I'm so happy to see this email. It's > just > like a dream, can't believe it is true !! Thanks for choosing me. I'll try > my > best to accomplish this mission !! Happy coding and good night :-) > > Cheers, > Mincong > > On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < > summerofcode-noreply at google.com> wrote: > >> [image: Google Summer of Code] >> >> Hi mincongh, >> >> Welcome to GSoC 2016! >> >> Your proposal Hibernate Search: JSR 352 batch job for re-indexing >> entities >> >> has been accepted! >> >> We look forward to seeing the great things you will accomplish this >> summer with JBoss Community. >> >> This email contains important information about your participation in >> GSoC this year. Please read it carefully. >> >> Over the next month you will take part in the Community Bonding period >> with your organization. This period is for you to become familiar with the >> organization's code base, version control and other infrastructure. You >> will be getting to know the community and its practices, as well as working >> with your mentor on milestones for the summer. >> >> Complete all of these steps as soon as you can: >> >> 1. Read the Accepted Student Information >> >> 2. Upload your tax >> form *before May 16, 2016 at 19:00 UTC* >> 3. Read the Student Payment Information >> >> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC >> 5. Verify your shipping address, promotional materials, and t-shirt >> information on your profile >> . >> >> If you have questions about anything in this email, please email the >> Google GSoC support team at gsoc-support at google.com. Don?t email the >> student list with tax or payment issues. >> >> Have a great summer! >> >> Google Open Source Programs team >> >> This email was sent to mincong.h at gmail.com. >> >> You are receiving this email because of your participation in Google >> Summer of Code 2016. >> https://summerofcode.withgoogle.com >> >> To leave the program and stop receiving all emails, you can go to your >> profile and >> request deletion of your program profile. >> >> For any questions, please contact gsoc-support at google.com. Replies to >> this message go to an unmonitored mailbox. >> >> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, >> USA >> > > From steve at hibernate.org Sat Apr 23 10:21:46 2016 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 23 Apr 2016 14:21:46 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager Message-ID: There are a number of "expectation changes" that come about from consolidating hibernate-entitymanger into hibernate-core. Some we have discussed; some we have not. Hopefully we can come to a consensus regards how to deal with these changes... The first one is different exception types. We have discussed this before. For now, in an effort to fix test failures and move forward with developing, I simply changed failing tests to expect the JPA defined exceptions. I had mentioned, where possible, to to throw a combination of the 2 expected exceptions. Generally this falls into 2 discrete categories: 1. JPA expects a PersistenceException and we have historically thrown a HibernateException 2. JPA expects some form of JDK RuntimeException (IllegalArgumentException, IllegalStateException, etc) and we have historically thrown a HibernateException It is unfortunate that Java does not allow exceptions to be defined by means of interfaces; that's the only "clean" way I see to do this - that would have allowed us to define concrete exception classes that extend PersistenceException, IllegalArgumentException, etc and that implement HibernateException. So I see 3 potential solutions (feel free to bring up others). 1. Just move to JPA expected exceptions. 2. Have HibernateException extend PersistenceException and just not worry about the change in expectation in regards to that second category. 3. Push exception handling behind a strategy. This would have to be a pretty specific strategy for very specific cases. The first and second options are pretty self-explanatory and straight-forward so I won't go into detail there. Just realize that these change the expectation for the user. They'd have to change their code to catch these JPA-defined exceptions. The other option, I see, is to h The third option is perfect in theory, but it is very tedious. For example, take the case of trying to perform some operation on a closed Session/EntityManager. Hibernate historically threw a HibernateException here. JPA says that should result in an IllegalStateException. So in SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd call out to the strategy to handle that condition. Even more, Hibernate (historically) and JPA disagree about which methods getting called on a closed Session/EntityManager should lead to an exception. For example, JPA says calling EntityManager#close on a closed EntityManager should result in an exception; Hibernate historically did not care if you called Session#close on a closed Session. So that is a special case, and every one of those special cases would have to be exposed and handled in the exception handling strategy in additional to the general cases. Another change in expectation is in regards to operations outside of a transaction, which I consider a questionable pattern anyway. Hibernate historically allowed that; JPA explicitly disallows it. In a way this could fall under the exception discussion above, meaning we could push that distinction behind the exception handling strategy. Or we could decide that we are going to stop supporting that. There are a lot of other highly questionable things I have seen in the tests that JPA explicitly disallows that I think we ought to just stop supporting and opt for the JPA way, although I am open to discussing them if any feels strongly about them. Some of these include: - Asking a Session if is contains (Session/EntityManager#contains) a non-entity. Hibernate historically would just return false. JPA states that should be an exception. - Accessing Session/EntityManager#getTransaction. JPA says that is only allowed for JDBC transactions. Hibernate always allows it. If we go the route of an "exception handling strategy" a lot of the other points I mentioned above could just be pushed behind that strategy. But I really want to start looking critically at what we support today that we maybe really should not be. From steve at hibernate.org Sat Apr 23 10:29:51 2016 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 23 Apr 2016 14:29:51 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: Just realized that I should have mentioned an important plan that helps understand the idea behind the "exception handling strategy" route. I plan to keep track of how a SessionFactory was bootstrapped in some fashion. So when it was bootstrapped from EntityManagerFactoryBuilder (which JPA bootstrap methods leverage) we'd select the "JPA exception handling" strategy impl. When not, we'd use the "legacy Hibernate exception handling" strategy. On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole wrote: > There are a number of "expectation changes" that come about from > consolidating hibernate-entitymanger into hibernate-core. Some we have > discussed; some we have not. Hopefully we can come to a consensus regards > how to deal with these changes... > > The first one is different exception types. We have discussed this > before. For now, in an effort to fix test failures and move forward with > developing, I simply changed failing tests to expect the JPA defined > exceptions. I had mentioned, where possible, to to throw a combination of > the 2 expected exceptions. Generally this falls into 2 discrete categories: > > > 1. JPA expects a PersistenceException and we have historically thrown > a HibernateException > 2. JPA expects some form of JDK RuntimeException > (IllegalArgumentException, IllegalStateException, etc) and we have > historically thrown a HibernateException > > It is unfortunate that Java does not allow exceptions to be defined by > means of interfaces; that's the only "clean" way I see to do this - that > would have allowed us to define concrete exception classes that extend > PersistenceException, IllegalArgumentException, etc and that implement HibernateException. > > > So I see 3 potential solutions (feel free to bring up others). > > 1. Just move to JPA expected exceptions. > 2. Have HibernateException extend PersistenceException and just not > worry about the change in expectation in regards to that second category. > 3. Push exception handling behind a strategy. This would have to be a > pretty specific strategy for very specific cases. > > The first and second options are pretty self-explanatory and > straight-forward so I won't go into detail there. Just realize that these > change the expectation for the user. They'd have to change their code to > catch these JPA-defined exceptions. > The other option, I see, is to h > > The third option is perfect in theory, but it is very tedious. For > example, take the case of trying to perform some operation on a closed > Session/EntityManager. Hibernate historically threw a HibernateException > here. JPA says that should result in an IllegalStateException. So in > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd > call out to the strategy to handle that condition. Even more, Hibernate > (historically) and JPA disagree about which methods getting called on a > closed Session/EntityManager should lead to an exception. For example, > JPA says calling EntityManager#close on a closed EntityManager should > result in an exception; Hibernate historically did not care if you called > Session#close on a closed Session. So that is a special case, and every > one of those special cases would have to be exposed and handled in the > exception handling strategy in additional to the general cases. > > Another change in expectation is in regards to operations outside of a > transaction, which I consider a questionable pattern anyway. Hibernate > historically allowed that; JPA explicitly disallows it. In a way this > could fall under the exception discussion above, meaning we could push that > distinction behind the exception handling strategy. Or we could decide > that we are going to stop supporting that. > > There are a lot of other highly questionable things I have seen in the > tests that JPA explicitly disallows that I think we ought to just stop > supporting and opt for the JPA way, although I am open to discussing them > if any feels strongly about them. Some of these include: > > - Asking a Session if is contains (Session/EntityManager#contains) a > non-entity. Hibernate historically would just return false. JPA states > that should be an exception. > - Accessing Session/EntityManager#getTransaction. JPA says that is > only allowed for JDBC transactions. Hibernate always allows it. > > If we go the route of an "exception handling strategy" a lot of the other > points I mentioned above could just be pushed behind that strategy. But I > really want to start looking critically at what we support today that we > maybe really should not be. > From crancran at gmail.com Sat Apr 23 11:37:45 2016 From: crancran at gmail.com (Chris Cranford) Date: Sat, 23 Apr 2016 10:37:45 -0500 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Welcome aboard, Mincong!! On Sat, Apr 23, 2016 at 3:39 AM, Gunnar Morling wrote: > Hi Mincong, > > Congrats and welcome to this year's GSoC! Looking forward to the project > and your contributions very much! > > @Everyone: Please join me in welcoming Mincong to the team! He is a student > living in France and as part of Google Summer of Code he will be working on > an alternative for mass indexing entities in Hibernate Search based on the > JSR 352 for batch applications (see [1] for the project proposal). I'll be > mentoring him. > > @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend > before the action begins and then let's get a discussion on the details > started. > > Onwards, > > --Gunnar > > [1] https://summerofcode.withgoogle.com/serve/5594702887780352/ > > > > 2016-04-22 23:20 GMT+02:00 Mincong Huang : > > > Hi everybody, > > > > Thanks for accepting my application of GSoC !! Really excited to having > > chance to work the hibernate team. I'm so happy to see this email. It's > > just > > like a dream, can't believe it is true !! Thanks for choosing me. I'll > try > > my > > best to accomplish this mission !! Happy coding and good night :-) > > > > Cheers, > > Mincong > > > > On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < > > summerofcode-noreply at google.com> wrote: > > > >> [image: Google Summer of Code] > >> > >> Hi mincongh, > >> > >> Welcome to GSoC 2016! > >> > >> Your proposal Hibernate Search: JSR 352 batch job for re-indexing > >> entities > >> < > https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/ > > > >> has been accepted! > >> > >> We look forward to seeing the great things you will accomplish this > >> summer with JBoss Community. > >> > >> This email contains important information about your participation in > >> GSoC this year. Please read it carefully. > >> > >> Over the next month you will take part in the Community Bonding period > >> with your organization. This period is for you to become familiar with > the > >> organization's code base, version control and other infrastructure. You > >> will be getting to know the community and its practices, as well as > working > >> with your mentor on milestones for the summer. > >> > >> Complete all of these steps as soon as you can: > >> > >> 1. Read the Accepted Student Information > >> < > https://developers.google.com/open-source/gsoc/help/accepted-students> > >> 2. Upload your tax > >> form *before May 16, 2016 at 19:00 UTC* > >> 3. Read the Student Payment Information > >> > >> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC > >> 5. Verify your shipping address, promotional materials, and t-shirt > >> information on your profile > >> . > >> > >> If you have questions about anything in this email, please email the > >> Google GSoC support team at gsoc-support at google.com. Don?t email the > >> student list with tax or payment issues. > >> > >> Have a great summer! > >> > >> Google Open Source Programs team > >> > >> This email was sent to mincong.h at gmail.com. > >> > >> You are receiving this email because of your participation in Google > >> Summer of Code 2016. > >> https://summerofcode.withgoogle.com > >> > >> To leave the program and stop receiving all emails, you can go to your > >> profile and > >> request deletion of your program profile. > >> > >> For any questions, please contact gsoc-support at google.com. Replies to > >> this message go to an unmonitored mailbox. > >> > >> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, > >> USA > >> > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Sat Apr 23 11:44:10 2016 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 23 Apr 2016 15:44:10 +0000 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Congrats and thanks to you Mincing :) On Sat, Apr 23, 2016, 10:38 AM Chris Cranford wrote: > Welcome aboard, Mincong!! > > On Sat, Apr 23, 2016 at 3:39 AM, Gunnar Morling > wrote: > > > Hi Mincong, > > > > Congrats and welcome to this year's GSoC! Looking forward to the project > > and your contributions very much! > > > > @Everyone: Please join me in welcoming Mincong to the team! He is a > student > > living in France and as part of Google Summer of Code he will be working > on > > an alternative for mass indexing entities in Hibernate Search based on > the > > JSR 352 for batch applications (see [1] for the project proposal). I'll > be > > mentoring him. > > > > @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend > > before the action begins and then let's get a discussion on the details > > started. > > > > Onwards, > > > > --Gunnar > > > > [1] https://summerofcode.withgoogle.com/serve/5594702887780352/ > > > > > > > > 2016-04-22 23:20 GMT+02:00 Mincong Huang : > > > > > Hi everybody, > > > > > > Thanks for accepting my application of GSoC !! Really excited to having > > > chance to work the hibernate team. I'm so happy to see this email. It's > > > just > > > like a dream, can't believe it is true !! Thanks for choosing me. I'll > > try > > > my > > > best to accomplish this mission !! Happy coding and good night :-) > > > > > > Cheers, > > > Mincong > > > > > > On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < > > > summerofcode-noreply at google.com> wrote: > > > > > >> [image: Google Summer of Code] > > >> > > >> Hi mincongh, > > >> > > >> Welcome to GSoC 2016! > > >> > > >> Your proposal Hibernate Search: JSR 352 batch job for re-indexing > > >> entities > > >> < > > > https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/ > > > > > >> has been accepted! > > >> > > >> We look forward to seeing the great things you will accomplish this > > >> summer with JBoss Community. > > >> > > >> This email contains important information about your participation in > > >> GSoC this year. Please read it carefully. > > >> > > >> Over the next month you will take part in the Community Bonding period > > >> with your organization. This period is for you to become familiar with > > the > > >> organization's code base, version control and other infrastructure. > You > > >> will be getting to know the community and its practices, as well as > > working > > >> with your mentor on milestones for the summer. > > >> > > >> Complete all of these steps as soon as you can: > > >> > > >> 1. Read the Accepted Student Information > > >> < > > https://developers.google.com/open-source/gsoc/help/accepted-students> > > >> 2. Upload your > tax > > >> form *before May 16, 2016 at 19:00 UTC* > > >> 3. Read the Student Payment Information > > >> > > >> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC > > >> 5. Verify your shipping address, promotional materials, and t-shirt > > >> information on your profile > > >> . > > >> > > >> If you have questions about anything in this email, please email the > > >> Google GSoC support team at gsoc-support at google.com. Don?t email the > > >> student list with tax or payment issues. > > >> > > >> Have a great summer! > > >> > > >> Google Open Source Programs team > > >> > > >> This email was sent to mincong.h at gmail.com. > > >> > > >> You are receiving this email because of your participation in Google > > >> Summer of Code 2016. > > >> https://summerofcode.withgoogle.com > > >> > > >> To leave the program and stop receiving all emails, you can go to your > > >> profile and > > >> request deletion of your program profile. > > >> > > >> For any questions, please contact gsoc-support at google.com. Replies to > > >> this message go to an unmonitored mailbox. > > >> > > >> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA > 94043, > > >> USA > > >> > > > > > > > > _______________________________________________ > > 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 Sat Apr 23 12:17:46 2016 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 23 Apr 2016 16:17:46 +0000 Subject: [hibernate-dev] Hibernate.org and Roadmap nav link In-Reply-To: References: Message-ID: Like I said, that is exactly what I end up doing now. When I do a release I write the blog directly in the in.relation.to repo via the GitHub UI editor. Same for the release descriptor in hibernate.org. SO I am familiar with that approach. On Fri, Apr 22, 2016 at 10:34 AM Sanne Grinovero wrote: > Hi Steve, yes I understand you just want to write some content. > But then why not give the approach I just mentioned a try? > > You can totally skip the staging branch and docker stuff. > > I will *personally* keep using staging when I'm not sure about formatting > and/or am working on something which I want to shape visually. I wouldn't > have this option on github pages as its support for style is way more > limited, but having more options doesn't seem like a drawback. > > If you just want to update some text, go ahead on production directly. > Heck, worst case a mistake can be fixed or reverted.. at least it's > versioned ;) > On 22 Apr 2016 16:15, "Steve Ebersole" wrote: > >> Right, this is actually exactly what I end up doing for any dealing with >> hibernate.org or in.relation.to... >> >> Keep in mind I just want to author come content :) >> >> Personally I find the whole process just gets in the way. Generally >> right out of the chute we have to deal with forced pushes on staging and >> getting that all straightened out. Then I have to locally fight docker, >> etc to get the site built and hosted. It just feels like a lot (to me) to >> author some content. >> >> >> On Fri, Apr 22, 2016 at 5:30 AM Sanne Grinovero >> wrote: >> >>> There's a middle-ground strategy which might be cool to try. >>> >>> Go here: >>> - >>> https://github.com/hibernate/hibernate.org/edit/production/orm/roadmap.adoc >>> >>> edit the doc within the browser, confirm the changes with a brief >>> commit message and CI should pick it up, then publish within 5 >>> minutes. >>> >>> I just did this for the Search roadmap, although I opted for the >>> 'staging' branch to try it out.. and because I regularly screw up the >>> syntax. >>> >>> -- Sanne >>> >>> >>> On 21 April 2016 at 23:57, Davide D'Alto wrote: >>> > Hi Steve, >>> > what problems are you having with hibernate.org? >>> > I agree with Gunnar that we should try to stick with one look & feel if >>> > possible. >>> > >>> > On Thu, Apr 21, 2016 at 9:00 PM, Steve Ebersole >>> wrote: >>> > >>> >> Because I find it incredibly easier to work with GitHub wiki as >>> opposed to >>> >> hibernate.org for authoring. >>> >> >>> >> On Thu, Apr 21, 2016, 12:42 PM Gunnar Morling >>> >> wrote: >>> >> >>> >> > Hey, >>> >> > >>> >> > What's the reason for maintaining the roadmap in the wiki rather >>> than >>> >> > hibernate.org itself? >>> >> > >>> >> > I hoped we'd centralize this kind of information on hibernate.org; >>> Looks >>> >> > a tad more professional to have everything with the same look & >>> field >>> >> > rather than pointing to other resources as the wiki... Also >>> searchability >>> >> > benefits, should we once have a site search. >>> >> > >>> >> > --Gunnar >>> >> > >>> >> > >>> >> > >>> >> > 2016-04-21 19:36 GMT+02:00 Steve Ebersole : >>> >> > >>> >> >> I have started maintaining[1] the ORM Roadmap external to >>> hibernate.org >>> >> >> itself. I'd like to adjust the link to when under orm/ to point >>> to this >>> >> >> external URL rather than the parameterized {project}/roadmap >>> target. Is >>> >> >> that possible? And if so, how? >>> >> >> >>> >> >> [1] https://github.com/hibernate/hibernate-orm/wiki/Roadmap >>> >> >> >>> >> > _______________________________________________ >>> >> >> 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 Sat Apr 23 16:16:15 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Sat, 23 Apr 2016 22:16:15 +0200 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Welcome aboard, Mincong! On Sat, Apr 23, 2016 at 5:44 PM, Steve Ebersole wrote: > Congrats and thanks to you Mincing :) From dreborier at gmail.com Sun Apr 24 06:55:02 2016 From: dreborier at gmail.com (andrea boriero) Date: Sun, 24 Apr 2016 11:55:02 +0100 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Welcome Mincong!!! On 22 April 2016 at 22:20, Mincong Huang wrote: > Hi everybody, > > Thanks for accepting my application of GSoC !! Really excited to having > chance to work the hibernate team. I'm so happy to see this email. It's > just > like a dream, can't believe it is true !! Thanks for choosing me. I'll try > my > best to accomplish this mission !! Happy coding and good night :-) > > Cheers, > Mincong > > On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < > summerofcode-noreply at google.com> wrote: > > > [image: Google Summer of Code] > > > > Hi mincongh, > > > > Welcome to GSoC 2016! > > > > Your proposal Hibernate Search: JSR 352 batch job for re-indexing > entities > > < > https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/ > > > > has been accepted! > > > > We look forward to seeing the great things you will accomplish this > summer > > with JBoss Community. > > > > This email contains important information about your participation in > GSoC > > this year. Please read it carefully. > > > > Over the next month you will take part in the Community Bonding period > > with your organization. This period is for you to become familiar with > the > > organization's code base, version control and other infrastructure. You > > will be getting to know the community and its practices, as well as > working > > with your mentor on milestones for the summer. > > > > Complete all of these steps as soon as you can: > > > > 1. Read the Accepted Student Information > > < > https://developers.google.com/open-source/gsoc/help/accepted-students> > > 2. Upload your tax > > form *before May 16, 2016 at 19:00 UTC* > > 3. Read the Student Payment Information > > > > 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC > > 5. Verify your shipping address, promotional materials, and t-shirt > > information on your profile > > . > > > > If you have questions about anything in this email, please email the > > Google GSoC support team at gsoc-support at google.com. Don?t email the > > student list with tax or payment issues. > > > > Have a great summer! > > > > Google Open Source Programs team > > > > This email was sent to mincong.h at gmail.com. > > > > You are receiving this email because of your participation in Google > > Summer of Code 2016. > > https://summerofcode.withgoogle.com > > > > To leave the program and stop receiving all emails, you can go to your > > profile and > > request deletion of your program profile. > > > > For any questions, please contact gsoc-support at google.com. Replies to > > this message go to an unmonitored mailbox. > > > > ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, > > USA > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Sun Apr 24 14:00:09 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Sun, 24 Apr 2016 20:00:09 +0200 Subject: [hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider In-Reply-To: References: Message-ID: 2016-04-22 12:55 GMT+02:00 Sanne Grinovero : > On 21 April 2016 at 18:35, Gunnar Morling wrote: > > Hi, > > > > As IndexShardingStrategy is deprecated, I thought I'd use > > ShardIdentifierProvider and friends in new code I write. It's not clear > to > > me though, how it's meant to be used. > > > > Some questions: > > > > * Is it correct that EntityIndexBinding#getShardIdentifierProvider() > > returns null is sharding is not used for this entity? > > Yes, as the javadoc suggests. > Ok, thanks; The current comment is rather vague, it should more clearly state when the return value will be null. I don't like to return "null"s so if > > > I suppose in that > > case I simply can use EntityIndexBinding.getIndexManagers()[0]? > > I'm not understanding how this related to the previous question. What > are you up to? > E.g. look at DefaultBatchBackend. Working on improving batch performance for the ES backend, I came across the deprecation of IndexShardingStrategy and wondered what it'd take to get rid of that. N.B. the intent of the sharding strategies is not to give end users a > reference to the IndexManagers. > So the `ShardIdentifierProvider` contract lets people identify the > target indexes by naming them. > The deprecation comment on IndexShardingStrategy says "Use ShardIdentifierProvider instead". Are you saying that this cannot be done actually? That's what I tried: "use SIP" and from the shard name obtain an index manager. But your next comment below makes me wonder whether that's actually desirable. > > > * What's the envisioned way to get the IM for a given shard once I know > the > > shard id? I found IndexManagerHolder.getOrCreateIndexManager(), but this > > expects a *DynamicSharding*EntityIndexBinding, so how would it work for > > non-dynamic sharding? > > The envisioned way is that the user doesn't get a reference to the > IndexManager, > what he needs is to identify the indexes - not act on them. > See above. I'm confused by the deprecation comment on IndexShardingStrategy. Right now I don't see how ShardIdentifierProvider can be used instead. > > > > > It's tough to see how the pieces are meant to fit together, now that > > IndexShardingStrategy and ShardIdentifierProvider are there. I hope we > can > > get rid of the former soon, simplifying the code a bit? > > Yes. It has been deprecated for long enough, we could give a shot of > removing the old one if this helps something you're doing? > > I wouldn't remove it yet if it's not in the way of our 5.6 requirements. > > BTW the contract "IndexShardingStrategy" is deprecated so that users > of sharding move to the new API, but that interface still is the > foundation of the implementation even for dynamic sharding.. it's not > being removed from internals. > Aaah, so are you saying that IndexShardingStrategy is only deprecated for use by Hibernate Search users, but internally it's not meant to go away? I.e. it'll just be removed from the public API but will continue to exist in some "impl" package? If so, some more explicit comment about the nature of this deprecation would help :) > The new contract just enables us to add new shards dynamically, but > you can see this also as a removal of the previous limitation. The > high level concept can keep the generic name "index sharding strategy" > as it's still fitting. > > You can see this as a plan to not have users to choose between two > ways to express the same thing. > > Thanks, > Sanne > > > > > Thanks, > > > > --Gunnar > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Mon Apr 25 01:04:11 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 25 Apr 2016 08:04:11 +0300 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: Your second email summarizes my thoughts as well. If we can separate the exception handling in two separate strategies that are defined during bootstrap (JPA vs Hibernate), I think that's the way to go. There so many projects out there that rely on the exception type being thrown, and changing those would make it very difficult for them to migrate to this new version. But that only affects Hibernate-native projects since, for those who have been using JPA, they already expect the JPA exceptions anyway. As for the other behavior discrepancies: 1. "calling EntityManager#close on a closed EntityManager should result in an exception;" - that's a reasonable default and shouldn't cause too much trouble. 2. "Another change in expectation is in regards to operations outside of a transaction" - in JPA we can execute queries outside a transaction, but any write will fail if there is no transactional context, which is reasonable for me too. If Hibernate allows writes outside of a transactional context, that's definitely a thing we should not support anyway. 3. "Asking a Session if is contains (Session/EntityManager#contains) a non-entity" - we can handle this with the separate exception handler strategies to retain both JPA and Hibernate behaviors. 4. "Accessing Session/EntityManager#getTransaction. JPA says that is only allowed for JDBC transactions. Hibernate always allows it." - I'd choose the Hibernate behavior because I don;t see how it can cause any issue and it's an enhancement as well. Vlad On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole wrote: > Just realized that I should have mentioned an important plan that helps > understand the idea behind the "exception handling strategy" route. I plan > to keep track of how a SessionFactory was bootstrapped in some fashion. So > when it was bootstrapped from EntityManagerFactoryBuilder (which JPA > bootstrap methods leverage) we'd select the "JPA exception handling" > strategy impl. When not, we'd use the "legacy Hibernate exception > handling" strategy. > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole > wrote: > > > There are a number of "expectation changes" that come about from > > consolidating hibernate-entitymanger into hibernate-core. Some we have > > discussed; some we have not. Hopefully we can come to a consensus > regards > > how to deal with these changes... > > > > The first one is different exception types. We have discussed this > > before. For now, in an effort to fix test failures and move forward with > > developing, I simply changed failing tests to expect the JPA defined > > exceptions. I had mentioned, where possible, to to throw a combination > of > > the 2 expected exceptions. Generally this falls into 2 discrete > categories: > > > > > > 1. JPA expects a PersistenceException and we have historically thrown > > a HibernateException > > 2. JPA expects some form of JDK RuntimeException > > (IllegalArgumentException, IllegalStateException, etc) and we have > > historically thrown a HibernateException > > > > It is unfortunate that Java does not allow exceptions to be defined by > > means of interfaces; that's the only "clean" way I see to do this - that > > would have allowed us to define concrete exception classes that extend > > PersistenceException, IllegalArgumentException, etc and that implement > HibernateException. > > > > > > So I see 3 potential solutions (feel free to bring up others). > > > > 1. Just move to JPA expected exceptions. > > 2. Have HibernateException extend PersistenceException and just not > > worry about the change in expectation in regards to that second > category. > > 3. Push exception handling behind a strategy. This would have to be a > > pretty specific strategy for very specific cases. > > > > The first and second options are pretty self-explanatory and > > straight-forward so I won't go into detail there. Just realize that > these > > change the expectation for the user. They'd have to change their code to > > catch these JPA-defined exceptions. > > The other option, I see, is to h > > > > The third option is perfect in theory, but it is very tedious. For > > example, take the case of trying to perform some operation on a closed > > Session/EntityManager. Hibernate historically threw a HibernateException > > here. JPA says that should result in an IllegalStateException. So in > > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd > > call out to the strategy to handle that condition. Even more, Hibernate > > (historically) and JPA disagree about which methods getting called on a > > closed Session/EntityManager should lead to an exception. For example, > > JPA says calling EntityManager#close on a closed EntityManager should > > result in an exception; Hibernate historically did not care if you called > > Session#close on a closed Session. So that is a special case, and every > > one of those special cases would have to be exposed and handled in the > > exception handling strategy in additional to the general cases. > > > > Another change in expectation is in regards to operations outside of a > > transaction, which I consider a questionable pattern anyway. Hibernate > > historically allowed that; JPA explicitly disallows it. In a way this > > could fall under the exception discussion above, meaning we could push > that > > distinction behind the exception handling strategy. Or we could decide > > that we are going to stop supporting that. > > > > There are a lot of other highly questionable things I have seen in the > > tests that JPA explicitly disallows that I think we ought to just stop > > supporting and opt for the JPA way, although I am open to discussing them > > if any feels strongly about them. Some of these include: > > > > - Asking a Session if is contains (Session/EntityManager#contains) a > > non-entity. Hibernate historically would just return false. JPA > states > > that should be an exception. > > - Accessing Session/EntityManager#getTransaction. JPA says that is > > only allowed for JDBC transactions. Hibernate always allows it. > > > > If we go the route of an "exception handling strategy" a lot of the other > > points I mentioned above could just be pushed behind that strategy. But > I > > really want to start looking critically at what we support today that we > > maybe really should not be. > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mincong.h at gmail.com Mon Apr 25 03:07:51 2016 From: mincong.h at gmail.com (Mincong Huang) Date: Mon, 25 Apr 2016 09:07:51 +0200 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Hi Gunnar, Thanks you and everybody in hibernate-dev. So glad to join you :) Before the action begins, here're some progress I've done in these weeks : - Built a simple Apache Lucene example to understand how index and search works - Built a simple Hibernate Search example to understand how to transfer a simple lucene query (keyword, fuzzy, wildcard query) into FullTextQuery using FullTextEntityManager and JPA - Contributed to HSEARCH-2207 : Treat BooleanQuery as an immutable Query - Ran some batch examples on WildFly 10.0. (examples found at github.com/javaee-samples/javaee7-samples) - Building a simple batch example containing reader, processor, writer and a checkpoint algorithm. This one is still in progress, because I didn't found ways to break the batch job, and then test the checkpoint. Cheers, Mincong On Sat, Apr 23, 2016 at 10:39 AM, Gunnar Morling wrote: > Hi Mincong, > > Congrats and welcome to this year's GSoC! Looking forward to the project > and your contributions very much! > > @Everyone: Please join me in welcoming Mincong to the team! He is a > student living in France and as part of Google Summer of Code he will be > working on an alternative for mass indexing entities in Hibernate Search > based on the JSR 352 for batch applications (see [1] for the project > proposal). I'll be mentoring him. > > @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend > before the action begins and then let's get a discussion on the details > started. > > Onwards, > > --Gunnar > > [1] https://summerofcode.withgoogle.com/serve/5594702887780352/ > > > > 2016-04-22 23:20 GMT+02:00 Mincong Huang : > >> Hi everybody, >> >> Thanks for accepting my application of GSoC !! Really excited to having >> chance to work the hibernate team. I'm so happy to see this email. It's >> just >> like a dream, can't believe it is true !! Thanks for choosing me. I'll >> try my >> best to accomplish this mission !! Happy coding and good night :-) >> >> Cheers, >> Mincong >> >> On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < >> summerofcode-noreply at google.com> wrote: >> >>> [image: Google Summer of Code] >>> >>> Hi mincongh, >>> >>> Welcome to GSoC 2016! >>> >>> Your proposal Hibernate Search: JSR 352 batch job for re-indexing >>> entities >>> >>> has been accepted! >>> >>> We look forward to seeing the great things you will accomplish this >>> summer with JBoss Community. >>> >>> This email contains important information about your participation in >>> GSoC this year. Please read it carefully. >>> >>> Over the next month you will take part in the Community Bonding period >>> with your organization. This period is for you to become familiar with the >>> organization's code base, version control and other infrastructure. You >>> will be getting to know the community and its practices, as well as working >>> with your mentor on milestones for the summer. >>> >>> Complete all of these steps as soon as you can: >>> >>> 1. Read the Accepted Student Information >>> >>> 2. Upload your tax >>> form *before May 16, 2016 at 19:00 UTC* >>> 3. Read the Student Payment Information >>> >>> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC >>> 5. Verify your shipping address, promotional materials, and t-shirt >>> information on your profile >>> . >>> >>> If you have questions about anything in this email, please email the >>> Google GSoC support team at gsoc-support at google.com. Don?t email the >>> student list with tax or payment issues. >>> >>> Have a great summer! >>> >>> Google Open Source Programs team >>> >>> This email was sent to mincong.h at gmail.com. >>> >>> You are receiving this email because of your participation in Google >>> Summer of Code 2016. >>> https://summerofcode.withgoogle.com >>> >>> To leave the program and stop receiving all emails, you can go to your >>> profile and >>> request deletion of your program profile. >>> >>> For any questions, please contact gsoc-support at google.com. Replies to >>> this message go to an unmonitored mailbox. >>> >>> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, >>> USA >>> >> >> > From martinbraun123 at aol.com Mon Apr 25 04:02:44 2016 From: martinbraun123 at aol.com (Martin Braun) Date: Mon, 25 Apr 2016 04:02:44 -0400 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: Message-ID: <1544c712568-2a7d-6dd8@webprd-a58.mail.aol.com> Hi Mincong, welcome to the team :) Martin -----Original Message----- From: Mincong Huang To: Gunnar Morling Cc: Hibernate.org Sent: Mon, Apr 25, 2016 9:08 am Subject: Re: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! Hi Gunnar,Thanks you and everybody in hibernate-dev. So glad to join you :)Before the action begins, here're some progress I've done in these weeks : - Built a simple Apache Lucene example to understand how index and search works - Built a simple Hibernate Search example to understand how to transfer a simple lucene query (keyword, fuzzy, wildcard query) into FullTextQuery using FullTextEntityManager and JPA - Contributed to HSEARCH-2207 : Treat BooleanQuery as an immutable Query - Ran some batch examples on WildFly 10.0. (examples found at github.com/javaee-samples/javaee7-samples) - Building a simple batch example containing reader, processor, writer and a checkpoint algorithm. This one is still in progress, because I didn't found ways to break the batch job, and then test the checkpoint.Cheers,MincongOn Sat, Apr 23, 2016 at 10:39 AM, Gunnar Morling wrote:> Hi Mincong,>> Congrats and welcome to this year's GSoC! Looking forward to the project> and your contributions very much!>> @Everyone: Please join me in welcoming Mincong to the team! He is a> student living in France and as part of Google Summer of Code he will be> working on an alternative for mass indexing entities in Hibernate Search> based on the JSR 352 for batch applications (see [1] for the project> proposal). I'll be mentoring him.>> @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend> before the action begins and then let's get a discussion on the details> started.>> Onwards,>> --Gunnar>> [1] https://summerofcode.withgoogle.com/serve/5594702887780352/>>>> 2016-04-22 23:20 GMT+02:00 Mincong Huang :>>> Hi everybody,>>>> Thanks for accepting my application of GSoC !! Really excited to having>> chance to work the hibernate team. I'm so happy to see this email. It's>> just>> like a dream, can't believe it is true !! Thanks for choosing me. I'll>> try my>> best to accomplish this mission !! Happy coding and good night :-)>>>> Cheers,>> Mincong>>>> On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code <>> summerofcode-noreply at google.comnoreply@google.com> wrote:>>>>> [image: Google Summer of Code]>>>>>> Hi mincongh,>>>>>> Welcome to GSoC 2016!>>>>>> Your proposal Hibernate Search: JSR 352 batch job for re-indexing>>> entities>>> >>> has been accepted!>>>>>> We look forward to seeing the great things you will accomplish this>>> summer with JBoss Community.>>>>>> This email contains important information about your participation in>>> GSoC this year. Please read it carefully.>>>>>> Over the next month you will take part in the Community Bonding period>>> with your organization. This period is for you to become familiar with the>>> organization's code base, version control and other infrastructure. You>>> will be getting to know the community and its practices, as well as working>>> with your mentor on milestones for the summer.>>>>>> Complete all of these steps as soon as you can:>>>>>> 1. Read the Accepted Student Information>>> >>> 2. Upload your tax>>> form *before May 16, 2016 at 19:00 UTC*>>> 3. Read the Student Payment Information>>> >>> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC>>> 5. Verify your shipping address, promotional materials, and t-shirt>>> information on your profile>>> .>>>>>> If you have questions about anything in this email, please email the>>> Google GSoC support team at gsoc-support at google.comsupport@google.com. Don?t email the>>> student list with tax or payment issues.>>>>>> Have a great summer!>>>>>> Google Open Source Programs team>>>>>> This email was sent to mincong.h at gmail.commincong.h@gmail.com.>>>>>> You are receiving this email because of your participation in Google>>> Summer of Code 2016.>>> https://summerofcode.withgoogle.com>>>>>> To leave the program and stop receiving all emails, you can go to your>>> profile and>>> request deletion of your program profile.>>>>>> For any questions, please contact gsoc-support at google.comsupport@google.com. Replies to>>> this message go to an unmonitored mailbox.>>>>>> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043,>>> USA>>>>>>>>_______________________________________________hibernate-dev mailing listhibernate-dev at lists.jboss.orgdev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev From gunnar at hibernate.org Mon Apr 25 04:09:55 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 25 Apr 2016 10:09:55 +0200 Subject: [hibernate-dev] HipChat history is limited Message-ID: Hey all, I was looking for a discussion I had with Emmanuel a few month ago on HipChat. But navigating back in time, I could not go before Feb 1st because I hit "You've reached the end of your viewable chat history. Switch to HipChat Plus for unlimited access". Does anyone know whether we can get free HipChat Plus licenses as an OSS project? If not, I personally see no other way than going back to IRC completely. Not sure whether that only affects 1:1 chats (I could go back farther in the history of project rooms), but having access to only less than three months of history is a deal breaker for me. Thanks, --Gunnar From andrea at hibernate.org Mon Apr 25 04:47:38 2016 From: andrea at hibernate.org (andrea boriero) Date: Mon, 25 Apr 2016 09:47:38 +0100 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: Having a Strategy gives us more flexibility so +1. About the expectations I think what Vlad says is reasonable. On 25 April 2016 at 06:04, Vlad Mihalcea wrote: > Your second email summarizes my thoughts as well. If we can separate the > exception handling in two separate strategies that are defined during > bootstrap (JPA vs Hibernate), > I think that's the way to go. > > There so many projects out there that rely on the exception type being > thrown, and changing those would make it very difficult for them to migrate > to this new version. > But that only affects Hibernate-native projects since, for those who have > been using JPA, they already expect the JPA exceptions anyway. > > As for the other behavior discrepancies: > > 1. "calling EntityManager#close on a closed EntityManager should result in > an > exception;" - that's a reasonable default and shouldn't cause too much > trouble. > 2. "Another change in expectation is in regards to operations outside of a > transaction" - in JPA we can execute queries outside a transaction, but any > write will fail if there is no transactional context, which is reasonable > for me too. If Hibernate allows writes outside of a transactional context, > that's definitely a thing we should not support anyway. > 3. "Asking a Session if is contains (Session/EntityManager#contains) a > non-entity" - we can handle this with the separate exception handler > strategies to retain both JPA and Hibernate behaviors. > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is > only allowed > for JDBC transactions. Hibernate always allows it." - I'd choose the > Hibernate behavior because I don;t see how it can cause any issue and it's > an enhancement as well. > > Vlad > > > > > > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole > wrote: > > > Just realized that I should have mentioned an important plan that helps > > understand the idea behind the "exception handling strategy" route. I > plan > > to keep track of how a SessionFactory was bootstrapped in some fashion. > So > > when it was bootstrapped from EntityManagerFactoryBuilder (which JPA > > bootstrap methods leverage) we'd select the "JPA exception handling" > > strategy impl. When not, we'd use the "legacy Hibernate exception > > handling" strategy. > > > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole > > wrote: > > > > > There are a number of "expectation changes" that come about from > > > consolidating hibernate-entitymanger into hibernate-core. Some we have > > > discussed; some we have not. Hopefully we can come to a consensus > > regards > > > how to deal with these changes... > > > > > > The first one is different exception types. We have discussed this > > > before. For now, in an effort to fix test failures and move forward > with > > > developing, I simply changed failing tests to expect the JPA defined > > > exceptions. I had mentioned, where possible, to to throw a combination > > of > > > the 2 expected exceptions. Generally this falls into 2 discrete > > categories: > > > > > > > > > 1. JPA expects a PersistenceException and we have historically > thrown > > > a HibernateException > > > 2. JPA expects some form of JDK RuntimeException > > > (IllegalArgumentException, IllegalStateException, etc) and we have > > > historically thrown a HibernateException > > > > > > It is unfortunate that Java does not allow exceptions to be defined by > > > means of interfaces; that's the only "clean" way I see to do this - > that > > > would have allowed us to define concrete exception classes that extend > > > PersistenceException, IllegalArgumentException, etc and that implement > > HibernateException. > > > > > > > > > So I see 3 potential solutions (feel free to bring up others). > > > > > > 1. Just move to JPA expected exceptions. > > > 2. Have HibernateException extend PersistenceException and just not > > > worry about the change in expectation in regards to that second > > category. > > > 3. Push exception handling behind a strategy. This would have to > be a > > > pretty specific strategy for very specific cases. > > > > > > The first and second options are pretty self-explanatory and > > > straight-forward so I won't go into detail there. Just realize that > > these > > > change the expectation for the user. They'd have to change their code > to > > > catch these JPA-defined exceptions. > > > The other option, I see, is to h > > > > > > The third option is perfect in theory, but it is very tedious. For > > > example, take the case of trying to perform some operation on a closed > > > Session/EntityManager. Hibernate historically threw a > HibernateException > > > here. JPA says that should result in an IllegalStateException. So in > > > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd > > > call out to the strategy to handle that condition. Even more, > Hibernate > > > (historically) and JPA disagree about which methods getting called on a > > > closed Session/EntityManager should lead to an exception. For example, > > > JPA says calling EntityManager#close on a closed EntityManager should > > > result in an exception; Hibernate historically did not care if you > called > > > Session#close on a closed Session. So that is a special case, and > every > > > one of those special cases would have to be exposed and handled in the > > > exception handling strategy in additional to the general cases. > > > > > > Another change in expectation is in regards to operations outside of a > > > transaction, which I consider a questionable pattern anyway. Hibernate > > > historically allowed that; JPA explicitly disallows it. In a way this > > > could fall under the exception discussion above, meaning we could push > > that > > > distinction behind the exception handling strategy. Or we could decide > > > that we are going to stop supporting that. > > > > > > There are a lot of other highly questionable things I have seen in the > > > tests that JPA explicitly disallows that I think we ought to just stop > > > supporting and opt for the JPA way, although I am open to discussing > them > > > if any feels strongly about them. Some of these include: > > > > > > - Asking a Session if is contains (Session/EntityManager#contains) a > > > non-entity. Hibernate historically would just return false. JPA > > states > > > that should be an exception. > > > - Accessing Session/EntityManager#getTransaction. JPA says that is > > > only allowed for JDBC transactions. Hibernate always allows it. > > > > > > If we go the route of an "exception handling strategy" a lot of the > other > > > points I mentioned above could just be pushed behind that strategy. > But > > I > > > really want to start looking critically at what we support today that > we > > > maybe really should not be. > > > > > _______________________________________________ > > 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 gunnar at hibernate.org Mon Apr 25 05:13:48 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Mon, 25 Apr 2016 11:13:48 +0200 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: The strategy approach sounds nice on first thought, but it also adds complexity. I think the underlying question is: What's the long-term strategy around the "Classic API"? Should it remain in place for all times as a complete alternative to the JPA API? Or should we begin to deprecate it and narrow it down in favour of the corresponding functionality standardized in JPA, and only functionality not present in JPA would be exposed through some kind of unwrap()? Without having thought about all the implications too much, I'd lean towards the latter, in which case I vote for "1. Just move to JPA expected exceptions" as part of such larger effort. It'd be interesting to run a poll to see some figures of people using classic vs. JPA. --Gunnar 2016-04-25 10:47 GMT+02:00 andrea boriero : > Having a Strategy gives us more flexibility so +1. > > About the expectations I think what Vlad says is reasonable. > > On 25 April 2016 at 06:04, Vlad Mihalcea wrote: > > > Your second email summarizes my thoughts as well. If we can separate the > > exception handling in two separate strategies that are defined during > > bootstrap (JPA vs Hibernate), > > I think that's the way to go. > > > > There so many projects out there that rely on the exception type being > > thrown, and changing those would make it very difficult for them to > migrate > > to this new version. > > But that only affects Hibernate-native projects since, for those who have > > been using JPA, they already expect the JPA exceptions anyway. > > > > As for the other behavior discrepancies: > > > > 1. "calling EntityManager#close on a closed EntityManager should result > in > > an > > exception;" - that's a reasonable default and shouldn't cause too much > > trouble. > > 2. "Another change in expectation is in regards to operations outside of > a > > transaction" - in JPA we can execute queries outside a transaction, but > any > > write will fail if there is no transactional context, which is reasonable > > for me too. If Hibernate allows writes outside of a transactional > context, > > that's definitely a thing we should not support anyway. > > 3. "Asking a Session if is contains (Session/EntityManager#contains) a > > non-entity" - we can handle this with the separate exception handler > > strategies to retain both JPA and Hibernate behaviors. > > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is > > only allowed > > for JDBC transactions. Hibernate always allows it." - I'd choose the > > Hibernate behavior because I don;t see how it can cause any issue and > it's > > an enhancement as well. > > > > Vlad > > > > > > > > > > > > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole > > wrote: > > > > > Just realized that I should have mentioned an important plan that helps > > > understand the idea behind the "exception handling strategy" route. I > > plan > > > to keep track of how a SessionFactory was bootstrapped in some fashion. > > So > > > when it was bootstrapped from EntityManagerFactoryBuilder (which JPA > > > bootstrap methods leverage) we'd select the "JPA exception handling" > > > strategy impl. When not, we'd use the "legacy Hibernate exception > > > handling" strategy. > > > > > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole > > > wrote: > > > > > > > There are a number of "expectation changes" that come about from > > > > consolidating hibernate-entitymanger into hibernate-core. Some we > have > > > > discussed; some we have not. Hopefully we can come to a consensus > > > regards > > > > how to deal with these changes... > > > > > > > > The first one is different exception types. We have discussed this > > > > before. For now, in an effort to fix test failures and move forward > > with > > > > developing, I simply changed failing tests to expect the JPA defined > > > > exceptions. I had mentioned, where possible, to to throw a > combination > > > of > > > > the 2 expected exceptions. Generally this falls into 2 discrete > > > categories: > > > > > > > > > > > > 1. JPA expects a PersistenceException and we have historically > > thrown > > > > a HibernateException > > > > 2. JPA expects some form of JDK RuntimeException > > > > (IllegalArgumentException, IllegalStateException, etc) and we have > > > > historically thrown a HibernateException > > > > > > > > It is unfortunate that Java does not allow exceptions to be defined > by > > > > means of interfaces; that's the only "clean" way I see to do this - > > that > > > > would have allowed us to define concrete exception classes that > extend > > > > PersistenceException, IllegalArgumentException, etc and that > implement > > > HibernateException. > > > > > > > > > > > > So I see 3 potential solutions (feel free to bring up others). > > > > > > > > 1. Just move to JPA expected exceptions. > > > > 2. Have HibernateException extend PersistenceException and just > not > > > > worry about the change in expectation in regards to that second > > > category. > > > > 3. Push exception handling behind a strategy. This would have to > > be a > > > > pretty specific strategy for very specific cases. > > > > > > > > The first and second options are pretty self-explanatory and > > > > straight-forward so I won't go into detail there. Just realize that > > > these > > > > change the expectation for the user. They'd have to change their > code > > to > > > > catch these JPA-defined exceptions. > > > > The other option, I see, is to h > > > > > > > > The third option is perfect in theory, but it is very tedious. For > > > > example, take the case of trying to perform some operation on a > closed > > > > Session/EntityManager. Hibernate historically threw a > > HibernateException > > > > here. JPA says that should result in an IllegalStateException. So > in > > > > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd > > > > call out to the strategy to handle that condition. Even more, > > Hibernate > > > > (historically) and JPA disagree about which methods getting called > on a > > > > closed Session/EntityManager should lead to an exception. For > example, > > > > JPA says calling EntityManager#close on a closed EntityManager should > > > > result in an exception; Hibernate historically did not care if you > > called > > > > Session#close on a closed Session. So that is a special case, and > > every > > > > one of those special cases would have to be exposed and handled in > the > > > > exception handling strategy in additional to the general cases. > > > > > > > > Another change in expectation is in regards to operations outside of > a > > > > transaction, which I consider a questionable pattern anyway. > Hibernate > > > > historically allowed that; JPA explicitly disallows it. In a way > this > > > > could fall under the exception discussion above, meaning we could > push > > > that > > > > distinction behind the exception handling strategy. Or we could > decide > > > > that we are going to stop supporting that. > > > > > > > > There are a lot of other highly questionable things I have seen in > the > > > > tests that JPA explicitly disallows that I think we ought to just > stop > > > > supporting and opt for the JPA way, although I am open to discussing > > them > > > > if any feels strongly about them. Some of these include: > > > > > > > > - Asking a Session if is contains > (Session/EntityManager#contains) a > > > > non-entity. Hibernate historically would just return false. JPA > > > states > > > > that should be an exception. > > > > - Accessing Session/EntityManager#getTransaction. JPA says that > is > > > > only allowed for JDBC transactions. Hibernate always allows it. > > > > > > > > If we go the route of an "exception handling strategy" a lot of the > > other > > > > points I mentioned above could just be pushed behind that strategy. > > But > > > I > > > > really want to start looking critically at what we support today that > > we > > > > maybe really should not be. > > > > > > > _______________________________________________ > > > 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 Mon Apr 25 06:37:14 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Apr 2016 11:37:14 +0100 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: Gunnar's words seem wise to me: users will need to have the JPA API on classpath anyway, so I don't see why we should have - and maintain - strategies for different kind of exceptions. This might have been useful in the past, but looking forward? If the reasoning is that Hibernate - having more features - could throw more specific and informative exceptions, we could have some Hibernate exceptions to subclass the JPA ones? Would be nice to avoid breaking the expected exception types in a minor, so I'm not sure if you can do that in all cases by subclassing the JPA ones, but I suspect it can get you a long way. On 25 April 2016 at 10:13, Gunnar Morling wrote: > The strategy approach sounds nice on first thought, but it also adds > complexity. > > I think the underlying question is: What's the long-term strategy around > the "Classic API"? Should it remain in place for all times as a complete > alternative to the JPA API? > > Or should we begin to deprecate it and narrow it down in favour of the > corresponding functionality standardized in JPA, and only functionality not > present in JPA would be exposed through some kind of unwrap()? > > Without having thought about all the implications too much, I'd lean > towards the latter, in which case I vote for "1. Just move to JPA expected > exceptions" as part of such larger effort. > > It'd be interesting to run a poll to see some figures of people using > classic vs. JPA. > > --Gunnar > > > > 2016-04-25 10:47 GMT+02:00 andrea boriero : > >> Having a Strategy gives us more flexibility so +1. >> >> About the expectations I think what Vlad says is reasonable. >> >> On 25 April 2016 at 06:04, Vlad Mihalcea wrote: >> >> > Your second email summarizes my thoughts as well. If we can separate the >> > exception handling in two separate strategies that are defined during >> > bootstrap (JPA vs Hibernate), >> > I think that's the way to go. >> > >> > There so many projects out there that rely on the exception type being >> > thrown, and changing those would make it very difficult for them to >> migrate >> > to this new version. >> > But that only affects Hibernate-native projects since, for those who have >> > been using JPA, they already expect the JPA exceptions anyway. >> > >> > As for the other behavior discrepancies: >> > >> > 1. "calling EntityManager#close on a closed EntityManager should result >> in >> > an >> > exception;" - that's a reasonable default and shouldn't cause too much >> > trouble. >> > 2. "Another change in expectation is in regards to operations outside of >> a >> > transaction" - in JPA we can execute queries outside a transaction, but >> any >> > write will fail if there is no transactional context, which is reasonable >> > for me too. If Hibernate allows writes outside of a transactional >> context, >> > that's definitely a thing we should not support anyway. >> > 3. "Asking a Session if is contains (Session/EntityManager#contains) a >> > non-entity" - we can handle this with the separate exception handler >> > strategies to retain both JPA and Hibernate behaviors. >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is >> > only allowed >> > for JDBC transactions. Hibernate always allows it." - I'd choose the >> > Hibernate behavior because I don;t see how it can cause any issue and >> it's >> > an enhancement as well. >> > >> > Vlad >> > >> > >> > >> > >> > >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole >> > wrote: >> > >> > > Just realized that I should have mentioned an important plan that helps >> > > understand the idea behind the "exception handling strategy" route. I >> > plan >> > > to keep track of how a SessionFactory was bootstrapped in some fashion. >> > So >> > > when it was bootstrapped from EntityManagerFactoryBuilder (which JPA >> > > bootstrap methods leverage) we'd select the "JPA exception handling" >> > > strategy impl. When not, we'd use the "legacy Hibernate exception >> > > handling" strategy. >> > > >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole >> > > wrote: >> > > >> > > > There are a number of "expectation changes" that come about from >> > > > consolidating hibernate-entitymanger into hibernate-core. Some we >> have >> > > > discussed; some we have not. Hopefully we can come to a consensus >> > > regards >> > > > how to deal with these changes... >> > > > >> > > > The first one is different exception types. We have discussed this >> > > > before. For now, in an effort to fix test failures and move forward >> > with >> > > > developing, I simply changed failing tests to expect the JPA defined >> > > > exceptions. I had mentioned, where possible, to to throw a >> combination >> > > of >> > > > the 2 expected exceptions. Generally this falls into 2 discrete >> > > categories: >> > > > >> > > > >> > > > 1. JPA expects a PersistenceException and we have historically >> > thrown >> > > > a HibernateException >> > > > 2. JPA expects some form of JDK RuntimeException >> > > > (IllegalArgumentException, IllegalStateException, etc) and we have >> > > > historically thrown a HibernateException >> > > > >> > > > It is unfortunate that Java does not allow exceptions to be defined >> by >> > > > means of interfaces; that's the only "clean" way I see to do this - >> > that >> > > > would have allowed us to define concrete exception classes that >> extend >> > > > PersistenceException, IllegalArgumentException, etc and that >> implement >> > > HibernateException. >> > > > >> > > > >> > > > So I see 3 potential solutions (feel free to bring up others). >> > > > >> > > > 1. Just move to JPA expected exceptions. >> > > > 2. Have HibernateException extend PersistenceException and just >> not >> > > > worry about the change in expectation in regards to that second >> > > category. >> > > > 3. Push exception handling behind a strategy. This would have to >> > be a >> > > > pretty specific strategy for very specific cases. >> > > > >> > > > The first and second options are pretty self-explanatory and >> > > > straight-forward so I won't go into detail there. Just realize that >> > > these >> > > > change the expectation for the user. They'd have to change their >> code >> > to >> > > > catch these JPA-defined exceptions. >> > > > The other option, I see, is to h >> > > > >> > > > The third option is perfect in theory, but it is very tedious. For >> > > > example, take the case of trying to perform some operation on a >> closed >> > > > Session/EntityManager. Hibernate historically threw a >> > HibernateException >> > > > here. JPA says that should result in an IllegalStateException. So >> in >> > > > SessionImpl#checkOpen, when the Session/EntityManager is closed, we'd >> > > > call out to the strategy to handle that condition. Even more, >> > Hibernate >> > > > (historically) and JPA disagree about which methods getting called >> on a >> > > > closed Session/EntityManager should lead to an exception. For >> example, >> > > > JPA says calling EntityManager#close on a closed EntityManager should >> > > > result in an exception; Hibernate historically did not care if you >> > called >> > > > Session#close on a closed Session. So that is a special case, and >> > every >> > > > one of those special cases would have to be exposed and handled in >> the >> > > > exception handling strategy in additional to the general cases. >> > > > >> > > > Another change in expectation is in regards to operations outside of >> a >> > > > transaction, which I consider a questionable pattern anyway. >> Hibernate >> > > > historically allowed that; JPA explicitly disallows it. In a way >> this >> > > > could fall under the exception discussion above, meaning we could >> push >> > > that >> > > > distinction behind the exception handling strategy. Or we could >> decide >> > > > that we are going to stop supporting that. >> > > > >> > > > There are a lot of other highly questionable things I have seen in >> the >> > > > tests that JPA explicitly disallows that I think we ought to just >> stop >> > > > supporting and opt for the JPA way, although I am open to discussing >> > them >> > > > if any feels strongly about them. Some of these include: >> > > > >> > > > - Asking a Session if is contains >> (Session/EntityManager#contains) a >> > > > non-entity. Hibernate historically would just return false. JPA >> > > states >> > > > that should be an exception. >> > > > - Accessing Session/EntityManager#getTransaction. JPA says that >> is >> > > > only allowed for JDBC transactions. Hibernate always allows it. >> > > > >> > > > If we go the route of an "exception handling strategy" a lot of the >> > other >> > > > points I mentioned above could just be pushed behind that strategy. >> > But >> > > I >> > > > really want to start looking critically at what we support today that >> > we >> > > > maybe really should not be. >> > > > >> > > _______________________________________________ >> > > 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 Mon Apr 25 07:57:12 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Apr 2016 12:57:12 +0100 Subject: [hibernate-dev] [HSEARCH] Usage of ShardIdentifierProvider In-Reply-To: References: Message-ID: On 24 April 2016 at 19:00, Gunnar Morling wrote: > > > 2016-04-22 12:55 GMT+02:00 Sanne Grinovero : >> >> On 21 April 2016 at 18:35, Gunnar Morling wrote: >> > Hi, >> > >> > As IndexShardingStrategy is deprecated, I thought I'd use >> > ShardIdentifierProvider and friends in new code I write. It's not clear >> > to >> > me though, how it's meant to be used. >> > >> > Some questions: >> > >> > * Is it correct that EntityIndexBinding#getShardIdentifierProvider() >> > returns null is sharding is not used for this entity? >> >> Yes, as the javadoc suggests. > > > Ok, thanks; The current comment is rather vague, it should more clearly > state when the return value will be null. > >> I don't like to return "null"s so if >> >> > I suppose in that >> > case I simply can use EntityIndexBinding.getIndexManagers()[0]? >> >> I'm not understanding how this related to the previous question. What >> are you up to? > > > E.g. look at DefaultBatchBackend. Working on improving batch performance for > the ES backend, I came across the deprecation of IndexShardingStrategy and > wondered what it'd take to get rid of that. > >> N.B. the intent of the sharding strategies is not to give end users a >> reference to the IndexManagers. >> So the `ShardIdentifierProvider` contract lets people identify the >> target indexes by naming them. > > > The deprecation comment on IndexShardingStrategy says "Use > ShardIdentifierProvider instead". Are you saying that this cannot be done > actually? That's what I tried: "use SIP" and from the shard name obtain an > index manager. But your next comment below makes me wonder whether that's > actually desirable. >> >> >> > * What's the envisioned way to get the IM for a given shard once I know >> > the >> > shard id? I found IndexManagerHolder.getOrCreateIndexManager(), but this >> > expects a *DynamicSharding*EntityIndexBinding, so how would it work for >> > non-dynamic sharding? >> >> The envisioned way is that the user doesn't get a reference to the >> IndexManager, >> what he needs is to identify the indexes - not act on them. > > > See above. I'm confused by the deprecation comment on IndexShardingStrategy. > Right now I don't see how ShardIdentifierProvider can be used instead. >> >> >> > >> > It's tough to see how the pieces are meant to fit together, now that >> > IndexShardingStrategy and ShardIdentifierProvider are there. I hope we >> > can >> > get rid of the former soon, simplifying the code a bit? >> >> Yes. It has been deprecated for long enough, we could give a shot of >> removing the old one if this helps something you're doing? >> >> I wouldn't remove it yet if it's not in the way of our 5.6 requirements. >> >> BTW the contract "IndexShardingStrategy" is deprecated so that users >> of sharding move to the new API, but that interface still is the >> foundation of the implementation even for dynamic sharding.. it's not >> being removed from internals. > > > Aaah, so are you saying that IndexShardingStrategy is only deprecated for > use by Hibernate Search users, but internally it's not meant to go away? > I.e. it'll just be removed from the public API but will continue to exist in > some "impl" package? > > If so, some more explicit comment about the nature of this deprecation would > help :) I don't think this was clear when we decided that dynamic sharding would need to hide references to IndexManager instances from the user's sharding strategy code; discussions back then were focusing on user experience and API. I just came to this conclusion when looking at how we use the contract internally, from a point of view of trying to guess what your questions were aiming at :) So to conclude: - yes it's deprecated for end users: you *may* move/remove it now if that helps with your goals - it's not necessarily going away as long as it's a useful abstraction for our own internal purposes Personally I'd not fully remove it: an IndexShardingStrategy interface is a fitting name for the concept, I'd avoid in future to have this imply anything about its details such as dynamic vs static sharding though. It is currently bound to the "static sharding" concept from historical reasons. --Sanne > >> >> The new contract just enables us to add new shards dynamically, but >> you can see this also as a removal of the previous limitation. The >> high level concept can keep the generic name "index sharding strategy" >> as it's still fitting. >> >> You can see this as a plan to not have users to choose between two >> ways to express the same thing. >> >> Thanks, >> Sanne >> >> > >> > Thanks, >> > >> > --Gunnar >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > From mihalcea.vlad at gmail.com Mon Apr 25 08:44:17 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Mon, 25 Apr 2016 15:44:17 +0300 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Hi Mincong, Welcome and enjoy the GSoC! Vlad On Mon, Apr 25, 2016 at 10:07 AM, Mincong Huang wrote: > Hi Gunnar, > > Thanks you and everybody in hibernate-dev. So glad to join you :) > > Before the action begins, here're some progress I've done in these weeks : > > - Built a simple Apache Lucene example to understand how index and > search works > - Built a simple Hibernate Search example to understand how to transfer > a simple lucene query (keyword, fuzzy, wildcard query) into > FullTextQuery > using FullTextEntityManager and JPA > - Contributed to HSEARCH-2207 > : Treat > BooleanQuery as an immutable Query > - Ran some batch examples on WildFly 10.0. (examples found at > github.com/javaee-samples/javaee7-samples) > - Building a simple batch example containing reader, processor, writer > and a checkpoint algorithm. This one is still in progress, because I > didn't > found ways to break the batch job, and then test the checkpoint. > > Cheers, > Mincong > > On Sat, Apr 23, 2016 at 10:39 AM, Gunnar Morling > wrote: > > > Hi Mincong, > > > > Congrats and welcome to this year's GSoC! Looking forward to the project > > and your contributions very much! > > > > @Everyone: Please join me in welcoming Mincong to the team! He is a > > student living in France and as part of Google Summer of Code he will be > > working on an alternative for mass indexing entities in Hibernate Search > > based on the JSR 352 for batch applications (see [1] for the project > > proposal). I'll be mentoring him. > > > > @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend > > before the action begins and then let's get a discussion on the details > > started. > > > > Onwards, > > > > --Gunnar > > > > [1] https://summerofcode.withgoogle.com/serve/5594702887780352/ > > > > > > > > 2016-04-22 23:20 GMT+02:00 Mincong Huang : > > > >> Hi everybody, > >> > >> Thanks for accepting my application of GSoC !! Really excited to having > >> chance to work the hibernate team. I'm so happy to see this email. It's > >> just > >> like a dream, can't believe it is true !! Thanks for choosing me. I'll > >> try my > >> best to accomplish this mission !! Happy coding and good night :-) > >> > >> Cheers, > >> Mincong > >> > >> On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < > >> summerofcode-noreply at google.com> wrote: > >> > >>> [image: Google Summer of Code] > >>> > >>> Hi mincongh, > >>> > >>> Welcome to GSoC 2016! > >>> > >>> Your proposal Hibernate Search: JSR 352 batch job for re-indexing > >>> entities > >>> < > https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/ > > > >>> has been accepted! > >>> > >>> We look forward to seeing the great things you will accomplish this > >>> summer with JBoss Community. > >>> > >>> This email contains important information about your participation in > >>> GSoC this year. Please read it carefully. > >>> > >>> Over the next month you will take part in the Community Bonding period > >>> with your organization. This period is for you to become familiar with > the > >>> organization's code base, version control and other infrastructure. You > >>> will be getting to know the community and its practices, as well as > working > >>> with your mentor on milestones for the summer. > >>> > >>> Complete all of these steps as soon as you can: > >>> > >>> 1. Read the Accepted Student Information > >>> < > https://developers.google.com/open-source/gsoc/help/accepted-students> > >>> 2. Upload your tax > >>> form *before May 16, 2016 at 19:00 UTC* > >>> 3. Read the Student Payment Information > >>> > >>> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC > >>> 5. Verify your shipping address, promotional materials, and t-shirt > >>> information on your profile > >>> . > >>> > >>> If you have questions about anything in this email, please email the > >>> Google GSoC support team at gsoc-support at google.com. Don?t email the > >>> student list with tax or payment issues. > >>> > >>> Have a great summer! > >>> > >>> Google Open Source Programs team > >>> > >>> This email was sent to mincong.h at gmail.com. > >>> > >>> You are receiving this email because of your participation in Google > >>> Summer of Code 2016. > >>> https://summerofcode.withgoogle.com > >>> > >>> To leave the program and stop receiving all emails, you can go to your > >>> profile and > >>> request deletion of your program profile. > >>> > >>> For any questions, please contact gsoc-support at google.com. Replies to > >>> this message go to an unmonitored mailbox. > >>> > >>> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, > >>> USA > >>> > >> > >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From steve at hibernate.org Mon Apr 25 10:25:14 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 25 Apr 2016 14:25:14 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: I agree with Gunnar in that the underlying question here is in how we see the "Hibernate API" long term. However I would consider the following categories: 1. Methods which are Hibernate-only 2. Methods which Hibernate had historically which share a signature with JPA 3. Methods which we added to Hibernate specifically for JPA. Personally, in retrospect, I would say that group (3) unequivocally should have been handled by just throwing the JPA exceptions. In a clean-room impl that's what I would do. So I guess the question is whether we want to look at this as a clean-room impl or if we want to constrain ourselves to the legacy exception types. I do wonder if a hybrid approach may be the best, as touched on before. Namely, where JPA expects an IllegalArgumentException, IllegalStateException, etc we throw those; for the rest we'd have Hibernate exception extend PersistenceException. I think that's a great compromise. I'd also mention that in the IllegalArgumentException, IllegalStateException, etc cases there are a few places where HibernateExceptions cover the JPA case already. E.g. JPA says that if there is a problem with the JPQL query (String) used to create a Query an IllegalArgumentException should be thrown; Hibernate currently handles this by throwing a QuerySyntaxException - we could just make QuerySyntaxException extend from IllegalArgumentException rather than Hibernate's HibernateException hierarchy. I think the bottom line is that having Session and EntityManager split before caused all kinds of difficult-to-debug complexity that I'd rather avoid as we consolidate them together. On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero wrote: > Gunnar's words seem wise to me: users will need to have the JPA API on > classpath anyway, so I don't see why we should have - and maintain - > strategies for different kind of exceptions. > > This might have been useful in the past, but looking forward? > > If the reasoning is that Hibernate - having more features - could > throw more specific and informative exceptions, we could have some > Hibernate exceptions to subclass the JPA ones? > > Would be nice to avoid breaking the expected exception types in a > minor, so I'm not sure if you can do that in all cases by subclassing > the JPA ones, but I suspect it can get you a long way. > > > On 25 April 2016 at 10:13, Gunnar Morling wrote: > > The strategy approach sounds nice on first thought, but it also adds > > complexity. > > > > I think the underlying question is: What's the long-term strategy around > > the "Classic API"? Should it remain in place for all times as a complete > > alternative to the JPA API? > > > > Or should we begin to deprecate it and narrow it down in favour of the > > corresponding functionality standardized in JPA, and only functionality > not > > present in JPA would be exposed through some kind of unwrap()? > > > > Without having thought about all the implications too much, I'd lean > > towards the latter, in which case I vote for "1. Just move to JPA > expected > > exceptions" as part of such larger effort. > > > > It'd be interesting to run a poll to see some figures of people using > > classic vs. JPA. > > > > --Gunnar > > > > > > > > 2016-04-25 10:47 GMT+02:00 andrea boriero : > > > >> Having a Strategy gives us more flexibility so +1. > >> > >> About the expectations I think what Vlad says is reasonable. > >> > >> On 25 April 2016 at 06:04, Vlad Mihalcea > wrote: > >> > >> > Your second email summarizes my thoughts as well. If we can separate > the > >> > exception handling in two separate strategies that are defined during > >> > bootstrap (JPA vs Hibernate), > >> > I think that's the way to go. > >> > > >> > There so many projects out there that rely on the exception type being > >> > thrown, and changing those would make it very difficult for them to > >> migrate > >> > to this new version. > >> > But that only affects Hibernate-native projects since, for those who > have > >> > been using JPA, they already expect the JPA exceptions anyway. > >> > > >> > As for the other behavior discrepancies: > >> > > >> > 1. "calling EntityManager#close on a closed EntityManager should > result > >> in > >> > an > >> > exception;" - that's a reasonable default and shouldn't cause too much > >> > trouble. > >> > 2. "Another change in expectation is in regards to operations outside > of > >> a > >> > transaction" - in JPA we can execute queries outside a transaction, > but > >> any > >> > write will fail if there is no transactional context, which is > reasonable > >> > for me too. If Hibernate allows writes outside of a transactional > >> context, > >> > that's definitely a thing we should not support anyway. > >> > 3. "Asking a Session if is contains (Session/EntityManager#contains) a > >> > non-entity" - we can handle this with the separate exception handler > >> > strategies to retain both JPA and Hibernate behaviors. > >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is > >> > only allowed > >> > for JDBC transactions. Hibernate always allows it." - I'd choose the > >> > Hibernate behavior because I don;t see how it can cause any issue and > >> it's > >> > an enhancement as well. > >> > > >> > Vlad > >> > > >> > > >> > > >> > > >> > > >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole > >> > wrote: > >> > > >> > > Just realized that I should have mentioned an important plan that > helps > >> > > understand the idea behind the "exception handling strategy" > route. I > >> > plan > >> > > to keep track of how a SessionFactory was bootstrapped in some > fashion. > >> > So > >> > > when it was bootstrapped from EntityManagerFactoryBuilder (which JPA > >> > > bootstrap methods leverage) we'd select the "JPA exception handling" > >> > > strategy impl. When not, we'd use the "legacy Hibernate exception > >> > > handling" strategy. > >> > > > >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole > > >> > > wrote: > >> > > > >> > > > There are a number of "expectation changes" that come about from > >> > > > consolidating hibernate-entitymanger into hibernate-core. Some we > >> have > >> > > > discussed; some we have not. Hopefully we can come to a consensus > >> > > regards > >> > > > how to deal with these changes... > >> > > > > >> > > > The first one is different exception types. We have discussed > this > >> > > > before. For now, in an effort to fix test failures and move > forward > >> > with > >> > > > developing, I simply changed failing tests to expect the JPA > defined > >> > > > exceptions. I had mentioned, where possible, to to throw a > >> combination > >> > > of > >> > > > the 2 expected exceptions. Generally this falls into 2 discrete > >> > > categories: > >> > > > > >> > > > > >> > > > 1. JPA expects a PersistenceException and we have historically > >> > thrown > >> > > > a HibernateException > >> > > > 2. JPA expects some form of JDK RuntimeException > >> > > > (IllegalArgumentException, IllegalStateException, etc) and we > have > >> > > > historically thrown a HibernateException > >> > > > > >> > > > It is unfortunate that Java does not allow exceptions to be > defined > >> by > >> > > > means of interfaces; that's the only "clean" way I see to do this > - > >> > that > >> > > > would have allowed us to define concrete exception classes that > >> extend > >> > > > PersistenceException, IllegalArgumentException, etc and that > >> implement > >> > > HibernateException. > >> > > > > >> > > > > >> > > > So I see 3 potential solutions (feel free to bring up others). > >> > > > > >> > > > 1. Just move to JPA expected exceptions. > >> > > > 2. Have HibernateException extend PersistenceException and just > >> not > >> > > > worry about the change in expectation in regards to that second > >> > > category. > >> > > > 3. Push exception handling behind a strategy. This would have > to > >> > be a > >> > > > pretty specific strategy for very specific cases. > >> > > > > >> > > > The first and second options are pretty self-explanatory and > >> > > > straight-forward so I won't go into detail there. Just realize > that > >> > > these > >> > > > change the expectation for the user. They'd have to change their > >> code > >> > to > >> > > > catch these JPA-defined exceptions. > >> > > > The other option, I see, is to h > >> > > > > >> > > > The third option is perfect in theory, but it is very tedious. > For > >> > > > example, take the case of trying to perform some operation on a > >> closed > >> > > > Session/EntityManager. Hibernate historically threw a > >> > HibernateException > >> > > > here. JPA says that should result in an IllegalStateException. > So > >> in > >> > > > SessionImpl#checkOpen, when the Session/EntityManager is closed, > we'd > >> > > > call out to the strategy to handle that condition. Even more, > >> > Hibernate > >> > > > (historically) and JPA disagree about which methods getting called > >> on a > >> > > > closed Session/EntityManager should lead to an exception. For > >> example, > >> > > > JPA says calling EntityManager#close on a closed EntityManager > should > >> > > > result in an exception; Hibernate historically did not care if you > >> > called > >> > > > Session#close on a closed Session. So that is a special case, and > >> > every > >> > > > one of those special cases would have to be exposed and handled in > >> the > >> > > > exception handling strategy in additional to the general cases. > >> > > > > >> > > > Another change in expectation is in regards to operations outside > of > >> a > >> > > > transaction, which I consider a questionable pattern anyway. > >> Hibernate > >> > > > historically allowed that; JPA explicitly disallows it. In a way > >> this > >> > > > could fall under the exception discussion above, meaning we could > >> push > >> > > that > >> > > > distinction behind the exception handling strategy. Or we could > >> decide > >> > > > that we are going to stop supporting that. > >> > > > > >> > > > There are a lot of other highly questionable things I have seen in > >> the > >> > > > tests that JPA explicitly disallows that I think we ought to just > >> stop > >> > > > supporting and opt for the JPA way, although I am open to > discussing > >> > them > >> > > > if any feels strongly about them. Some of these include: > >> > > > > >> > > > - Asking a Session if is contains > >> (Session/EntityManager#contains) a > >> > > > non-entity. Hibernate historically would just return false. > JPA > >> > > states > >> > > > that should be an exception. > >> > > > - Accessing Session/EntityManager#getTransaction. JPA says > that > >> is > >> > > > only allowed for JDBC transactions. Hibernate always allows > it. > >> > > > > >> > > > If we go the route of an "exception handling strategy" a lot of > the > >> > other > >> > > > points I mentioned above could just be pushed behind that > strategy. > >> > But > >> > > I > >> > > > really want to start looking critically at what we support today > that > >> > we > >> > > > maybe really should not be. > >> > > > > >> > > _______________________________________________ > >> > > 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 Mon Apr 25 10:52:04 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Apr 2016 15:52:04 +0100 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: N.B. that chancing the exception types thrown by our native methods is an API change in my opinion. So while I think you can have some Hibernate exceptions now extend some of the types expected by JPA, a fully "clean room" approach is not something I'd do in a minor release. On 25 April 2016 at 15:25, Steve Ebersole wrote: > I agree with Gunnar in that the underlying question here is in how we see > the "Hibernate API" long term. However I would consider the following > categories: > > Methods which are Hibernate-only > Methods which Hibernate had historically which share a signature with JPA > Methods which we added to Hibernate specifically for JPA. > > > Personally, in retrospect, I would say that group (3) unequivocally should > have been handled by just throwing the JPA exceptions. In a clean-room impl > that's what I would do. > > So I guess the question is whether we want to look at this as a clean-room > impl or if we want to constrain ourselves to the legacy exception types. I > do wonder if a hybrid approach may be the best, as touched on before. > Namely, where JPA expects an IllegalArgumentException, > IllegalStateException, etc we throw those; for the rest we'd have Hibernate > exception extend PersistenceException. I think that's a great compromise. > > I'd also mention that in the IllegalArgumentException, > IllegalStateException, etc cases there are a few places where > HibernateExceptions cover the JPA case already. E.g. JPA says that if there > is a problem with the JPQL query (String) used to create a Query an > IllegalArgumentException should be thrown; Hibernate currently handles this > by throwing a QuerySyntaxException - we could just make QuerySyntaxException > extend from IllegalArgumentException rather than Hibernate's > HibernateException hierarchy. > > I think the bottom line is that having Session and EntityManager split > before caused all kinds of difficult-to-debug complexity that I'd rather > avoid as we consolidate them together. > > > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero wrote: >> >> Gunnar's words seem wise to me: users will need to have the JPA API on >> classpath anyway, so I don't see why we should have - and maintain - >> strategies for different kind of exceptions. >> >> This might have been useful in the past, but looking forward? >> >> If the reasoning is that Hibernate - having more features - could >> throw more specific and informative exceptions, we could have some >> Hibernate exceptions to subclass the JPA ones? >> >> Would be nice to avoid breaking the expected exception types in a >> minor, so I'm not sure if you can do that in all cases by subclassing >> the JPA ones, but I suspect it can get you a long way. >> >> >> On 25 April 2016 at 10:13, Gunnar Morling wrote: >> > The strategy approach sounds nice on first thought, but it also adds >> > complexity. >> > >> > I think the underlying question is: What's the long-term strategy around >> > the "Classic API"? Should it remain in place for all times as a complete >> > alternative to the JPA API? >> > >> > Or should we begin to deprecate it and narrow it down in favour of the >> > corresponding functionality standardized in JPA, and only functionality >> > not >> > present in JPA would be exposed through some kind of unwrap()? >> > >> > Without having thought about all the implications too much, I'd lean >> > towards the latter, in which case I vote for "1. Just move to JPA >> > expected >> > exceptions" as part of such larger effort. >> > >> > It'd be interesting to run a poll to see some figures of people using >> > classic vs. JPA. >> > >> > --Gunnar >> > >> > >> > >> > 2016-04-25 10:47 GMT+02:00 andrea boriero : >> > >> >> Having a Strategy gives us more flexibility so +1. >> >> >> >> About the expectations I think what Vlad says is reasonable. >> >> >> >> On 25 April 2016 at 06:04, Vlad Mihalcea >> >> wrote: >> >> >> >> > Your second email summarizes my thoughts as well. If we can separate >> >> > the >> >> > exception handling in two separate strategies that are defined during >> >> > bootstrap (JPA vs Hibernate), >> >> > I think that's the way to go. >> >> > >> >> > There so many projects out there that rely on the exception type >> >> > being >> >> > thrown, and changing those would make it very difficult for them to >> >> migrate >> >> > to this new version. >> >> > But that only affects Hibernate-native projects since, for those who >> >> > have >> >> > been using JPA, they already expect the JPA exceptions anyway. >> >> > >> >> > As for the other behavior discrepancies: >> >> > >> >> > 1. "calling EntityManager#close on a closed EntityManager should >> >> > result >> >> in >> >> > an >> >> > exception;" - that's a reasonable default and shouldn't cause too >> >> > much >> >> > trouble. >> >> > 2. "Another change in expectation is in regards to operations outside >> >> > of >> >> a >> >> > transaction" - in JPA we can execute queries outside a transaction, >> >> > but >> >> any >> >> > write will fail if there is no transactional context, which is >> >> > reasonable >> >> > for me too. If Hibernate allows writes outside of a transactional >> >> context, >> >> > that's definitely a thing we should not support anyway. >> >> > 3. "Asking a Session if is contains (Session/EntityManager#contains) >> >> > a >> >> > non-entity" - we can handle this with the separate exception handler >> >> > strategies to retain both JPA and Hibernate behaviors. >> >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is >> >> > only allowed >> >> > for JDBC transactions. Hibernate always allows it." - I'd choose the >> >> > Hibernate behavior because I don;t see how it can cause any issue and >> >> it's >> >> > an enhancement as well. >> >> > >> >> > Vlad >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole >> >> > wrote: >> >> > >> >> > > Just realized that I should have mentioned an important plan that >> >> > > helps >> >> > > understand the idea behind the "exception handling strategy" route. >> >> > > I >> >> > plan >> >> > > to keep track of how a SessionFactory was bootstrapped in some >> >> > > fashion. >> >> > So >> >> > > when it was bootstrapped from EntityManagerFactoryBuilder (which >> >> > > JPA >> >> > > bootstrap methods leverage) we'd select the "JPA exception >> >> > > handling" >> >> > > strategy impl. When not, we'd use the "legacy Hibernate exception >> >> > > handling" strategy. >> >> > > >> >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole >> >> > > >> >> > > wrote: >> >> > > >> >> > > > There are a number of "expectation changes" that come about from >> >> > > > consolidating hibernate-entitymanger into hibernate-core. Some >> >> > > > we >> >> have >> >> > > > discussed; some we have not. Hopefully we can come to a >> >> > > > consensus >> >> > > regards >> >> > > > how to deal with these changes... >> >> > > > >> >> > > > The first one is different exception types. We have discussed >> >> > > > this >> >> > > > before. For now, in an effort to fix test failures and move >> >> > > > forward >> >> > with >> >> > > > developing, I simply changed failing tests to expect the JPA >> >> > > > defined >> >> > > > exceptions. I had mentioned, where possible, to to throw a >> >> combination >> >> > > of >> >> > > > the 2 expected exceptions. Generally this falls into 2 discrete >> >> > > categories: >> >> > > > >> >> > > > >> >> > > > 1. JPA expects a PersistenceException and we have historically >> >> > thrown >> >> > > > a HibernateException >> >> > > > 2. JPA expects some form of JDK RuntimeException >> >> > > > (IllegalArgumentException, IllegalStateException, etc) and we >> >> > > > have >> >> > > > historically thrown a HibernateException >> >> > > > >> >> > > > It is unfortunate that Java does not allow exceptions to be >> >> > > > defined >> >> by >> >> > > > means of interfaces; that's the only "clean" way I see to do this >> >> > > > - >> >> > that >> >> > > > would have allowed us to define concrete exception classes that >> >> extend >> >> > > > PersistenceException, IllegalArgumentException, etc and that >> >> implement >> >> > > HibernateException. >> >> > > > >> >> > > > >> >> > > > So I see 3 potential solutions (feel free to bring up others). >> >> > > > >> >> > > > 1. Just move to JPA expected exceptions. >> >> > > > 2. Have HibernateException extend PersistenceException and >> >> > > > just >> >> not >> >> > > > worry about the change in expectation in regards to that >> >> > > > second >> >> > > category. >> >> > > > 3. Push exception handling behind a strategy. This would have >> >> > > > to >> >> > be a >> >> > > > pretty specific strategy for very specific cases. >> >> > > > >> >> > > > The first and second options are pretty self-explanatory and >> >> > > > straight-forward so I won't go into detail there. Just realize >> >> > > > that >> >> > > these >> >> > > > change the expectation for the user. They'd have to change their >> >> code >> >> > to >> >> > > > catch these JPA-defined exceptions. >> >> > > > The other option, I see, is to h >> >> > > > >> >> > > > The third option is perfect in theory, but it is very tedious. >> >> > > > For >> >> > > > example, take the case of trying to perform some operation on a >> >> closed >> >> > > > Session/EntityManager. Hibernate historically threw a >> >> > HibernateException >> >> > > > here. JPA says that should result in an IllegalStateException. >> >> > > > So >> >> in >> >> > > > SessionImpl#checkOpen, when the Session/EntityManager is closed, >> >> > > > we'd >> >> > > > call out to the strategy to handle that condition. Even more, >> >> > Hibernate >> >> > > > (historically) and JPA disagree about which methods getting >> >> > > > called >> >> on a >> >> > > > closed Session/EntityManager should lead to an exception. For >> >> example, >> >> > > > JPA says calling EntityManager#close on a closed EntityManager >> >> > > > should >> >> > > > result in an exception; Hibernate historically did not care if >> >> > > > you >> >> > called >> >> > > > Session#close on a closed Session. So that is a special case, >> >> > > > and >> >> > every >> >> > > > one of those special cases would have to be exposed and handled >> >> > > > in >> >> the >> >> > > > exception handling strategy in additional to the general cases. >> >> > > > >> >> > > > Another change in expectation is in regards to operations outside >> >> > > > of >> >> a >> >> > > > transaction, which I consider a questionable pattern anyway. >> >> Hibernate >> >> > > > historically allowed that; JPA explicitly disallows it. In a way >> >> this >> >> > > > could fall under the exception discussion above, meaning we could >> >> push >> >> > > that >> >> > > > distinction behind the exception handling strategy. Or we could >> >> decide >> >> > > > that we are going to stop supporting that. >> >> > > > >> >> > > > There are a lot of other highly questionable things I have seen >> >> > > > in >> >> the >> >> > > > tests that JPA explicitly disallows that I think we ought to just >> >> stop >> >> > > > supporting and opt for the JPA way, although I am open to >> >> > > > discussing >> >> > them >> >> > > > if any feels strongly about them. Some of these include: >> >> > > > >> >> > > > - Asking a Session if is contains >> >> (Session/EntityManager#contains) a >> >> > > > non-entity. Hibernate historically would just return false. >> >> > > > JPA >> >> > > states >> >> > > > that should be an exception. >> >> > > > - Accessing Session/EntityManager#getTransaction. JPA says >> >> > > > that >> >> is >> >> > > > only allowed for JDBC transactions. Hibernate always allows >> >> > > > it. >> >> > > > >> >> > > > If we go the route of an "exception handling strategy" a lot of >> >> > > > the >> >> > other >> >> > > > points I mentioned above could just be pushed behind that >> >> > > > strategy. >> >> > But >> >> > > I >> >> > > > really want to start looking critically at what we support today >> >> > > > that >> >> > we >> >> > > > maybe really should not be. >> >> > > > >> >> > > _______________________________________________ >> >> > > 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 steve at hibernate.org Mon Apr 25 11:28:49 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 25 Apr 2016 15:28:49 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: I agree with that to an extent. However there is also a balance - clearly any added complexity has a direct correlation to likelihood of errors/bugs. We just have to find that balance :) On Mon, Apr 25, 2016 at 9:52 AM Sanne Grinovero wrote: > N.B. that chancing the exception types thrown by our native methods is > an API change in my opinion. > > So while I think you can have some Hibernate exceptions now extend > some of the types expected by JPA, a fully "clean room" approach is > not something I'd do in a minor release. > > On 25 April 2016 at 15:25, Steve Ebersole wrote: > > I agree with Gunnar in that the underlying question here is in how we see > > the "Hibernate API" long term. However I would consider the following > > categories: > > > > Methods which are Hibernate-only > > Methods which Hibernate had historically which share a signature with JPA > > Methods which we added to Hibernate specifically for JPA. > > > > > > Personally, in retrospect, I would say that group (3) unequivocally > should > > have been handled by just throwing the JPA exceptions. In a clean-room > impl > > that's what I would do. > > > > So I guess the question is whether we want to look at this as a > clean-room > > impl or if we want to constrain ourselves to the legacy exception > types. I > > do wonder if a hybrid approach may be the best, as touched on before. > > Namely, where JPA expects an IllegalArgumentException, > > IllegalStateException, etc we throw those; for the rest we'd have > Hibernate > > exception extend PersistenceException. I think that's a great > compromise. > > > > I'd also mention that in the IllegalArgumentException, > > IllegalStateException, etc cases there are a few places where > > HibernateExceptions cover the JPA case already. E.g. JPA says that if > there > > is a problem with the JPQL query (String) used to create a Query an > > IllegalArgumentException should be thrown; Hibernate currently handles > this > > by throwing a QuerySyntaxException - we could just make > QuerySyntaxException > > extend from IllegalArgumentException rather than Hibernate's > > HibernateException hierarchy. > > > > I think the bottom line is that having Session and EntityManager split > > before caused all kinds of difficult-to-debug complexity that I'd rather > > avoid as we consolidate them together. > > > > > > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero > wrote: > >> > >> Gunnar's words seem wise to me: users will need to have the JPA API on > >> classpath anyway, so I don't see why we should have - and maintain - > >> strategies for different kind of exceptions. > >> > >> This might have been useful in the past, but looking forward? > >> > >> If the reasoning is that Hibernate - having more features - could > >> throw more specific and informative exceptions, we could have some > >> Hibernate exceptions to subclass the JPA ones? > >> > >> Would be nice to avoid breaking the expected exception types in a > >> minor, so I'm not sure if you can do that in all cases by subclassing > >> the JPA ones, but I suspect it can get you a long way. > >> > >> > >> On 25 April 2016 at 10:13, Gunnar Morling wrote: > >> > The strategy approach sounds nice on first thought, but it also adds > >> > complexity. > >> > > >> > I think the underlying question is: What's the long-term strategy > around > >> > the "Classic API"? Should it remain in place for all times as a > complete > >> > alternative to the JPA API? > >> > > >> > Or should we begin to deprecate it and narrow it down in favour of the > >> > corresponding functionality standardized in JPA, and only > functionality > >> > not > >> > present in JPA would be exposed through some kind of unwrap()? > >> > > >> > Without having thought about all the implications too much, I'd lean > >> > towards the latter, in which case I vote for "1. Just move to JPA > >> > expected > >> > exceptions" as part of such larger effort. > >> > > >> > It'd be interesting to run a poll to see some figures of people using > >> > classic vs. JPA. > >> > > >> > --Gunnar > >> > > >> > > >> > > >> > 2016-04-25 10:47 GMT+02:00 andrea boriero : > >> > > >> >> Having a Strategy gives us more flexibility so +1. > >> >> > >> >> About the expectations I think what Vlad says is reasonable. > >> >> > >> >> On 25 April 2016 at 06:04, Vlad Mihalcea > >> >> wrote: > >> >> > >> >> > Your second email summarizes my thoughts as well. If we can > separate > >> >> > the > >> >> > exception handling in two separate strategies that are defined > during > >> >> > bootstrap (JPA vs Hibernate), > >> >> > I think that's the way to go. > >> >> > > >> >> > There so many projects out there that rely on the exception type > >> >> > being > >> >> > thrown, and changing those would make it very difficult for them to > >> >> migrate > >> >> > to this new version. > >> >> > But that only affects Hibernate-native projects since, for those > who > >> >> > have > >> >> > been using JPA, they already expect the JPA exceptions anyway. > >> >> > > >> >> > As for the other behavior discrepancies: > >> >> > > >> >> > 1. "calling EntityManager#close on a closed EntityManager should > >> >> > result > >> >> in > >> >> > an > >> >> > exception;" - that's a reasonable default and shouldn't cause too > >> >> > much > >> >> > trouble. > >> >> > 2. "Another change in expectation is in regards to operations > outside > >> >> > of > >> >> a > >> >> > transaction" - in JPA we can execute queries outside a transaction, > >> >> > but > >> >> any > >> >> > write will fail if there is no transactional context, which is > >> >> > reasonable > >> >> > for me too. If Hibernate allows writes outside of a transactional > >> >> context, > >> >> > that's definitely a thing we should not support anyway. > >> >> > 3. "Asking a Session if is contains > (Session/EntityManager#contains) > >> >> > a > >> >> > non-entity" - we can handle this with the separate exception > handler > >> >> > strategies to retain both JPA and Hibernate behaviors. > >> >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says that > is > >> >> > only allowed > >> >> > for JDBC transactions. Hibernate always allows it." - I'd choose > the > >> >> > Hibernate behavior because I don;t see how it can cause any issue > and > >> >> it's > >> >> > an enhancement as well. > >> >> > > >> >> > Vlad > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole < > steve at hibernate.org> > >> >> > wrote: > >> >> > > >> >> > > Just realized that I should have mentioned an important plan that > >> >> > > helps > >> >> > > understand the idea behind the "exception handling strategy" > route. > >> >> > > I > >> >> > plan > >> >> > > to keep track of how a SessionFactory was bootstrapped in some > >> >> > > fashion. > >> >> > So > >> >> > > when it was bootstrapped from EntityManagerFactoryBuilder (which > >> >> > > JPA > >> >> > > bootstrap methods leverage) we'd select the "JPA exception > >> >> > > handling" > >> >> > > strategy impl. When not, we'd use the "legacy Hibernate > exception > >> >> > > handling" strategy. > >> >> > > > >> >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole > >> >> > > > >> >> > > wrote: > >> >> > > > >> >> > > > There are a number of "expectation changes" that come about > from > >> >> > > > consolidating hibernate-entitymanger into hibernate-core. Some > >> >> > > > we > >> >> have > >> >> > > > discussed; some we have not. Hopefully we can come to a > >> >> > > > consensus > >> >> > > regards > >> >> > > > how to deal with these changes... > >> >> > > > > >> >> > > > The first one is different exception types. We have discussed > >> >> > > > this > >> >> > > > before. For now, in an effort to fix test failures and move > >> >> > > > forward > >> >> > with > >> >> > > > developing, I simply changed failing tests to expect the JPA > >> >> > > > defined > >> >> > > > exceptions. I had mentioned, where possible, to to throw a > >> >> combination > >> >> > > of > >> >> > > > the 2 expected exceptions. Generally this falls into 2 > discrete > >> >> > > categories: > >> >> > > > > >> >> > > > > >> >> > > > 1. JPA expects a PersistenceException and we have > historically > >> >> > thrown > >> >> > > > a HibernateException > >> >> > > > 2. JPA expects some form of JDK RuntimeException > >> >> > > > (IllegalArgumentException, IllegalStateException, etc) and > we > >> >> > > > have > >> >> > > > historically thrown a HibernateException > >> >> > > > > >> >> > > > It is unfortunate that Java does not allow exceptions to be > >> >> > > > defined > >> >> by > >> >> > > > means of interfaces; that's the only "clean" way I see to do > this > >> >> > > > - > >> >> > that > >> >> > > > would have allowed us to define concrete exception classes that > >> >> extend > >> >> > > > PersistenceException, IllegalArgumentException, etc and that > >> >> implement > >> >> > > HibernateException. > >> >> > > > > >> >> > > > > >> >> > > > So I see 3 potential solutions (feel free to bring up others). > >> >> > > > > >> >> > > > 1. Just move to JPA expected exceptions. > >> >> > > > 2. Have HibernateException extend PersistenceException and > >> >> > > > just > >> >> not > >> >> > > > worry about the change in expectation in regards to that > >> >> > > > second > >> >> > > category. > >> >> > > > 3. Push exception handling behind a strategy. This would > have > >> >> > > > to > >> >> > be a > >> >> > > > pretty specific strategy for very specific cases. > >> >> > > > > >> >> > > > The first and second options are pretty self-explanatory and > >> >> > > > straight-forward so I won't go into detail there. Just realize > >> >> > > > that > >> >> > > these > >> >> > > > change the expectation for the user. They'd have to change > their > >> >> code > >> >> > to > >> >> > > > catch these JPA-defined exceptions. > >> >> > > > The other option, I see, is to h > >> >> > > > > >> >> > > > The third option is perfect in theory, but it is very tedious. > >> >> > > > For > >> >> > > > example, take the case of trying to perform some operation on a > >> >> closed > >> >> > > > Session/EntityManager. Hibernate historically threw a > >> >> > HibernateException > >> >> > > > here. JPA says that should result in an IllegalStateException. > >> >> > > > So > >> >> in > >> >> > > > SessionImpl#checkOpen, when the Session/EntityManager is > closed, > >> >> > > > we'd > >> >> > > > call out to the strategy to handle that condition. Even more, > >> >> > Hibernate > >> >> > > > (historically) and JPA disagree about which methods getting > >> >> > > > called > >> >> on a > >> >> > > > closed Session/EntityManager should lead to an exception. For > >> >> example, > >> >> > > > JPA says calling EntityManager#close on a closed EntityManager > >> >> > > > should > >> >> > > > result in an exception; Hibernate historically did not care if > >> >> > > > you > >> >> > called > >> >> > > > Session#close on a closed Session. So that is a special case, > >> >> > > > and > >> >> > every > >> >> > > > one of those special cases would have to be exposed and handled > >> >> > > > in > >> >> the > >> >> > > > exception handling strategy in additional to the general cases. > >> >> > > > > >> >> > > > Another change in expectation is in regards to operations > outside > >> >> > > > of > >> >> a > >> >> > > > transaction, which I consider a questionable pattern anyway. > >> >> Hibernate > >> >> > > > historically allowed that; JPA explicitly disallows it. In a > way > >> >> this > >> >> > > > could fall under the exception discussion above, meaning we > could > >> >> push > >> >> > > that > >> >> > > > distinction behind the exception handling strategy. Or we > could > >> >> decide > >> >> > > > that we are going to stop supporting that. > >> >> > > > > >> >> > > > There are a lot of other highly questionable things I have seen > >> >> > > > in > >> >> the > >> >> > > > tests that JPA explicitly disallows that I think we ought to > just > >> >> stop > >> >> > > > supporting and opt for the JPA way, although I am open to > >> >> > > > discussing > >> >> > them > >> >> > > > if any feels strongly about them. Some of these include: > >> >> > > > > >> >> > > > - Asking a Session if is contains > >> >> (Session/EntityManager#contains) a > >> >> > > > non-entity. Hibernate historically would just return false. > >> >> > > > JPA > >> >> > > states > >> >> > > > that should be an exception. > >> >> > > > - Accessing Session/EntityManager#getTransaction. JPA says > >> >> > > > that > >> >> is > >> >> > > > only allowed for JDBC transactions. Hibernate always allows > >> >> > > > it. > >> >> > > > > >> >> > > > If we go the route of an "exception handling strategy" a lot of > >> >> > > > the > >> >> > other > >> >> > > > points I mentioned above could just be pushed behind that > >> >> > > > strategy. > >> >> > But > >> >> > > I > >> >> > > > really want to start looking critically at what we support > today > >> >> > > > that > >> >> > we > >> >> > > > maybe really should not be. > >> >> > > > > >> >> > > _______________________________________________ > >> >> > > 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 steve at hibernate.org Mon Apr 25 11:34:36 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 25 Apr 2016 15:34:36 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: I'd add this as well... I believe that in most of the cases here we are talking about (passing in a bad query, closing a closed Session, etc) these exceptions are of the "checked" sort, meaning they are easily identifiable prior to deployment. Which IMO helps mitigate somewhat the difficulty handling a change in exception type On Mon, Apr 25, 2016 at 10:28 AM Steve Ebersole wrote: > I agree with that to an extent. However there is also a balance - clearly > any added complexity has a direct correlation to likelihood of > errors/bugs. We just have to find that balance :) > > On Mon, Apr 25, 2016 at 9:52 AM Sanne Grinovero > wrote: > >> N.B. that chancing the exception types thrown by our native methods is >> an API change in my opinion. >> >> So while I think you can have some Hibernate exceptions now extend >> some of the types expected by JPA, a fully "clean room" approach is >> not something I'd do in a minor release. >> >> On 25 April 2016 at 15:25, Steve Ebersole wrote: >> > I agree with Gunnar in that the underlying question here is in how we >> see >> > the "Hibernate API" long term. However I would consider the following >> > categories: >> > >> > Methods which are Hibernate-only >> > Methods which Hibernate had historically which share a signature with >> JPA >> > Methods which we added to Hibernate specifically for JPA. >> > >> > >> > Personally, in retrospect, I would say that group (3) unequivocally >> should >> > have been handled by just throwing the JPA exceptions. In a clean-room >> impl >> > that's what I would do. >> > >> > So I guess the question is whether we want to look at this as a >> clean-room >> > impl or if we want to constrain ourselves to the legacy exception >> types. I >> > do wonder if a hybrid approach may be the best, as touched on before. >> > Namely, where JPA expects an IllegalArgumentException, >> > IllegalStateException, etc we throw those; for the rest we'd have >> Hibernate >> > exception extend PersistenceException. I think that's a great >> compromise. >> > >> > I'd also mention that in the IllegalArgumentException, >> > IllegalStateException, etc cases there are a few places where >> > HibernateExceptions cover the JPA case already. E.g. JPA says that if >> there >> > is a problem with the JPQL query (String) used to create a Query an >> > IllegalArgumentException should be thrown; Hibernate currently handles >> this >> > by throwing a QuerySyntaxException - we could just make >> QuerySyntaxException >> > extend from IllegalArgumentException rather than Hibernate's >> > HibernateException hierarchy. >> > >> > I think the bottom line is that having Session and EntityManager split >> > before caused all kinds of difficult-to-debug complexity that I'd rather >> > avoid as we consolidate them together. >> > >> > >> > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero >> wrote: >> >> >> >> Gunnar's words seem wise to me: users will need to have the JPA API on >> >> classpath anyway, so I don't see why we should have - and maintain - >> >> strategies for different kind of exceptions. >> >> >> >> This might have been useful in the past, but looking forward? >> >> >> >> If the reasoning is that Hibernate - having more features - could >> >> throw more specific and informative exceptions, we could have some >> >> Hibernate exceptions to subclass the JPA ones? >> >> >> >> Would be nice to avoid breaking the expected exception types in a >> >> minor, so I'm not sure if you can do that in all cases by subclassing >> >> the JPA ones, but I suspect it can get you a long way. >> >> >> >> >> >> On 25 April 2016 at 10:13, Gunnar Morling >> wrote: >> >> > The strategy approach sounds nice on first thought, but it also adds >> >> > complexity. >> >> > >> >> > I think the underlying question is: What's the long-term strategy >> around >> >> > the "Classic API"? Should it remain in place for all times as a >> complete >> >> > alternative to the JPA API? >> >> > >> >> > Or should we begin to deprecate it and narrow it down in favour of >> the >> >> > corresponding functionality standardized in JPA, and only >> functionality >> >> > not >> >> > present in JPA would be exposed through some kind of unwrap()? >> >> > >> >> > Without having thought about all the implications too much, I'd lean >> >> > towards the latter, in which case I vote for "1. Just move to JPA >> >> > expected >> >> > exceptions" as part of such larger effort. >> >> > >> >> > It'd be interesting to run a poll to see some figures of people using >> >> > classic vs. JPA. >> >> > >> >> > --Gunnar >> >> > >> >> > >> >> > >> >> > 2016-04-25 10:47 GMT+02:00 andrea boriero : >> >> > >> >> >> Having a Strategy gives us more flexibility so +1. >> >> >> >> >> >> About the expectations I think what Vlad says is reasonable. >> >> >> >> >> >> On 25 April 2016 at 06:04, Vlad Mihalcea >> >> >> wrote: >> >> >> >> >> >> > Your second email summarizes my thoughts as well. If we can >> separate >> >> >> > the >> >> >> > exception handling in two separate strategies that are defined >> during >> >> >> > bootstrap (JPA vs Hibernate), >> >> >> > I think that's the way to go. >> >> >> > >> >> >> > There so many projects out there that rely on the exception type >> >> >> > being >> >> >> > thrown, and changing those would make it very difficult for them >> to >> >> >> migrate >> >> >> > to this new version. >> >> >> > But that only affects Hibernate-native projects since, for those >> who >> >> >> > have >> >> >> > been using JPA, they already expect the JPA exceptions anyway. >> >> >> > >> >> >> > As for the other behavior discrepancies: >> >> >> > >> >> >> > 1. "calling EntityManager#close on a closed EntityManager should >> >> >> > result >> >> >> in >> >> >> > an >> >> >> > exception;" - that's a reasonable default and shouldn't cause too >> >> >> > much >> >> >> > trouble. >> >> >> > 2. "Another change in expectation is in regards to operations >> outside >> >> >> > of >> >> >> a >> >> >> > transaction" - in JPA we can execute queries outside a >> transaction, >> >> >> > but >> >> >> any >> >> >> > write will fail if there is no transactional context, which is >> >> >> > reasonable >> >> >> > for me too. If Hibernate allows writes outside of a transactional >> >> >> context, >> >> >> > that's definitely a thing we should not support anyway. >> >> >> > 3. "Asking a Session if is contains >> (Session/EntityManager#contains) >> >> >> > a >> >> >> > non-entity" - we can handle this with the separate exception >> handler >> >> >> > strategies to retain both JPA and Hibernate behaviors. >> >> >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says >> that is >> >> >> > only allowed >> >> >> > for JDBC transactions. Hibernate always allows it." - I'd choose >> the >> >> >> > Hibernate behavior because I don;t see how it can cause any issue >> and >> >> >> it's >> >> >> > an enhancement as well. >> >> >> > >> >> >> > Vlad >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole < >> steve at hibernate.org> >> >> >> > wrote: >> >> >> > >> >> >> > > Just realized that I should have mentioned an important plan >> that >> >> >> > > helps >> >> >> > > understand the idea behind the "exception handling strategy" >> route. >> >> >> > > I >> >> >> > plan >> >> >> > > to keep track of how a SessionFactory was bootstrapped in some >> >> >> > > fashion. >> >> >> > So >> >> >> > > when it was bootstrapped from EntityManagerFactoryBuilder (which >> >> >> > > JPA >> >> >> > > bootstrap methods leverage) we'd select the "JPA exception >> >> >> > > handling" >> >> >> > > strategy impl. When not, we'd use the "legacy Hibernate >> exception >> >> >> > > handling" strategy. >> >> >> > > >> >> >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole >> >> >> > > >> >> >> > > wrote: >> >> >> > > >> >> >> > > > There are a number of "expectation changes" that come about >> from >> >> >> > > > consolidating hibernate-entitymanger into hibernate-core. >> Some >> >> >> > > > we >> >> >> have >> >> >> > > > discussed; some we have not. Hopefully we can come to a >> >> >> > > > consensus >> >> >> > > regards >> >> >> > > > how to deal with these changes... >> >> >> > > > >> >> >> > > > The first one is different exception types. We have discussed >> >> >> > > > this >> >> >> > > > before. For now, in an effort to fix test failures and move >> >> >> > > > forward >> >> >> > with >> >> >> > > > developing, I simply changed failing tests to expect the JPA >> >> >> > > > defined >> >> >> > > > exceptions. I had mentioned, where possible, to to throw a >> >> >> combination >> >> >> > > of >> >> >> > > > the 2 expected exceptions. Generally this falls into 2 >> discrete >> >> >> > > categories: >> >> >> > > > >> >> >> > > > >> >> >> > > > 1. JPA expects a PersistenceException and we have >> historically >> >> >> > thrown >> >> >> > > > a HibernateException >> >> >> > > > 2. JPA expects some form of JDK RuntimeException >> >> >> > > > (IllegalArgumentException, IllegalStateException, etc) and >> we >> >> >> > > > have >> >> >> > > > historically thrown a HibernateException >> >> >> > > > >> >> >> > > > It is unfortunate that Java does not allow exceptions to be >> >> >> > > > defined >> >> >> by >> >> >> > > > means of interfaces; that's the only "clean" way I see to do >> this >> >> >> > > > - >> >> >> > that >> >> >> > > > would have allowed us to define concrete exception classes >> that >> >> >> extend >> >> >> > > > PersistenceException, IllegalArgumentException, etc and that >> >> >> implement >> >> >> > > HibernateException. >> >> >> > > > >> >> >> > > > >> >> >> > > > So I see 3 potential solutions (feel free to bring up others). >> >> >> > > > >> >> >> > > > 1. Just move to JPA expected exceptions. >> >> >> > > > 2. Have HibernateException extend PersistenceException and >> >> >> > > > just >> >> >> not >> >> >> > > > worry about the change in expectation in regards to that >> >> >> > > > second >> >> >> > > category. >> >> >> > > > 3. Push exception handling behind a strategy. This would >> have >> >> >> > > > to >> >> >> > be a >> >> >> > > > pretty specific strategy for very specific cases. >> >> >> > > > >> >> >> > > > The first and second options are pretty self-explanatory and >> >> >> > > > straight-forward so I won't go into detail there. Just >> realize >> >> >> > > > that >> >> >> > > these >> >> >> > > > change the expectation for the user. They'd have to change >> their >> >> >> code >> >> >> > to >> >> >> > > > catch these JPA-defined exceptions. >> >> >> > > > The other option, I see, is to h >> >> >> > > > >> >> >> > > > The third option is perfect in theory, but it is very tedious. >> >> >> > > > For >> >> >> > > > example, take the case of trying to perform some operation on >> a >> >> >> closed >> >> >> > > > Session/EntityManager. Hibernate historically threw a >> >> >> > HibernateException >> >> >> > > > here. JPA says that should result in an >> IllegalStateException. >> >> >> > > > So >> >> >> in >> >> >> > > > SessionImpl#checkOpen, when the Session/EntityManager is >> closed, >> >> >> > > > we'd >> >> >> > > > call out to the strategy to handle that condition. Even more, >> >> >> > Hibernate >> >> >> > > > (historically) and JPA disagree about which methods getting >> >> >> > > > called >> >> >> on a >> >> >> > > > closed Session/EntityManager should lead to an exception. For >> >> >> example, >> >> >> > > > JPA says calling EntityManager#close on a closed EntityManager >> >> >> > > > should >> >> >> > > > result in an exception; Hibernate historically did not care if >> >> >> > > > you >> >> >> > called >> >> >> > > > Session#close on a closed Session. So that is a special case, >> >> >> > > > and >> >> >> > every >> >> >> > > > one of those special cases would have to be exposed and >> handled >> >> >> > > > in >> >> >> the >> >> >> > > > exception handling strategy in additional to the general >> cases. >> >> >> > > > >> >> >> > > > Another change in expectation is in regards to operations >> outside >> >> >> > > > of >> >> >> a >> >> >> > > > transaction, which I consider a questionable pattern anyway. >> >> >> Hibernate >> >> >> > > > historically allowed that; JPA explicitly disallows it. In a >> way >> >> >> this >> >> >> > > > could fall under the exception discussion above, meaning we >> could >> >> >> push >> >> >> > > that >> >> >> > > > distinction behind the exception handling strategy. Or we >> could >> >> >> decide >> >> >> > > > that we are going to stop supporting that. >> >> >> > > > >> >> >> > > > There are a lot of other highly questionable things I have >> seen >> >> >> > > > in >> >> >> the >> >> >> > > > tests that JPA explicitly disallows that I think we ought to >> just >> >> >> stop >> >> >> > > > supporting and opt for the JPA way, although I am open to >> >> >> > > > discussing >> >> >> > them >> >> >> > > > if any feels strongly about them. Some of these include: >> >> >> > > > >> >> >> > > > - Asking a Session if is contains >> >> >> (Session/EntityManager#contains) a >> >> >> > > > non-entity. Hibernate historically would just return >> false. >> >> >> > > > JPA >> >> >> > > states >> >> >> > > > that should be an exception. >> >> >> > > > - Accessing Session/EntityManager#getTransaction. JPA says >> >> >> > > > that >> >> >> is >> >> >> > > > only allowed for JDBC transactions. Hibernate always >> allows >> >> >> > > > it. >> >> >> > > > >> >> >> > > > If we go the route of an "exception handling strategy" a lot >> of >> >> >> > > > the >> >> >> > other >> >> >> > > > points I mentioned above could just be pushed behind that >> >> >> > > > strategy. >> >> >> > But >> >> >> > > I >> >> >> > > > really want to start looking critically at what we support >> today >> >> >> > > > that >> >> >> > we >> >> >> > > > maybe really should not be. >> >> >> > > > >> >> >> > > _______________________________________________ >> >> >> > > 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 Mon Apr 25 11:36:33 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 25 Apr 2016 16:36:33 +0100 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: On 25 April 2016 at 16:28, Steve Ebersole wrote: > I agree with that to an extent. However there is also a balance - clearly > any added complexity has a direct correlation to likelihood of errors/bugs. > We just have to find that balance :) Of course :) Just pointing this out as there was mention of "clean room" design. > > On Mon, Apr 25, 2016 at 9:52 AM Sanne Grinovero wrote: >> >> N.B. that chancing the exception types thrown by our native methods is >> an API change in my opinion. >> >> So while I think you can have some Hibernate exceptions now extend >> some of the types expected by JPA, a fully "clean room" approach is >> not something I'd do in a minor release. >> >> On 25 April 2016 at 15:25, Steve Ebersole wrote: >> > I agree with Gunnar in that the underlying question here is in how we >> > see >> > the "Hibernate API" long term. However I would consider the following >> > categories: >> > >> > Methods which are Hibernate-only >> > Methods which Hibernate had historically which share a signature with >> > JPA >> > Methods which we added to Hibernate specifically for JPA. >> > >> > >> > Personally, in retrospect, I would say that group (3) unequivocally >> > should >> > have been handled by just throwing the JPA exceptions. In a clean-room >> > impl >> > that's what I would do. >> > >> > So I guess the question is whether we want to look at this as a >> > clean-room >> > impl or if we want to constrain ourselves to the legacy exception types. >> > I >> > do wonder if a hybrid approach may be the best, as touched on before. >> > Namely, where JPA expects an IllegalArgumentException, >> > IllegalStateException, etc we throw those; for the rest we'd have >> > Hibernate >> > exception extend PersistenceException. I think that's a great >> > compromise. >> > >> > I'd also mention that in the IllegalArgumentException, >> > IllegalStateException, etc cases there are a few places where >> > HibernateExceptions cover the JPA case already. E.g. JPA says that if >> > there >> > is a problem with the JPQL query (String) used to create a Query an >> > IllegalArgumentException should be thrown; Hibernate currently handles >> > this >> > by throwing a QuerySyntaxException - we could just make >> > QuerySyntaxException >> > extend from IllegalArgumentException rather than Hibernate's >> > HibernateException hierarchy. >> > >> > I think the bottom line is that having Session and EntityManager split >> > before caused all kinds of difficult-to-debug complexity that I'd rather >> > avoid as we consolidate them together. >> > >> > >> > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero >> > wrote: >> >> >> >> Gunnar's words seem wise to me: users will need to have the JPA API on >> >> classpath anyway, so I don't see why we should have - and maintain - >> >> strategies for different kind of exceptions. >> >> >> >> This might have been useful in the past, but looking forward? >> >> >> >> If the reasoning is that Hibernate - having more features - could >> >> throw more specific and informative exceptions, we could have some >> >> Hibernate exceptions to subclass the JPA ones? >> >> >> >> Would be nice to avoid breaking the expected exception types in a >> >> minor, so I'm not sure if you can do that in all cases by subclassing >> >> the JPA ones, but I suspect it can get you a long way. >> >> >> >> >> >> On 25 April 2016 at 10:13, Gunnar Morling wrote: >> >> > The strategy approach sounds nice on first thought, but it also adds >> >> > complexity. >> >> > >> >> > I think the underlying question is: What's the long-term strategy >> >> > around >> >> > the "Classic API"? Should it remain in place for all times as a >> >> > complete >> >> > alternative to the JPA API? >> >> > >> >> > Or should we begin to deprecate it and narrow it down in favour of >> >> > the >> >> > corresponding functionality standardized in JPA, and only >> >> > functionality >> >> > not >> >> > present in JPA would be exposed through some kind of unwrap()? >> >> > >> >> > Without having thought about all the implications too much, I'd lean >> >> > towards the latter, in which case I vote for "1. Just move to JPA >> >> > expected >> >> > exceptions" as part of such larger effort. >> >> > >> >> > It'd be interesting to run a poll to see some figures of people using >> >> > classic vs. JPA. >> >> > >> >> > --Gunnar >> >> > >> >> > >> >> > >> >> > 2016-04-25 10:47 GMT+02:00 andrea boriero : >> >> > >> >> >> Having a Strategy gives us more flexibility so +1. >> >> >> >> >> >> About the expectations I think what Vlad says is reasonable. >> >> >> >> >> >> On 25 April 2016 at 06:04, Vlad Mihalcea >> >> >> wrote: >> >> >> >> >> >> > Your second email summarizes my thoughts as well. If we can >> >> >> > separate >> >> >> > the >> >> >> > exception handling in two separate strategies that are defined >> >> >> > during >> >> >> > bootstrap (JPA vs Hibernate), >> >> >> > I think that's the way to go. >> >> >> > >> >> >> > There so many projects out there that rely on the exception type >> >> >> > being >> >> >> > thrown, and changing those would make it very difficult for them >> >> >> > to >> >> >> migrate >> >> >> > to this new version. >> >> >> > But that only affects Hibernate-native projects since, for those >> >> >> > who >> >> >> > have >> >> >> > been using JPA, they already expect the JPA exceptions anyway. >> >> >> > >> >> >> > As for the other behavior discrepancies: >> >> >> > >> >> >> > 1. "calling EntityManager#close on a closed EntityManager should >> >> >> > result >> >> >> in >> >> >> > an >> >> >> > exception;" - that's a reasonable default and shouldn't cause too >> >> >> > much >> >> >> > trouble. >> >> >> > 2. "Another change in expectation is in regards to operations >> >> >> > outside >> >> >> > of >> >> >> a >> >> >> > transaction" - in JPA we can execute queries outside a >> >> >> > transaction, >> >> >> > but >> >> >> any >> >> >> > write will fail if there is no transactional context, which is >> >> >> > reasonable >> >> >> > for me too. If Hibernate allows writes outside of a transactional >> >> >> context, >> >> >> > that's definitely a thing we should not support anyway. >> >> >> > 3. "Asking a Session if is contains >> >> >> > (Session/EntityManager#contains) >> >> >> > a >> >> >> > non-entity" - we can handle this with the separate exception >> >> >> > handler >> >> >> > strategies to retain both JPA and Hibernate behaviors. >> >> >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says that >> >> >> > is >> >> >> > only allowed >> >> >> > for JDBC transactions. Hibernate always allows it." - I'd choose >> >> >> > the >> >> >> > Hibernate behavior because I don;t see how it can cause any issue >> >> >> > and >> >> >> it's >> >> >> > an enhancement as well. >> >> >> > >> >> >> > Vlad >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole >> >> >> > >> >> >> > wrote: >> >> >> > >> >> >> > > Just realized that I should have mentioned an important plan >> >> >> > > that >> >> >> > > helps >> >> >> > > understand the idea behind the "exception handling strategy" >> >> >> > > route. >> >> >> > > I >> >> >> > plan >> >> >> > > to keep track of how a SessionFactory was bootstrapped in some >> >> >> > > fashion. >> >> >> > So >> >> >> > > when it was bootstrapped from EntityManagerFactoryBuilder (which >> >> >> > > JPA >> >> >> > > bootstrap methods leverage) we'd select the "JPA exception >> >> >> > > handling" >> >> >> > > strategy impl. When not, we'd use the "legacy Hibernate >> >> >> > > exception >> >> >> > > handling" strategy. >> >> >> > > >> >> >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole >> >> >> > > >> >> >> > > wrote: >> >> >> > > >> >> >> > > > There are a number of "expectation changes" that come about >> >> >> > > > from >> >> >> > > > consolidating hibernate-entitymanger into hibernate-core. >> >> >> > > > Some >> >> >> > > > we >> >> >> have >> >> >> > > > discussed; some we have not. Hopefully we can come to a >> >> >> > > > consensus >> >> >> > > regards >> >> >> > > > how to deal with these changes... >> >> >> > > > >> >> >> > > > The first one is different exception types. We have discussed >> >> >> > > > this >> >> >> > > > before. For now, in an effort to fix test failures and move >> >> >> > > > forward >> >> >> > with >> >> >> > > > developing, I simply changed failing tests to expect the JPA >> >> >> > > > defined >> >> >> > > > exceptions. I had mentioned, where possible, to to throw a >> >> >> combination >> >> >> > > of >> >> >> > > > the 2 expected exceptions. Generally this falls into 2 >> >> >> > > > discrete >> >> >> > > categories: >> >> >> > > > >> >> >> > > > >> >> >> > > > 1. JPA expects a PersistenceException and we have >> >> >> > > > historically >> >> >> > thrown >> >> >> > > > a HibernateException >> >> >> > > > 2. JPA expects some form of JDK RuntimeException >> >> >> > > > (IllegalArgumentException, IllegalStateException, etc) and >> >> >> > > > we >> >> >> > > > have >> >> >> > > > historically thrown a HibernateException >> >> >> > > > >> >> >> > > > It is unfortunate that Java does not allow exceptions to be >> >> >> > > > defined >> >> >> by >> >> >> > > > means of interfaces; that's the only "clean" way I see to do >> >> >> > > > this >> >> >> > > > - >> >> >> > that >> >> >> > > > would have allowed us to define concrete exception classes >> >> >> > > > that >> >> >> extend >> >> >> > > > PersistenceException, IllegalArgumentException, etc and that >> >> >> implement >> >> >> > > HibernateException. >> >> >> > > > >> >> >> > > > >> >> >> > > > So I see 3 potential solutions (feel free to bring up others). >> >> >> > > > >> >> >> > > > 1. Just move to JPA expected exceptions. >> >> >> > > > 2. Have HibernateException extend PersistenceException and >> >> >> > > > just >> >> >> not >> >> >> > > > worry about the change in expectation in regards to that >> >> >> > > > second >> >> >> > > category. >> >> >> > > > 3. Push exception handling behind a strategy. This would >> >> >> > > > have >> >> >> > > > to >> >> >> > be a >> >> >> > > > pretty specific strategy for very specific cases. >> >> >> > > > >> >> >> > > > The first and second options are pretty self-explanatory and >> >> >> > > > straight-forward so I won't go into detail there. Just >> >> >> > > > realize >> >> >> > > > that >> >> >> > > these >> >> >> > > > change the expectation for the user. They'd have to change >> >> >> > > > their >> >> >> code >> >> >> > to >> >> >> > > > catch these JPA-defined exceptions. >> >> >> > > > The other option, I see, is to h >> >> >> > > > >> >> >> > > > The third option is perfect in theory, but it is very tedious. >> >> >> > > > For >> >> >> > > > example, take the case of trying to perform some operation on >> >> >> > > > a >> >> >> closed >> >> >> > > > Session/EntityManager. Hibernate historically threw a >> >> >> > HibernateException >> >> >> > > > here. JPA says that should result in an >> >> >> > > > IllegalStateException. >> >> >> > > > So >> >> >> in >> >> >> > > > SessionImpl#checkOpen, when the Session/EntityManager is >> >> >> > > > closed, >> >> >> > > > we'd >> >> >> > > > call out to the strategy to handle that condition. Even more, >> >> >> > Hibernate >> >> >> > > > (historically) and JPA disagree about which methods getting >> >> >> > > > called >> >> >> on a >> >> >> > > > closed Session/EntityManager should lead to an exception. For >> >> >> example, >> >> >> > > > JPA says calling EntityManager#close on a closed EntityManager >> >> >> > > > should >> >> >> > > > result in an exception; Hibernate historically did not care if >> >> >> > > > you >> >> >> > called >> >> >> > > > Session#close on a closed Session. So that is a special case, >> >> >> > > > and >> >> >> > every >> >> >> > > > one of those special cases would have to be exposed and >> >> >> > > > handled >> >> >> > > > in >> >> >> the >> >> >> > > > exception handling strategy in additional to the general >> >> >> > > > cases. >> >> >> > > > >> >> >> > > > Another change in expectation is in regards to operations >> >> >> > > > outside >> >> >> > > > of >> >> >> a >> >> >> > > > transaction, which I consider a questionable pattern anyway. >> >> >> Hibernate >> >> >> > > > historically allowed that; JPA explicitly disallows it. In a >> >> >> > > > way >> >> >> this >> >> >> > > > could fall under the exception discussion above, meaning we >> >> >> > > > could >> >> >> push >> >> >> > > that >> >> >> > > > distinction behind the exception handling strategy. Or we >> >> >> > > > could >> >> >> decide >> >> >> > > > that we are going to stop supporting that. >> >> >> > > > >> >> >> > > > There are a lot of other highly questionable things I have >> >> >> > > > seen >> >> >> > > > in >> >> >> the >> >> >> > > > tests that JPA explicitly disallows that I think we ought to >> >> >> > > > just >> >> >> stop >> >> >> > > > supporting and opt for the JPA way, although I am open to >> >> >> > > > discussing >> >> >> > them >> >> >> > > > if any feels strongly about them. Some of these include: >> >> >> > > > >> >> >> > > > - Asking a Session if is contains >> >> >> (Session/EntityManager#contains) a >> >> >> > > > non-entity. Hibernate historically would just return >> >> >> > > > false. >> >> >> > > > JPA >> >> >> > > states >> >> >> > > > that should be an exception. >> >> >> > > > - Accessing Session/EntityManager#getTransaction. JPA says >> >> >> > > > that >> >> >> is >> >> >> > > > only allowed for JDBC transactions. Hibernate always >> >> >> > > > allows >> >> >> > > > it. >> >> >> > > > >> >> >> > > > If we go the route of an "exception handling strategy" a lot >> >> >> > > > of >> >> >> > > > the >> >> >> > other >> >> >> > > > points I mentioned above could just be pushed behind that >> >> >> > > > strategy. >> >> >> > But >> >> >> > > I >> >> >> > > > really want to start looking critically at what we support >> >> >> > > > today >> >> >> > > > that >> >> >> > we >> >> >> > > > maybe really should not be. >> >> >> > > > >> >> >> > > _______________________________________________ >> >> >> > > 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 steve at hibernate.org Mon Apr 25 13:43:00 2016 From: steve at hibernate.org (Steve Ebersole) Date: Mon, 25 Apr 2016 17:43:00 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: Currently we make a distinction between FlushMode and `shouldFlushBeforeCompletion`. Is there any reason for that? I have no idea why we decided not to have FlushMode drive `shouldFlushBeforeCompletion`. Anyone? On Mon, Apr 25, 2016 at 10:36 AM Sanne Grinovero wrote: > On 25 April 2016 at 16:28, Steve Ebersole wrote: > > I agree with that to an extent. However there is also a balance - > clearly > > any added complexity has a direct correlation to likelihood of > errors/bugs. > > We just have to find that balance :) > > Of course :) > Just pointing this out as there was mention of "clean room" design. > > > > > On Mon, Apr 25, 2016 at 9:52 AM Sanne Grinovero > wrote: > >> > >> N.B. that chancing the exception types thrown by our native methods is > >> an API change in my opinion. > >> > >> So while I think you can have some Hibernate exceptions now extend > >> some of the types expected by JPA, a fully "clean room" approach is > >> not something I'd do in a minor release. > >> > >> On 25 April 2016 at 15:25, Steve Ebersole wrote: > >> > I agree with Gunnar in that the underlying question here is in how we > >> > see > >> > the "Hibernate API" long term. However I would consider the following > >> > categories: > >> > > >> > Methods which are Hibernate-only > >> > Methods which Hibernate had historically which share a signature with > >> > JPA > >> > Methods which we added to Hibernate specifically for JPA. > >> > > >> > > >> > Personally, in retrospect, I would say that group (3) unequivocally > >> > should > >> > have been handled by just throwing the JPA exceptions. In a > clean-room > >> > impl > >> > that's what I would do. > >> > > >> > So I guess the question is whether we want to look at this as a > >> > clean-room > >> > impl or if we want to constrain ourselves to the legacy exception > types. > >> > I > >> > do wonder if a hybrid approach may be the best, as touched on before. > >> > Namely, where JPA expects an IllegalArgumentException, > >> > IllegalStateException, etc we throw those; for the rest we'd have > >> > Hibernate > >> > exception extend PersistenceException. I think that's a great > >> > compromise. > >> > > >> > I'd also mention that in the IllegalArgumentException, > >> > IllegalStateException, etc cases there are a few places where > >> > HibernateExceptions cover the JPA case already. E.g. JPA says that if > >> > there > >> > is a problem with the JPQL query (String) used to create a Query an > >> > IllegalArgumentException should be thrown; Hibernate currently handles > >> > this > >> > by throwing a QuerySyntaxException - we could just make > >> > QuerySyntaxException > >> > extend from IllegalArgumentException rather than Hibernate's > >> > HibernateException hierarchy. > >> > > >> > I think the bottom line is that having Session and EntityManager split > >> > before caused all kinds of difficult-to-debug complexity that I'd > rather > >> > avoid as we consolidate them together. > >> > > >> > > >> > On Mon, Apr 25, 2016 at 5:37 AM Sanne Grinovero > >> > wrote: > >> >> > >> >> Gunnar's words seem wise to me: users will need to have the JPA API > on > >> >> classpath anyway, so I don't see why we should have - and maintain - > >> >> strategies for different kind of exceptions. > >> >> > >> >> This might have been useful in the past, but looking forward? > >> >> > >> >> If the reasoning is that Hibernate - having more features - could > >> >> throw more specific and informative exceptions, we could have some > >> >> Hibernate exceptions to subclass the JPA ones? > >> >> > >> >> Would be nice to avoid breaking the expected exception types in a > >> >> minor, so I'm not sure if you can do that in all cases by subclassing > >> >> the JPA ones, but I suspect it can get you a long way. > >> >> > >> >> > >> >> On 25 April 2016 at 10:13, Gunnar Morling > wrote: > >> >> > The strategy approach sounds nice on first thought, but it also > adds > >> >> > complexity. > >> >> > > >> >> > I think the underlying question is: What's the long-term strategy > >> >> > around > >> >> > the "Classic API"? Should it remain in place for all times as a > >> >> > complete > >> >> > alternative to the JPA API? > >> >> > > >> >> > Or should we begin to deprecate it and narrow it down in favour of > >> >> > the > >> >> > corresponding functionality standardized in JPA, and only > >> >> > functionality > >> >> > not > >> >> > present in JPA would be exposed through some kind of unwrap()? > >> >> > > >> >> > Without having thought about all the implications too much, I'd > lean > >> >> > towards the latter, in which case I vote for "1. Just move to JPA > >> >> > expected > >> >> > exceptions" as part of such larger effort. > >> >> > > >> >> > It'd be interesting to run a poll to see some figures of people > using > >> >> > classic vs. JPA. > >> >> > > >> >> > --Gunnar > >> >> > > >> >> > > >> >> > > >> >> > 2016-04-25 10:47 GMT+02:00 andrea boriero : > >> >> > > >> >> >> Having a Strategy gives us more flexibility so +1. > >> >> >> > >> >> >> About the expectations I think what Vlad says is reasonable. > >> >> >> > >> >> >> On 25 April 2016 at 06:04, Vlad Mihalcea > > >> >> >> wrote: > >> >> >> > >> >> >> > Your second email summarizes my thoughts as well. If we can > >> >> >> > separate > >> >> >> > the > >> >> >> > exception handling in two separate strategies that are defined > >> >> >> > during > >> >> >> > bootstrap (JPA vs Hibernate), > >> >> >> > I think that's the way to go. > >> >> >> > > >> >> >> > There so many projects out there that rely on the exception type > >> >> >> > being > >> >> >> > thrown, and changing those would make it very difficult for them > >> >> >> > to > >> >> >> migrate > >> >> >> > to this new version. > >> >> >> > But that only affects Hibernate-native projects since, for those > >> >> >> > who > >> >> >> > have > >> >> >> > been using JPA, they already expect the JPA exceptions anyway. > >> >> >> > > >> >> >> > As for the other behavior discrepancies: > >> >> >> > > >> >> >> > 1. "calling EntityManager#close on a closed EntityManager should > >> >> >> > result > >> >> >> in > >> >> >> > an > >> >> >> > exception;" - that's a reasonable default and shouldn't cause > too > >> >> >> > much > >> >> >> > trouble. > >> >> >> > 2. "Another change in expectation is in regards to operations > >> >> >> > outside > >> >> >> > of > >> >> >> a > >> >> >> > transaction" - in JPA we can execute queries outside a > >> >> >> > transaction, > >> >> >> > but > >> >> >> any > >> >> >> > write will fail if there is no transactional context, which is > >> >> >> > reasonable > >> >> >> > for me too. If Hibernate allows writes outside of a > transactional > >> >> >> context, > >> >> >> > that's definitely a thing we should not support anyway. > >> >> >> > 3. "Asking a Session if is contains > >> >> >> > (Session/EntityManager#contains) > >> >> >> > a > >> >> >> > non-entity" - we can handle this with the separate exception > >> >> >> > handler > >> >> >> > strategies to retain both JPA and Hibernate behaviors. > >> >> >> > 4. "Accessing Session/EntityManager#getTransaction. JPA says > that > >> >> >> > is > >> >> >> > only allowed > >> >> >> > for JDBC transactions. Hibernate always allows it." - I'd > choose > >> >> >> > the > >> >> >> > Hibernate behavior because I don;t see how it can cause any > issue > >> >> >> > and > >> >> >> it's > >> >> >> > an enhancement as well. > >> >> >> > > >> >> >> > Vlad > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > On Sat, Apr 23, 2016 at 5:29 PM, Steve Ebersole > >> >> >> > > >> >> >> > wrote: > >> >> >> > > >> >> >> > > Just realized that I should have mentioned an important plan > >> >> >> > > that > >> >> >> > > helps > >> >> >> > > understand the idea behind the "exception handling strategy" > >> >> >> > > route. > >> >> >> > > I > >> >> >> > plan > >> >> >> > > to keep track of how a SessionFactory was bootstrapped in some > >> >> >> > > fashion. > >> >> >> > So > >> >> >> > > when it was bootstrapped from EntityManagerFactoryBuilder > (which > >> >> >> > > JPA > >> >> >> > > bootstrap methods leverage) we'd select the "JPA exception > >> >> >> > > handling" > >> >> >> > > strategy impl. When not, we'd use the "legacy Hibernate > >> >> >> > > exception > >> >> >> > > handling" strategy. > >> >> >> > > > >> >> >> > > On Sat, Apr 23, 2016 at 9:21 AM Steve Ebersole > >> >> >> > > > >> >> >> > > wrote: > >> >> >> > > > >> >> >> > > > There are a number of "expectation changes" that come about > >> >> >> > > > from > >> >> >> > > > consolidating hibernate-entitymanger into hibernate-core. > >> >> >> > > > Some > >> >> >> > > > we > >> >> >> have > >> >> >> > > > discussed; some we have not. Hopefully we can come to a > >> >> >> > > > consensus > >> >> >> > > regards > >> >> >> > > > how to deal with these changes... > >> >> >> > > > > >> >> >> > > > The first one is different exception types. We have > discussed > >> >> >> > > > this > >> >> >> > > > before. For now, in an effort to fix test failures and move > >> >> >> > > > forward > >> >> >> > with > >> >> >> > > > developing, I simply changed failing tests to expect the JPA > >> >> >> > > > defined > >> >> >> > > > exceptions. I had mentioned, where possible, to to throw a > >> >> >> combination > >> >> >> > > of > >> >> >> > > > the 2 expected exceptions. Generally this falls into 2 > >> >> >> > > > discrete > >> >> >> > > categories: > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > 1. JPA expects a PersistenceException and we have > >> >> >> > > > historically > >> >> >> > thrown > >> >> >> > > > a HibernateException > >> >> >> > > > 2. JPA expects some form of JDK RuntimeException > >> >> >> > > > (IllegalArgumentException, IllegalStateException, etc) > and > >> >> >> > > > we > >> >> >> > > > have > >> >> >> > > > historically thrown a HibernateException > >> >> >> > > > > >> >> >> > > > It is unfortunate that Java does not allow exceptions to be > >> >> >> > > > defined > >> >> >> by > >> >> >> > > > means of interfaces; that's the only "clean" way I see to do > >> >> >> > > > this > >> >> >> > > > - > >> >> >> > that > >> >> >> > > > would have allowed us to define concrete exception classes > >> >> >> > > > that > >> >> >> extend > >> >> >> > > > PersistenceException, IllegalArgumentException, etc and that > >> >> >> implement > >> >> >> > > HibernateException. > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > So I see 3 potential solutions (feel free to bring up > others). > >> >> >> > > > > >> >> >> > > > 1. Just move to JPA expected exceptions. > >> >> >> > > > 2. Have HibernateException extend PersistenceException > and > >> >> >> > > > just > >> >> >> not > >> >> >> > > > worry about the change in expectation in regards to that > >> >> >> > > > second > >> >> >> > > category. > >> >> >> > > > 3. Push exception handling behind a strategy. This would > >> >> >> > > > have > >> >> >> > > > to > >> >> >> > be a > >> >> >> > > > pretty specific strategy for very specific cases. > >> >> >> > > > > >> >> >> > > > The first and second options are pretty self-explanatory and > >> >> >> > > > straight-forward so I won't go into detail there. Just > >> >> >> > > > realize > >> >> >> > > > that > >> >> >> > > these > >> >> >> > > > change the expectation for the user. They'd have to change > >> >> >> > > > their > >> >> >> code > >> >> >> > to > >> >> >> > > > catch these JPA-defined exceptions. > >> >> >> > > > The other option, I see, is to h > >> >> >> > > > > >> >> >> > > > The third option is perfect in theory, but it is very > tedious. > >> >> >> > > > For > >> >> >> > > > example, take the case of trying to perform some operation > on > >> >> >> > > > a > >> >> >> closed > >> >> >> > > > Session/EntityManager. Hibernate historically threw a > >> >> >> > HibernateException > >> >> >> > > > here. JPA says that should result in an > >> >> >> > > > IllegalStateException. > >> >> >> > > > So > >> >> >> in > >> >> >> > > > SessionImpl#checkOpen, when the Session/EntityManager is > >> >> >> > > > closed, > >> >> >> > > > we'd > >> >> >> > > > call out to the strategy to handle that condition. Even > more, > >> >> >> > Hibernate > >> >> >> > > > (historically) and JPA disagree about which methods getting > >> >> >> > > > called > >> >> >> on a > >> >> >> > > > closed Session/EntityManager should lead to an exception. > For > >> >> >> example, > >> >> >> > > > JPA says calling EntityManager#close on a closed > EntityManager > >> >> >> > > > should > >> >> >> > > > result in an exception; Hibernate historically did not care > if > >> >> >> > > > you > >> >> >> > called > >> >> >> > > > Session#close on a closed Session. So that is a special > case, > >> >> >> > > > and > >> >> >> > every > >> >> >> > > > one of those special cases would have to be exposed and > >> >> >> > > > handled > >> >> >> > > > in > >> >> >> the > >> >> >> > > > exception handling strategy in additional to the general > >> >> >> > > > cases. > >> >> >> > > > > >> >> >> > > > Another change in expectation is in regards to operations > >> >> >> > > > outside > >> >> >> > > > of > >> >> >> a > >> >> >> > > > transaction, which I consider a questionable pattern anyway. > >> >> >> Hibernate > >> >> >> > > > historically allowed that; JPA explicitly disallows it. In > a > >> >> >> > > > way > >> >> >> this > >> >> >> > > > could fall under the exception discussion above, meaning we > >> >> >> > > > could > >> >> >> push > >> >> >> > > that > >> >> >> > > > distinction behind the exception handling strategy. Or we > >> >> >> > > > could > >> >> >> decide > >> >> >> > > > that we are going to stop supporting that. > >> >> >> > > > > >> >> >> > > > There are a lot of other highly questionable things I have > >> >> >> > > > seen > >> >> >> > > > in > >> >> >> the > >> >> >> > > > tests that JPA explicitly disallows that I think we ought to > >> >> >> > > > just > >> >> >> stop > >> >> >> > > > supporting and opt for the JPA way, although I am open to > >> >> >> > > > discussing > >> >> >> > them > >> >> >> > > > if any feels strongly about them. Some of these include: > >> >> >> > > > > >> >> >> > > > - Asking a Session if is contains > >> >> >> (Session/EntityManager#contains) a > >> >> >> > > > non-entity. Hibernate historically would just return > >> >> >> > > > false. > >> >> >> > > > JPA > >> >> >> > > states > >> >> >> > > > that should be an exception. > >> >> >> > > > - Accessing Session/EntityManager#getTransaction. JPA > says > >> >> >> > > > that > >> >> >> is > >> >> >> > > > only allowed for JDBC transactions. Hibernate always > >> >> >> > > > allows > >> >> >> > > > it. > >> >> >> > > > > >> >> >> > > > If we go the route of an "exception handling strategy" a lot > >> >> >> > > > of > >> >> >> > > > the > >> >> >> > other > >> >> >> > > > points I mentioned above could just be pushed behind that > >> >> >> > > > strategy. > >> >> >> > But > >> >> >> > > I > >> >> >> > > > really want to start looking critically at what we support > >> >> >> > > > today > >> >> >> > > > that > >> >> >> > we > >> >> >> > > > maybe really should not be. > >> >> >> > > > > >> >> >> > > _______________________________________________ > >> >> >> > > 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 Tue Apr 26 08:34:45 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 26 Apr 2016 13:34:45 +0100 Subject: [hibernate-dev] Released: Hibernate Search 5.5.3.Final Message-ID: Hello all, a maintenance release of our latest stable branch, version 5.5.3.Final of Hibernate Search is now available, and is the suggested stable version for everyone to use. More details about the improvements can be found on our blog: - http://in.relation.to/2016/04/26/Polishing-A-Great-Release-Hibernate-Search-5/ Regards, Sanne From crancran at gmail.com Tue Apr 26 08:56:15 2016 From: crancran at gmail.com (Chris Cranford) Date: Tue, 26 Apr 2016 07:56:15 -0500 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: <571F656F.2040404@gmail.com> On 04/25/2016 12:04 AM, Vlad Mihalcea wrote: > 1. "calling EntityManager#close on a closed EntityManager should result in an > exception;" - that's a reasonable default and shouldn't cause too much > trouble. > 2. "Another change in expectation is in regards to operations outside of a > transaction" - in JPA we can execute queries outside a transaction, but any > write will fail if there is no transactional context, which is reasonable > for me too. If Hibernate allows writes outside of a transactional context, > that's definitely a thing we should not support anyway. > 3. "Asking a Session if is contains (Session/EntityManager#contains) a > non-entity" - we can handle this with the separate exception handler > strategies to retain both JPA and Hibernate behaviors. > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is > only allowed > for JDBC transactions. Hibernate always allows it." - I'd choose the > Hibernate behavior because I don;t see how it can cause any issue and it's > an enhancement as well. +1 From crancran at gmail.com Tue Apr 26 08:57:15 2016 From: crancran at gmail.com (Chris Cranford) Date: Tue, 26 Apr 2016 07:57:15 -0500 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: <571F65AB.7090607@gmail.com> On 04/25/2016 10:34 AM, Steve Ebersole wrote: > I'd add this as well... > > I believe that in most of the cases here we are talking about (passing in a > bad query, closing a closed Session, etc) these exceptions are of the > "checked" sort, meaning they are easily identifiable prior to deployment. > Which IMO helps mitigate somewhat the difficulty handling a change in > exception type +1 From guillaume.smet at gmail.com Tue Apr 26 09:54:56 2016 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Tue, 26 Apr 2016 15:54:56 +0200 Subject: [hibernate-dev] NoORM IRC meeting transcripts Message-ID: Hi everyone, Here are the transcripts of this week's NoORM IRC meeting. 15:47 < jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-04-26-13.01.html 15:47 < jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-04-26-13.01.txt 15:47 < jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-04-26-13.01.log.html First meeting as chair so there are a couple of adjustments to make. See you next time! -- Guillaume From steve at hibernate.org Tue Apr 26 10:53:59 2016 From: steve at hibernate.org (Steve Ebersole) Date: Tue, 26 Apr 2016 14:53:59 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: > > 2. "Another change in expectation is in regards to operations outside of > a transaction" - in JPA we can execute queries outside a transaction, but > any write will fail if there is no transactional context, which is > reasonable for me too. If Hibernate allows writes outside of a > transactional context, that's definitely a thing we should not support > anyway. > Well we'll agree to disagree about the validity of allowing queries outside the scope of a transaction; it does not matter, because JPA says it should be allowed, so we have to allow that. However, historically Hibernate allowed writes outside the scope of a transaction as well (auto-commit support), so that is what I am talking about. After pulling over HEM logic we now have some test failures due to tests trying to write data outside of an explicit transaction ( javax.persistence.TransactionRequiredException). So I propose we continue to expect that as a failure starting in 5.2. For queries we will continue to supports it, but only because JPA requires us to; not because it is a valid concept. > 3. "Asking a Session if is contains (Session/EntityManager#contains) a > non-entity" - we can handle this with the separate exception handler > strategies to retain both JPA and Hibernate behaviors. > Why? This is exactly the kind of thing I have in mind when I talk about the unnecessary complexity. Clearly asking if the Session contains a boolean e.g. is complete non-sense. If JPA requires that condition to throw an exception, why even worry about the other case? > 4. "Accessing Session/EntityManager#getTransaction. JPA says that is > only allowed for JDBC transactions. Hibernate always allows it." - I'd > choose the Hibernate behavior because I don;t see how it can cause any > issue and it's an enhancement as well. > Well that's great in principle. But JPA actually requires an exception be thrown when #getTransaction() is called in the JTA case. So there is no simple "just allow it as an extension" solution, we'd have to specific allow users to opt-in to allowing that. From mihalcea.vlad at gmail.com Tue Apr 26 11:09:25 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Tue, 26 Apr 2016 18:09:25 +0300 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: Hi, It's fine if we stick to the JPA spec so that only read ops are allowed to be executed outside of a transactional context. Most applications use either Java EE or Spring, so transaction boundaries are usually enforced anyway. It's also fine to throw an exception if the object being checked within the Persistence Context is not an entity. This might break some existing use cases, but we are covered by the JPA spec :D In the getTransaction() case, I still believe we should offer two strategies: a JPA and a native one, the choice being made based on the current bootstrap procedure or some configuration property. Vlad On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole wrote: > 2. "Another change in expectation is in regards to operations outside of >> a transaction" - in JPA we can execute queries outside a transaction, >> but any write will fail if there is no transactional context, which is >> reasonable for me too. If Hibernate allows writes outside of a >> transactional context, that's definitely a thing we should not support >> anyway. >> > > Well we'll agree to disagree about the validity of allowing queries > outside the scope of a transaction; it does not matter, because JPA says it > should be allowed, so we have to allow that. > > However, historically Hibernate allowed writes outside the scope of a > transaction as well (auto-commit support), so that is what I am talking > about. After pulling over HEM logic we now have some test failures due to > tests trying to write data outside of an explicit transaction ( > javax.persistence.TransactionRequiredException). > > So I propose we continue to expect that as a failure starting in 5.2. For > queries we will continue to supports it, but only because JPA requires us > to; not because it is a valid concept. > > > >> 3. "Asking a Session if is contains (Session/EntityManager#contains) a >> non-entity" - we can handle this with the separate exception handler >> strategies to retain both JPA and Hibernate behaviors. >> > > Why? This is exactly the kind of thing I have in mind when I talk about > the unnecessary complexity. Clearly asking if the Session contains a > boolean e.g. is complete non-sense. If JPA requires that condition to > throw an exception, why even worry about the other case? > > > > >> 4. "Accessing Session/EntityManager#getTransaction. JPA says that is >> only allowed for JDBC transactions. Hibernate always allows it." - I'd >> choose the Hibernate behavior because I don;t see how it can cause any >> issue and it's an enhancement as well. >> > > Well that's great in principle. But JPA actually requires an exception be > thrown when #getTransaction() is called in the JTA case. So there is no > simple "just allow it as an extension" solution, we'd have to specific > allow users to opt-in to allowing that. > > From gbadner at redhat.com Tue Apr 26 14:03:39 2016 From: gbadner at redhat.com (Gail Badner) Date: Tue, 26 Apr 2016 11:03:39 -0700 Subject: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted! In-Reply-To: References: <001a113f7d24b49bcf053117c9ba@google.com> Message-ID: Welcome Mincong! On Mon, Apr 25, 2016 at 5:44 AM, Vlad Mihalcea wrote: > Hi Mincong, > > Welcome and enjoy the GSoC! > > Vlad > > On Mon, Apr 25, 2016 at 10:07 AM, Mincong Huang > wrote: > > > Hi Gunnar, > > > > Thanks you and everybody in hibernate-dev. So glad to join you :) > > > > Before the action begins, here're some progress I've done in these weeks > : > > > > - Built a simple Apache Lucene example to understand how index and > > search works > > - Built a simple Hibernate Search example to understand how to > transfer > > a simple lucene query (keyword, fuzzy, wildcard query) into > > FullTextQuery > > using FullTextEntityManager and JPA > > - Contributed to HSEARCH-2207 > > : Treat > > BooleanQuery as an immutable Query > > - Ran some batch examples on WildFly 10.0. (examples found at > > github.com/javaee-samples/javaee7-samples) > > - Building a simple batch example containing reader, processor, writer > > and a checkpoint algorithm. This one is still in progress, because I > > didn't > > found ways to break the batch job, and then test the checkpoint. > > > > Cheers, > > Mincong > > > > On Sat, Apr 23, 2016 at 10:39 AM, Gunnar Morling > > wrote: > > > > > Hi Mincong, > > > > > > Congrats and welcome to this year's GSoC! Looking forward to the > project > > > and your contributions very much! > > > > > > @Everyone: Please join me in welcoming Mincong to the team! He is a > > > student living in France and as part of Google Summer of Code he will > be > > > working on an alternative for mass indexing entities in Hibernate > Search > > > based on the JSR 352 for batch applications (see [1] for the project > > > proposal). I'll be mentoring him. > > > > > > @Mincong: All the best for your GSoC! I'd say for now enjoy the weekend > > > before the action begins and then let's get a discussion on the details > > > started. > > > > > > Onwards, > > > > > > --Gunnar > > > > > > [1] https://summerofcode.withgoogle.com/serve/5594702887780352/ > > > > > > > > > > > > 2016-04-22 23:20 GMT+02:00 Mincong Huang : > > > > > >> Hi everybody, > > >> > > >> Thanks for accepting my application of GSoC !! Really excited to > having > > >> chance to work the hibernate team. I'm so happy to see this email. > It's > > >> just > > >> like a dream, can't believe it is true !! Thanks for choosing me. I'll > > >> try my > > >> best to accomplish this mission !! Happy coding and good night :-) > > >> > > >> Cheers, > > >> Mincong > > >> > > >> On Fri, Apr 22, 2016 at 9:25 PM, Google Summer of Code < > > >> summerofcode-noreply at google.com> wrote: > > >> > > >>> [image: Google Summer of Code] > > >>> > > >>> Hi mincongh, > > >>> > > >>> Welcome to GSoC 2016! > > >>> > > >>> Your proposal Hibernate Search: JSR 352 batch job for re-indexing > > >>> entities > > >>> < > > > https://summerofcode.withgoogle.com/dashboard/student/proposal/5244068401512448/ > > > > > >>> has been accepted! > > >>> > > >>> We look forward to seeing the great things you will accomplish this > > >>> summer with JBoss Community. > > >>> > > >>> This email contains important information about your participation in > > >>> GSoC this year. Please read it carefully. > > >>> > > >>> Over the next month you will take part in the Community Bonding > period > > >>> with your organization. This period is for you to become familiar > with > > the > > >>> organization's code base, version control and other infrastructure. > You > > >>> will be getting to know the community and its practices, as well as > > working > > >>> with your mentor on milestones for the summer. > > >>> > > >>> Complete all of these steps as soon as you can: > > >>> > > >>> 1. Read the Accepted Student Information > > >>> < > > https://developers.google.com/open-source/gsoc/help/accepted-students> > > >>> 2. Upload your > tax > > >>> form *before May 16, 2016 at 19:00 UTC* > > >>> 3. Read the Student Payment Information > > >>> > > >>> 4. Set up your Payoneer account before May 16, 2016 at 19:00 UTC > > >>> 5. Verify your shipping address, promotional materials, and > t-shirt > > >>> information on your profile > > >>> . > > >>> > > >>> If you have questions about anything in this email, please email the > > >>> Google GSoC support team at gsoc-support at google.com. Don?t email the > > >>> student list with tax or payment issues. > > >>> > > >>> Have a great summer! > > >>> > > >>> Google Open Source Programs team > > >>> > > >>> This email was sent to mincong.h at gmail.com. > > >>> > > >>> You are receiving this email because of your participation in Google > > >>> Summer of Code 2016. > > >>> https://summerofcode.withgoogle.com > > >>> > > >>> To leave the program and stop receiving all emails, you can go to > your > > >>> profile and > > >>> request deletion of your program profile. > > >>> > > >>> For any questions, please contact gsoc-support at google.com. Replies > to > > >>> this message go to an unmonitored mailbox. > > >>> > > >>> ? 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA > 94043, > > >>> USA > > >>> > > >> > > >> > > > > > _______________________________________________ > > 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 Apr 26 18:04:59 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 26 Apr 2016 23:04:59 +0100 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite Message-ID: The "Service" and "ServiceManager" concepts in Hibernate Search have a specific meaning which is often misunderstood and/or abused, causing trouble. They also changed over time: victim of two major refactorings which evolved the purpose and stretching its intent So I'll change the definition again :-) But hopefully clarifying it, so here is a draft of the rules which I plan to both implement and document carefully on the javadoc, with some comments to highlight what is changing: # A service type is identified by a Class: a Service interface Nothing new here. Yet: worth stressing that this implies that only one implementation will be around. # There can only be ONE IMPLEMENTATION of a service type used by the whole Hibernate Search instance In other words: it was not a good idea to have the LuceneWorkSerializer to be modelled as a Service, back when we supposedly could use a different serialization strategy for a different index. Yet it is a good idea nowadays to have LuceneWorkSerializer extend Service, as we dropped that level of flexibility. This implies that there's a single type of serializer (at most) and it's totally fine to expose this as: SearchIntegrator#getLuceneWorkSerializer() [this method doesn't exist yet, but I'm thinking of adding it for our convenience and the following other points] P.S. we're only maintaining - and bundling - a single Serializer implementation so it's no surprise that we can handle only one.. yet this implies people wanting to override it have to either hack our bootstrap or physically remove our implementation. # A Service implementation can be provided by having it injected at bootstrap (i.e. org.hibernate.search.cfg.spi.SearchConfiguration.getProvidedServices() ) Not a new rule either: repeating for clarity. We call these "provided" services. # If a service isn't "provided", then we attempt to create one using java.util.ServiceLoader Currently this expects a single implementation to be available: there's no way to pick which one if there are multiple implementations on the classpath. I think we'll need to be able to pass a "hint" or similar to the requestService to allow expression of preferences, handle shortnames, etc.. a proposal for that will follow when there will be need: at this point it's important to clarify the limitation, as this expresses what a Service is not able to model today. Currently implementations are looked up "on demand". I plan to allow "pre-initialize" services as it removes some trouble; these components could have convenience getters, not least to remove the concurrency overhead. Remember that since there's only one implementation for a given type around, there's no reason to not do this: the intent of the Service contract is to allow people to inject a customized implementation. # If a Service implementation also implements Startable, or Stoppable, we'll invoke the respective methods once at start and/or at stop of the Search instance - unless they are provided in which case they are ignored. The current javadoc suggests that it's illegal for a provided implementation to also implement Startable and/or Stoppable; I don't remember why that was, but today it seems unfitting: people might want to extend one of our implementations, or reuse some of the implementations normally auto-started but reuse them "by instance" by providing them to multiple Search instances to save memory (we actually have a need for this for Index Affinity in Infinispan). The important concept which will survive, is that we don't start or stop stuff which is provided as that's clearly responsibility of another component. # All non-provided Services will be stopped once, and only once as final step when the SearchIntegrator is stopped. This is a significant difference with today's code: we expect the Service consumers to "open / close", hopefully in a finally block, to the point that Gunnar enhanced it to at least allow AutoClose semantics. Yet, I don't want runtime code to open and close these frequently as it has been a bottleneck in the past. It also led to the creations of issues like HSEARCH-1589 : we might start/stop the same service frequently, and need to improve with reference counters. I suspect that historically the reasoning was to make sure that the order of teardown would follow the inverse order of bootstrap as components would cleanup after themselves, but having clarified that Service instances are unique globally, should also imply that their state doesn't depend on other Services. So the teardown order doesn't matter anymore.. we'll start one for each, but only close it at shutdown. # Hierarchy? We've talked about global components so far. It's clear that the IndexManager has a central role in the overall architecture, as we tend to allow per-index customisations. Or per-family customisations, as suggested in my previous email. An example which affects Service: The "JestClient client" [the Service we use to connect to Elasticsearch] could be considered a good fit for being a "Service" as this allows people to override the client implementation and/or inject a pre-configured instance.. yet it's not a good fit if we want to allow people to connect to different hosts for different indexes. I don't plan to implement the hierarchical ServiceManager right now, but proposing it already so that we can agree on the above cleanups in contract, with the perspective that there are cleaner solutions also for the scoped use case. Implementing these changes resolves or obsoletes at least 10 JIRA issues in one shot.. Thanks, Sanne From daltodavide at gmail.com Wed Apr 27 05:33:14 2016 From: daltodavide at gmail.com (Davide D'Alto) Date: Wed, 27 Apr 2016 10:33:14 +0100 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite In-Reply-To: References: Message-ID: This is an interesting sum up. Shouldn't we keep these thoughts in a separate document for developer? Together with some higher level diagrams of the architecture, maybe. On Tue, Apr 26, 2016 at 11:04 PM, Sanne Grinovero wrote: > The "Service" and "ServiceManager" concepts in Hibernate Search have a > specific meaning which is often misunderstood and/or abused, causing > trouble. > > They also changed over time: victim of two major refactorings which > evolved the purpose and stretching its intent > > So I'll change the definition again :-) > But hopefully clarifying it, so here is a draft of the rules which I > plan to both implement and document carefully on the javadoc, with > some comments to highlight what is changing: > > > > # A service type is identified by a Class: a Service interface > > Nothing new here. Yet: worth stressing that this implies that only one > implementation will be around. > > # There can only be ONE IMPLEMENTATION of a service type used by the > whole Hibernate Search instance > > In other words: it was not a good idea to have the > LuceneWorkSerializer to be modelled as a Service, back when we > supposedly could use a different serialization strategy for a > different index. > > Yet it is a good idea nowadays to have LuceneWorkSerializer extend > Service, as we dropped that level of flexibility. This implies that > there's a single type of serializer (at most) and it's totally fine to > expose this as: > > SearchIntegrator#getLuceneWorkSerializer() > > [this method doesn't exist yet, but I'm thinking of adding it for our > convenience and the following other points] > > P.S. we're only maintaining - and bundling - a single Serializer > implementation so it's no surprise that we can handle only one.. yet > this implies people wanting to override it have to either hack our > bootstrap or physically remove our implementation. > > # A Service implementation can be provided by having it injected at > bootstrap (i.e. > org.hibernate.search.cfg.spi.SearchConfiguration.getProvidedServices() > ) > > Not a new rule either: repeating for clarity. We call these "provided" > services. > > # If a service isn't "provided", then we attempt to create one using > java.util.ServiceLoader > > Currently this expects a single implementation to be available: > there's no way to pick which one if there are multiple implementations > on the classpath. > I think we'll need to be able to pass a "hint" or similar to the > requestService to allow expression of preferences, handle shortnames, > etc.. a proposal for that will follow when there will be need: at this > point it's important to clarify the limitation, as this expresses what > a Service is not able to model today. > > Currently implementations are looked up "on demand". I plan to allow > "pre-initialize" services as it removes some trouble; these components > could have convenience getters, not least to remove the concurrency > overhead. > Remember that since there's only one implementation for a given type > around, there's no reason to not do this: the intent of the Service > contract is to allow people to inject a customized implementation. > > # If a Service implementation also implements Startable, or Stoppable, > we'll invoke the respective methods once at start and/or at stop of > the Search instance - unless they are provided in which case they are > ignored. > > The current javadoc suggests that it's illegal for a provided > implementation to also implement Startable and/or Stoppable; I don't > remember why that was, but today it seems unfitting: people might want > to extend one of our implementations, or reuse some of the > implementations normally auto-started but reuse them "by instance" by > providing them to multiple Search instances to save memory (we > actually have a need for this for Index Affinity in Infinispan). > The important concept which will survive, is that we don't start or > stop stuff which is provided as that's clearly responsibility of > another component. > > # All non-provided Services will be stopped once, and only once as > final step when the SearchIntegrator is stopped. > > This is a significant difference with today's code: we expect the > Service consumers to "open / close", hopefully in a finally block, to > the point that Gunnar enhanced it to at least allow AutoClose > semantics. > Yet, I don't want runtime code to open and close these frequently as > it has been a bottleneck in the past. > > It also led to the creations of issues like HSEARCH-1589 : we might > start/stop the same service frequently, and need to improve with > reference counters. > > I suspect that historically the reasoning was to make sure that the > order of teardown would follow the inverse order of bootstrap as > components would cleanup after themselves, but having clarified that > Service instances are unique globally, should also imply that their > state doesn't depend on other Services. So the teardown order doesn't > matter anymore.. we'll start one for each, but only close it at > shutdown. > > # Hierarchy? > > We've talked about global components so far. It's clear that the > IndexManager has a central role in the overall architecture, as we > tend to allow per-index customisations. Or per-family customisations, > as suggested in my previous email. > > An example which affects Service: > The "JestClient client" [the Service we use to connect to > Elasticsearch] could be considered a good fit for being a "Service" as > this allows people to override the client implementation and/or inject > a pre-configured instance.. yet it's not a good fit if we want to > allow people to connect to different hosts for different indexes. > > I don't plan to implement the hierarchical ServiceManager right now, > but proposing it already so that we can agree on the above cleanups in > contract, with the perspective that there are cleaner solutions also > for the scoped use case. > > Implementing these changes resolves or obsoletes at least 10 JIRA > issues in one shot.. > > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From mihalcea.vlad at gmail.com Wed Apr 27 06:33:42 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Wed, 27 Apr 2016 13:33:42 +0300 Subject: [hibernate-dev] Community newsletter contribution Message-ID: Hi, I wanted to ask everyone to let me know if you'd like to include any resource in the Community newsletter. If you stumble on a blog post, forum or StackOverflow question, that you happened to like and was worth sharing, you can send it to me, and I'll include it in the next edition. Thanks, Vlad From gunnar at hibernate.org Wed Apr 27 06:35:00 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 27 Apr 2016 12:35:00 +0200 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite In-Reply-To: References: Message-ID: Hey Sanne, great write-up! 2016-04-27 0:04 GMT+02:00 Sanne Grinovero : > The "Service" and "ServiceManager" concepts in Hibernate Search have a > specific meaning which is often misunderstood and/or abused, causing > trouble. > > They also changed over time: victim of two major refactorings which > evolved the purpose and stretching its intent > > So I'll change the definition again :-) > But hopefully clarifying it, so here is a draft of the rules which I > plan to both implement and document carefully on the javadoc, with > some comments to highlight what is changing: > > > > # A service type is identified by a Class: a Service interface > > Nothing new here. Yet: worth stressing that this implies that only one > implementation will be around. > > # There can only be ONE IMPLEMENTATION of a service type used by the > whole Hibernate Search instance > > In other words: it was not a good idea to have the > LuceneWorkSerializer to be modelled as a Service, back when we > supposedly could use a different serialization strategy for a > different index. > > Yet it is a good idea nowadays to have LuceneWorkSerializer extend > Service, as we dropped that level of flexibility. This implies that > there's a single type of serializer (at most) and it's totally fine to > expose this as: > > SearchIntegrator#getLuceneWorkSerializer() > > [this method doesn't exist yet, but I'm thinking of adding it for our > convenience and the following other points] > It's not clear to me when you'd provide such convenience getter and when not. What's the criteria for it? It appears you consider different categories of services? Personally, I'd like if each service would obtain the other services it depends on through its constructor. Then it can store the dependencies in (final) fields and reference them as needed without any sort of look-up. Services would not have to deal with the service manager anymore, they'd just get those services they need. One thing I dislike about the current approach is that you cannot make services fully immutable via final fields if you depend on other services. > > P.S. we're only maintaining - and bundling - a single Serializer > implementation so it's no surprise that we can handle only one.. yet > this implies people wanting to override it have to either hack our > bootstrap or physically remove our implementation. > > # A Service implementation can be provided by having it injected at > bootstrap (i.e. > org.hibernate.search.cfg.spi.SearchConfiguration.getProvidedServices() > ) > > Not a new rule either: repeating for clarity. We call these "provided" > services. > > # If a service isn't "provided", then we attempt to create one using > java.util.ServiceLoader > > Currently this expects a single implementation to be available: > there's no way to pick which one if there are multiple implementations > on the classpath. > I think we'll need to be able to pass a "hint" or similar to the > requestService to allow expression of preferences, handle shortnames, > etc.. a proposal for that will follow when there will be need: at this > point it's important to clarify the limitation, as this expresses what > a Service is not able to model today. > +1 for shaping requirements around this once it's needed. Atm. it appears a bit blurry to me. > > Currently implementations are looked up "on demand". I plan to allow > "pre-initialize" services as it removes some trouble; these components > could have convenience getters, not least to remove the concurrency > overhead. > Remember that since there's only one implementation for a given type > around, there's no reason to not do this: the intent of the Service > contract is to allow people to inject a customized implementation. > Sounds good. # If a Service implementation also implements Startable, or Stoppable, > we'll invoke the respective methods once at start and/or at stop of > the Search instance - unless they are provided in which case they are > ignored. > > The current javadoc suggests that it's illegal for a provided > implementation to also implement Startable and/or Stoppable; I don't > remember why that was, but today it seems unfitting: people might want > to extend one of our implementations, or reuse some of the > implementations normally auto-started but reuse them "by instance" by > providing them to multiple Search instances to save memory (we > actually have a need for this for Index Affinity in Infinispan). > The important concept which will survive, is that we don't start or > stop stuff which is provided as that's clearly responsibility of > another component. > Why is this? Above you say it's unfitting? I'm not quite clear on the proposed direction. # All non-provided Services will be stopped once, and only once as > final step when the SearchIntegrator is stopped. > > This is a significant difference with today's code: we expect the > Service consumers to "open / close", hopefully in a finally block, to > the point that Gunnar enhanced it to at least allow AutoClose > semantics. > Yet, I don't want runtime code to open and close these frequently as > it has been a bottleneck in the past. > +1 for setting up the graph once and avoiding all the request/release hassle. Ideally with "constructor injection" as described above. > > It also led to the creations of issues like HSEARCH-1589 : we might > start/stop the same service frequently, and need to improve with > reference counters. > > I suspect that historically the reasoning was to make sure that the > order of teardown would follow the inverse order of bootstrap as > components would cleanup after themselves, but having clarified that > Service instances are unique globally, should also imply that their > state doesn't depend on other Services. So the teardown order doesn't > matter anymore.. we'll start one for each, but only close it at > shutdown. > I'm not following on that one. Provided one service uses another and stores it in a field, tear down order may matter indeed (if a service is using another one in its close() logic). It'd be resolved easily if circles are forbidden. # Hierarchy? > > We've talked about global components so far. It's clear that the > IndexManager has a central role in the overall architecture, as we > tend to allow per-index customisations. Or per-family customisations, > as suggested in my previous email. > > An example which affects Service: > The "JestClient client" [the Service we use to connect to > Elasticsearch] could be considered a good fit for being a "Service" as > this allows people to override the client implementation and/or inject > a pre-configured instance.. yet it's not a good fit if we want to > allow people to connect to different hosts for different indexes. > > I don't plan to implement the hierarchical ServiceManager right now, > but proposing it already so that we can agree on the above cleanups in > contract, with the perspective that there are cleaner solutions also > for the scoped use case. > It's an interesting idea. The granularity of the hierarchy would have to be discussed. Would you e.g. have one service manager per index which inherits the global one? Implementing these changes resolves or obsoletes at least 10 JIRA > issues in one shot.. > What is your plan for this? Which ones do you plan to address as of 5.6, (5.7), 6 or farther in the future? > Thanks, > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From hardy at hibernate.org Wed Apr 27 08:34:41 2016 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 27 Apr 2016 14:34:41 +0200 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite In-Reply-To: References: Message-ID: <20160427123441.GA2401@nineveh.local> Hi, > Yet it is a good idea nowadays to have LuceneWorkSerializer extend > Service, as we dropped that level of flexibility. This implies that > there's a single type of serializer (at most) Ok > and it's totally fine to expose this as: > SearchIntegrator#getLuceneWorkSerializer() How is that related to the service discussion and why do you want to offer it. What is the benefit? The SearchIntegrator already gives access to the ServiceManager from where the serializer can be retrieved. Why exposing an explicit getter? Are you going to add getters for all services? Would this getter do something different than accessing the service manager? On a tangent, the whole serialization framework would need an overhaul, especially the Serializer and Deserializer interfaces. They are very tightly coupled on how Avro works and tbh they are quite convoluted. > # A Service implementation can be provided by having it injected at > bootstrap (i.e. > org.hibernate.search.cfg.spi.SearchConfiguration.getProvidedServices() > ) > > Not a new rule either: repeating for clarity. We call these "provided" services. One thing, I was never happy about was that provided services get a sopecial treatment in the service manager. They can returned first, provided they match the requested service type and they are don't get "released" (meaning they don't take part in the reference counting). I think services which are managed by the service manager should be treated equal. Maybe that becomes possible now that you consider dropping the reference counting, which I think is a good idea. > Currently this expects a single implementation to be available: > there's no way to pick which one if there are multiple implementations > on the classpath. We have been discussing to extend the implementation once the needs arises to allow multiple service implementation to be available on the classpath in which case the user must provide additional configuration to allow to select the correct implementation. So far there was no need to add this, but maybe now!? > Currently implementations are looked up "on demand". I plan to allow > "pre-initialize" services as it removes some trouble; What exactly does that mean? Didn't we have this discussion before? Which troubles are you talking about? > not least to remove the concurrency overhead. This argument could of course not be missed out ;-) > # If a Service implementation also implements Startable, or Stoppable, > we'll invoke the respective methods once at start and/or at stop of > the Search instance - unless they are provided in which case they are > ignored. This is something I never full understood. If a provided services does not want to get started/stopped would it then just not implement these interfaces? > The current javadoc suggests that it's illegal for a provided > implementation to also implement Startable and/or Stoppable; I don't > remember why that was, but today it seems unfitting Illegal might be the wrong term. It probably should say that it should not implement them if it does not want to have these callbacks invoked. Which is pretty much obvious. AFAIR, there was a discussion that we never should start/stop a provided service and hence this wording, but I think in code we never enforced it. > The important concept which will survive, is that we don't start or > stop stuff which is provided as that's clearly responsibility of > another component. Then it should not implement Startable/Stopable and if it does, it should be noops. > # All non-provided Services will be stopped once, and only once as > final step when the SearchIntegrator is stopped. +1 > This is a significant difference with today's code: we expect the > Service consumers to "open / close", hopefully in a finally block, to > the point that Gunnar enhanced it to at least allow AutoClose > semantics. I think this is still a good practice. I'd keep the API like this, but don't do reference counting and stop the service each time the count reaches 0. Instead, as you say, stop all services at a final shutdown. > I don't plan to implement the hierarchical ServiceManager right now, > but proposing it already so that we can agree on the above cleanups in > contract, with the perspective that there are cleaner solutions also > for the scoped use case. What do you even understand under a hierarchical index manager? > Implementing these changes resolves or obsoletes at least 10 JIRA > issues in one shot.. Really? --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160427/9833a67f/attachment-0001.bin From hardy at hibernate.org Wed Apr 27 08:36:58 2016 From: hardy at hibernate.org (Hardy Ferentschik) Date: Wed, 27 Apr 2016 14:36:58 +0200 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: <20160427123658.GB2401@nineveh.local> Hi, On Mon, 25-Apr-2016 11:13, Gunnar Morling wrote: > The strategy approach sounds nice on first thought, but it also adds > complexity. +1 > I think the underlying question is: What's the long-term strategy around > the "Classic API"? Should it remain in place for all times as a complete > alternative to the JPA API? > > Or should we begin to deprecate it and narrow it down in favour of the > corresponding functionality standardized in JPA, and only functionality not > present in JPA would be exposed through some kind of unwrap()? > > Without having thought about all the implications too much, I'd lean > towards the latter, in which case I vote for "1. Just move to JPA expected > exceptions" as part of such larger effort. +1 My thinking as well. --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160427/f11dd194/attachment.bin From sanne at hibernate.org Wed Apr 27 08:48:02 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Apr 2016 13:48:02 +0100 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite In-Reply-To: References: Message-ID: On 27 April 2016 at 10:33, Davide D'Alto wrote: > This is an interesting sum up. > Shouldn't we keep these thoughts in a separate document for developer? > > Together with some higher level diagrams of the architecture, maybe. I indeed wrote it as you expressed need for an high-level overview of Search. I can add a distilled version to our wiki and try to incorporate the feedback, but I was hoping we'd avoid the direction which might bring us to UML age :) .. maybe a clarification on the javadocs and contract methods would suffice? From sanne at hibernate.org Wed Apr 27 09:48:47 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Apr 2016 14:48:47 +0100 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite In-Reply-To: References: Message-ID: On 27 April 2016 at 11:35, Gunnar Morling wrote: > Hey Sanne, > > great write-up! > > 2016-04-27 0:04 GMT+02:00 Sanne Grinovero : >> >> The "Service" and "ServiceManager" concepts in Hibernate Search have a >> specific meaning which is often misunderstood and/or abused, causing >> trouble. >> >> They also changed over time: victim of two major refactorings which >> evolved the purpose and stretching its intent >> >> So I'll change the definition again :-) >> But hopefully clarifying it, so here is a draft of the rules which I >> plan to both implement and document carefully on the javadoc, with >> some comments to highlight what is changing: >> >> >> >> # A service type is identified by a Class: a Service interface >> >> Nothing new here. Yet: worth stressing that this implies that only one >> implementation will be around. >> >> # There can only be ONE IMPLEMENTATION of a service type used by the >> whole Hibernate Search instance >> >> In other words: it was not a good idea to have the >> LuceneWorkSerializer to be modelled as a Service, back when we >> supposedly could use a different serialization strategy for a >> different index. >> >> Yet it is a good idea nowadays to have LuceneWorkSerializer extend >> Service, as we dropped that level of flexibility. This implies that >> there's a single type of serializer (at most) and it's totally fine to >> expose this as: >> >> SearchIntegrator#getLuceneWorkSerializer() >> >> [this method doesn't exist yet, but I'm thinking of adding it for our >> convenience and the following other points] > > > It's not clear to me when you'd provide such convenience getter and when > not. What's the criteria for it? It appears you consider different > categories of services? Indeed this bothers me: "Service" is a general purpose abstraction, and in practice several components could be refactored to become a Service, while also many Service(s) could be refactored to not be one. Drawing a well defined line is not practical. Take a look at the ServiceIntegrator: why do we have a getErrorHandler(), and why is that not a Service? (hint: historical reasons) Even better, look at ImmutableSearchFactory: it's a placeholder for many things which could be services. Why is TimeoutExceptionFactory not a Service? The problem is twofold: - it's unclear - we keep discussing these stuff, while it has very low value to the end users So my take is going to be a pragmatic one: having getters on `ServiceIntegrator` is an approach which worked very well so far and I don't feel the need to be moving everything into a "Services" model. I do like the Services abstraction as a way to allow SPIs (think Infinispan Query, but also beyond) to customize and override internal components. Another benefit of Services is that one custom component might need to lookup another custom component, and this code living outside of the `engine` module you can't add a getter for all your custom stuff. Example: see the services defined by the JGroups backend: `NodeSelectorService` and `MessageSenderService` are very specific to the design of this backend, and depend on JGroups. Clearly something like a "ClassLoaderService" is useful to a wide scope and having a simple getter is just simpler. What I think was a mistake, is to allow exposing the ServiceManager to SPI as it is prone to abuse: while we know that a FieldBridgeFactory will need the ability to instantiate classes by name, that means it needs access to a ClassLoaderService but today we're passing it the whole ServiceManager ; this opens the door for lookup of other services, and we get quickly entangled in complex dependency graphs. There are some cases of valid inter-service dependencies, but these are very limited (e.g. the above JGroups services). So I'm not proposing to scrap this capability from the ServiceManager as it is a very useful thing, yet I don't see why e.g. the FieldBridgeFactory needs more than one trivial line of code to load the classes it needs. Alternatively, we could see to refactor those few Services which need additional services to not need this anymore - yet I don't see why since we have a beautiful ServiceManager which can do such things :) > Personally, I'd like if each service would obtain the other services it > depends on through its constructor. Then it can store the dependencies in > (final) fields and reference them as needed without any sort of look-up. > Services would not have to deal with the service manager anymore, they'd > just get those services they need. One thing I dislike about the current > approach is that you cannot make services fully immutable via final fields > if you depend on other services. It's a great idea. We should do that, but again since we don't have much time I'm forced to keep it practical :-( If you have time to propose a KISS patch (we're not in the business of DI frameworks) I'd love to apply it but remember our priority is Elasticsearch at this point.. I merely had to start this thread to clarify were I'd like to go with e.g. the JestClient and the SerializerService. >> P.S. we're only maintaining - and bundling - a single Serializer >> implementation so it's no surprise that we can handle only one.. yet >> this implies people wanting to override it have to either hack our >> bootstrap or physically remove our implementation. >> >> # A Service implementation can be provided by having it injected at >> bootstrap (i.e. >> org.hibernate.search.cfg.spi.SearchConfiguration.getProvidedServices() >> ) >> >> Not a new rule either: repeating for clarity. We call these "provided" >> services. >> >> # If a service isn't "provided", then we attempt to create one using >> java.util.ServiceLoader >> >> Currently this expects a single implementation to be available: >> there's no way to pick which one if there are multiple implementations >> on the classpath. >> I think we'll need to be able to pass a "hint" or similar to the >> requestService to allow expression of preferences, handle shortnames, >> etc.. a proposal for that will follow when there will be need: at this >> point it's important to clarify the limitation, as this expresses what >> a Service is not able to model today. > > > +1 for shaping requirements around this once it's needed. Atm. it appears a > bit blurry to me. There was no request for this, but to unblur the problem: say a power user wants to plug in its own SerializerService implementation, and bundles it with its app to deploy on WildFly. He'll get an exception as now there are two providers for the same service, and he can't easily "remove" the other one as it's provided by the app server. He can't override the provided services either, as the JPA context is booted by the app server. Would be nicer to have a property to allow picking which implementation to use, rather than throw exceptions. >> >> >> Currently implementations are looked up "on demand". I plan to allow >> "pre-initialize" services as it removes some trouble; these components >> could have convenience getters, not least to remove the concurrency >> overhead. >> Remember that since there's only one implementation for a given type >> around, there's no reason to not do this: the intent of the Service >> contract is to allow people to inject a customized implementation. > > > Sounds good. > >> # If a Service implementation also implements Startable, or Stoppable, >> we'll invoke the respective methods once at start and/or at stop of >> the Search instance - unless they are provided in which case they are >> ignored. >> >> The current javadoc suggests that it's illegal for a provided >> implementation to also implement Startable and/or Stoppable; I don't >> remember why that was, but today it seems unfitting: people might want >> to extend one of our implementations, or reuse some of the >> implementations normally auto-started but reuse them "by instance" by >> providing them to multiple Search instances to save memory (we >> actually have a need for this for Index Affinity in Infinispan). >> The important concept which will survive, is that we don't start or >> stop stuff which is provided as that's clearly responsibility of >> another component. > > > Why is this? Above you say it's unfitting? I'm not quite clear on the > proposed direction. It's very simple: say I want to extend JestClient and use my custom implementation, e.g. I am experimenting with some http pooling capabilities which Search doesn't have. I can ignore the start, and initialize it my own way.. but Search will refuse this Service instance as it's also inheriting @Startable. I'd prefer to allow people to inject their own stuff without being overly strict; BTW the JestClient service isn't using an interface to identify itself so users will need to extend it .. it's a limitation I think we need to fix, we've always been very friendly to allow people to override components. > >> # All non-provided Services will be stopped once, and only once as >> final step when the SearchIntegrator is stopped. >> >> This is a significant difference with today's code: we expect the >> Service consumers to "open / close", hopefully in a finally block, to >> the point that Gunnar enhanced it to at least allow AutoClose >> semantics. >> Yet, I don't want runtime code to open and close these frequently as >> it has been a bottleneck in the past. > > > +1 for setting up the graph once and avoiding all the request/release > hassle. Ideally with "constructor injection" as described above. +1 >> >> It also led to the creations of issues like HSEARCH-1589 : we might >> start/stop the same service frequently, and need to improve with >> reference counters. >> >> I suspect that historically the reasoning was to make sure that the >> order of teardown would follow the inverse order of bootstrap as >> components would cleanup after themselves, but having clarified that >> Service instances are unique globally, should also imply that their >> state doesn't depend on other Services. So the teardown order doesn't >> matter anymore.. we'll start one for each, but only close it at >> shutdown. > > > I'm not following on that one. Provided one service uses another and stores > it in a field, tear down order may matter indeed (if a service is using > another one in its close() logic). It'd be resolved easily if circles are > forbidden. Right those services depending on others might still need it. We might still need reference counters, or at least differentiate for those services which are frequently looked up and could bypass them. > >> # Hierarchy? >> >> We've talked about global components so far. It's clear that the >> IndexManager has a central role in the overall architecture, as we >> tend to allow per-index customisations. Or per-family customisations, >> as suggested in my previous email. >> >> An example which affects Service: >> The "JestClient client" [the Service we use to connect to >> Elasticsearch] could be considered a good fit for being a "Service" as >> this allows people to override the client implementation and/or inject >> a pre-configured instance.. yet it's not a good fit if we want to >> allow people to connect to different hosts for different indexes. >> >> I don't plan to implement the hierarchical ServiceManager right now, >> but proposing it already so that we can agree on the above cleanups in >> contract, with the perspective that there are cleaner solutions also >> for the scoped use case. > > > It's an interesting idea. The granularity of the hierarchy would have to be > discussed. Would you e.g. have one service manager per index which inherits > the global one? > >> Implementing these changes resolves or obsoletes at least 10 JIRA >> issues in one shot.. > > > What is your plan for this? Which ones do you plan to address as of 5.6, > (5.7), 6 or farther in the future? Implementing this plan has no visible benefit to end users, other than say be able to override the JestClient but that can be achieved by implementing just one step. So, purely practical oriented: 1) make you all aware of the limitations of Service to get the new code in the right direction 2) simplify things which give us benefit in new coding 3) move to the above plan iteratively, prioritizing what we need e.g. I need https://github.com/hibernate/hibernate-search/pull/1082 for various other reasons so I did it already. Thanks, Sanne From sanne at hibernate.org Wed Apr 27 10:13:21 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Apr 2016 15:13:21 +0100 Subject: [hibernate-dev] "Service" in Hibernate Search: history, lessons learned and rewrite In-Reply-To: <20160427123441.GA2401@nineveh.local> References: <20160427123441.GA2401@nineveh.local> Message-ID: I can't mention Service w/o getting your attention :) On 27 April 2016 at 13:34, Hardy Ferentschik wrote: > Hi, > >> Yet it is a good idea nowadays to have LuceneWorkSerializer extend >> Service, as we dropped that level of flexibility. This implies that >> there's a single type of serializer (at most) > > Ok > >> and it's totally fine to expose this as: >> SearchIntegrator#getLuceneWorkSerializer() > > How is that related to the service discussion and why do you want to offer it. > What is the benefit? The SearchIntegrator already gives access to the ServiceManager > from where the serializer can be retrieved. Why exposing an explicit getter? > Are you going to add getters for all services? Would this getter do something > different than accessing the service manager? I hope the reply to Gunnar qualifies here too: it's indeed a thin line but it's equally unclear when something should (not) be a Service. There are some cases in which one can only user the Service, so these would never able to get a Getter. > > On a tangent, the whole serialization framework would need an overhaul, especially > the Serializer and Deserializer interfaces. They are very tightly coupled on how > Avro works and tbh they are quite convoluted. +1 I wouldn't mind allowing the "backendqueue" to make its own arrangements, i.e. not mandate the contract anymore. We just need to provide at least one implementation, but others - especially if not interested in Avro - should be able to do something very different. We're also working to remove the Apache Document as something exposed to FieldBridge: by doing so, we could generate the actual Document only at receive side, and not have to serialize Apache code anymore but serialize an easier structure. > >> # A Service implementation can be provided by having it injected at >> bootstrap (i.e. >> org.hibernate.search.cfg.spi.SearchConfiguration.getProvidedServices() >> ) >> >> Not a new rule either: repeating for clarity. We call these "provided" services. > > One thing, I was never happy about was that provided services get a sopecial treatment > in the service manager. They can returned first, provided they match the requested service > type and they are don't get "released" (meaning they don't take part in the reference counting). > I think services which are managed by the service manager should be treated equal. > Maybe that becomes possible now that you consider dropping the reference counting, which > I think is a good idea. We need a way to have people override an internal component by handing in an instance: this was the very reason to create this Service manager. An example, is people running many instances of Search in the same JVM (many apps in an app server?) they can share some instances, provided we identify some components worth it. I can't think of such a component consuming enough memory to warrant doing this in our "traditional" use case (paired up with Hibernate ORM) but there are several heavy weight components which could be shared in the Infinispan use case. >> Currently this expects a single implementation to be available: >> there's no way to pick which one if there are multiple implementations >> on the classpath. > > We have been discussing to extend the implementation once the needs arises to > allow multiple service implementation to be available on the classpath in which > case the user must provide additional configuration to allow to select the correct > implementation. So far there was no need to add this, but maybe now!? There isn't specific need yet, I'm just pointing out to the newcomers to be aware of this :) > >> Currently implementations are looked up "on demand". I plan to allow >> "pre-initialize" services as it removes some trouble; > > What exactly does that mean? Didn't we have this discussion before? > Which troubles are you talking about? > >> not least to remove the concurrency overhead. > > This argument could of course not be missed out ;-) > >> # If a Service implementation also implements Startable, or Stoppable, >> we'll invoke the respective methods once at start and/or at stop of >> the Search instance - unless they are provided in which case they are >> ignored. > > This is something I never full understood. If a provided services does not > want to get started/stopped would it then just not implement these interfaces? Yes there are ways around, but it seems more practical to just allow it. As mentioned in my other reply, it's not always easy to implement it the "clean way" you suggest - not least if someone is skilled enough to want to override components, should be able to figure the limitations out. > >> The current javadoc suggests that it's illegal for a provided >> implementation to also implement Startable and/or Stoppable; I don't >> remember why that was, but today it seems unfitting > > Illegal might be the wrong term. It probably should say that it should not > implement them if it does not want to have these callbacks invoked. Which is > pretty much obvious. AFAIR, there was a discussion that we never should start/stop > a provided service and hence this wording, but I think in code we never enforced it. It currently enforces it, and we even have unit tests to make sure of it :) > >> The important concept which will survive, is that we don't start or >> stop stuff which is provided as that's clearly responsibility of >> another component. > > Then it should not implement Startable/Stopable and if it does, it should be > noops. > >> # All non-provided Services will be stopped once, and only once as >> final step when the SearchIntegrator is stopped. > > +1 > >> This is a significant difference with today's code: we expect the >> Service consumers to "open / close", hopefully in a finally block, to >> the point that Gunnar enhanced it to at least allow AutoClose >> semantics. > > I think this is still a good practice. I'd keep the API like this, > but don't do reference counting and stop the service each time the > count reaches 0. Instead, as you say, stop all services at a final > shutdown. Yea, I think the API is fitting. The main problem I'm seeing is confusion about when it's appropriate to make one.. The cases which I don't like the open/close is when some code blocks need a service within the scope of a single method call. As you say, long-lived components should grab a reference and reuse it over time, then finally release it, but e.g. ClassLoaderService is often needed "one shot" e.g. to setup a component.. which is were I think a simple getter - which also bypasses reference counting - would be more useful. > >> I don't plan to implement the hierarchical ServiceManager right now, >> but proposing it already so that we can agree on the above cleanups in >> contract, with the perspective that there are cleaner solutions also >> for the scoped use case. > > What do you even understand under a hierarchical index manager? > >> Implementing these changes resolves or obsoletes at least 10 JIRA >> issues in one shot.. > > Really? Ok, just 8 after closer inspection :) > > --Hardy > From sanne at hibernate.org Wed Apr 27 10:14:35 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 27 Apr 2016 15:14:35 +0100 Subject: [hibernate-dev] Community newsletter contribution In-Reply-To: References: Message-ID: Thanks Vlad, good idea! On 27 April 2016 at 11:33, Vlad Mihalcea wrote: > Hi, > > I wanted to ask everyone to let me know if you'd like to include any > resource in the Community newsletter. > If you stumble on a blog post, forum or StackOverflow question, that you > happened to like and was worth sharing, you can send it to me, and I'll > include it in the next edition. > > Thanks, > Vlad > _______________________________________________ > 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 Apr 28 04:58:28 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 28 Apr 2016 11:58:28 +0300 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core Message-ID: Hi, While reviewing this PR: https://github.com/hibernate/hibernate-orm/pull/1198/files I realized that we have some static fields which might cause some problems when we deploy two or more SessionFactories in the same container (e.g. Spring). The fix suggests that we should use synchronised, as indicated by Sonar, but I think we should avoid the static fields altogether. Every instance variable must be confined to an object that's confined to the same SessionFactory root object. Without static fields, we can make sure that nothing escapes a given SessionFactory. Let me know what you think. Vlad From sanne at hibernate.org Thu Apr 28 06:05:24 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Apr 2016 11:05:24 +0100 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core In-Reply-To: References: Message-ID: Hi Vlad, there are several components which can safely use static fields, of course as you say only if their state is not affected by which SessionFactory is using them. So I would agree on treating those with care: it should always be a warning sign during code reviews and warrant an in-depth check, but ultimately it's a reasonable way to save some resources (both CPU and memory) - especially when the same JVM runs multiple SessionFactory instances. Sure, savings might be small but when the component is clearly stateless: why not. I would assume this is a technical detail which we can handle without needing to make a blanket statement. +1 to avoid such tricks when it's not trivial to assert its safety, yet there are valid use cases. Looking at the specific case: the usage of "private static Method memberMethod;" [1] seems dodgy indeed. Synchronization is clearly not the best solution, as it would create a contention point were there's no need to create one. It would even contend across multiple SessionFactory instances which is worse than usual :) Indeed the code is "racy" as different threads might need to repeat the effort of finding the reference to "memberMethod", it would have been better to make the field "volatile" to ensure different threads would see it; yet the code is not functionally incorrect as any thread invoking that method will behave the same, and retrieve the right value. Better yet than volatile, make the "memberMethod" field Final, have it initialized statically and move it to the top.. not sure why there are fields hiding in the mid of a class :) BTW this is a good example of sane usage of static (final) fields: it doesn't matter which SessionFactory is running or how it's configured, but it's a good thing that different SessionFactory instances won't have to repeat the initialization of that field over and over. Thanks, Sanne 1 - https://github.com/hibernate/hibernate-orm/pull/1198/files#diff-9f3d2f3cd0828afe20be0db68694f7a0L151 On 28 April 2016 at 09:58, Vlad Mihalcea wrote: > Hi, > > While reviewing this PR: > > https://github.com/hibernate/hibernate-orm/pull/1198/files > > I realized that we have some static fields which might cause some problems > when we deploy two or more SessionFactories in the same container (e.g. > Spring). > The fix suggests that we should use synchronised, as indicated by Sonar, > but I think we should avoid the static fields altogether. > > Every instance variable must be confined to an object that's confined to > the same SessionFactory root object. > Without static fields, we can make sure that nothing escapes a given > SessionFactory. > > Let me know what you think. > > Vlad > _______________________________________________ > 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 Apr 28 06:57:20 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Thu, 28 Apr 2016 13:57:20 +0300 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core In-Reply-To: References: Message-ID: Hi, I agree with. I'll open a new issue and link to this PR and your comment as well. Vlad On Thu, Apr 28, 2016 at 1:05 PM, Sanne Grinovero wrote: > Hi Vlad, > > there are several components which can safely use static fields, of > course as you say only if their state is not affected by which > SessionFactory is using them. > > So I would agree on treating those with care: it should always be a > warning sign during code reviews and warrant an in-depth check, but > ultimately it's a reasonable way to save some resources (both CPU and > memory) - especially when the same JVM runs multiple SessionFactory > instances. > Sure, savings might be small but when the component is clearly > stateless: why not. > > I would assume this is a technical detail which we can handle without > needing to make a blanket statement. > > +1 to avoid such tricks when it's not trivial to assert its safety, > yet there are valid use cases. > > > Looking at the specific case: > the usage of "private static Method memberMethod;" [1] seems dodgy indeed. > Synchronization is clearly not the best solution, as it would create a > contention point were there's no need to create one. It would even > contend across multiple SessionFactory instances which is worse than > usual :) > > Indeed the code is "racy" as different threads might need to repeat > the effort of finding the reference to "memberMethod", it would have > been better to make the field "volatile" to ensure different threads > would see it; > yet the code is not functionally incorrect as any thread invoking that > method will behave the same, and retrieve the right value. > > Better yet than volatile, make the "memberMethod" field Final, have it > initialized statically and move it to the top.. not sure why there are > fields hiding in the mid of a class :) > > BTW this is a good example of sane usage of static (final) fields: it > doesn't matter which SessionFactory is running or how it's configured, > but it's a good thing that different SessionFactory instances won't > have to repeat the initialization of that field over and over. > > Thanks, > Sanne > > 1 - > https://github.com/hibernate/hibernate-orm/pull/1198/files#diff-9f3d2f3cd0828afe20be0db68694f7a0L151 > > On 28 April 2016 at 09:58, Vlad Mihalcea wrote: > > Hi, > > > > While reviewing this PR: > > > > https://github.com/hibernate/hibernate-orm/pull/1198/files > > > > I realized that we have some static fields which might cause some > problems > > when we deploy two or more SessionFactories in the same container (e.g. > > Spring). > > The fix suggests that we should use synchronised, as indicated by Sonar, > > but I think we should avoid the static fields altogether. > > > > Every instance variable must be confined to an object that's confined to > > the same SessionFactory root object. > > Without static fields, we can make sure that nothing escapes a given > > SessionFactory. > > > > Let me know what you think. > > > > Vlad > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From gunnar at hibernate.org Thu Apr 28 07:15:01 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 28 Apr 2016 13:15:01 +0200 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core In-Reply-To: References: Message-ID: Or, yet better, change the method definition in the upstream component (HCANN) so its accessible without jumping through reflective hoops. --Gunnar 2016-04-28 12:57 GMT+02:00 Vlad Mihalcea : > Hi, > > I agree with. > > I'll open a new issue and link to this PR and your comment as well. > > Vlad > > On Thu, Apr 28, 2016 at 1:05 PM, Sanne Grinovero > wrote: > > > Hi Vlad, > > > > there are several components which can safely use static fields, of > > course as you say only if their state is not affected by which > > SessionFactory is using them. > > > > So I would agree on treating those with care: it should always be a > > warning sign during code reviews and warrant an in-depth check, but > > ultimately it's a reasonable way to save some resources (both CPU and > > memory) - especially when the same JVM runs multiple SessionFactory > > instances. > > Sure, savings might be small but when the component is clearly > > stateless: why not. > > > > I would assume this is a technical detail which we can handle without > > needing to make a blanket statement. > > > > +1 to avoid such tricks when it's not trivial to assert its safety, > > yet there are valid use cases. > > > > > > Looking at the specific case: > > the usage of "private static Method memberMethod;" [1] seems dodgy > indeed. > > Synchronization is clearly not the best solution, as it would create a > > contention point were there's no need to create one. It would even > > contend across multiple SessionFactory instances which is worse than > > usual :) > > > > Indeed the code is "racy" as different threads might need to repeat > > the effort of finding the reference to "memberMethod", it would have > > been better to make the field "volatile" to ensure different threads > > would see it; > > yet the code is not functionally incorrect as any thread invoking that > > method will behave the same, and retrieve the right value. > > > > Better yet than volatile, make the "memberMethod" field Final, have it > > initialized statically and move it to the top.. not sure why there are > > fields hiding in the mid of a class :) > > > > BTW this is a good example of sane usage of static (final) fields: it > > doesn't matter which SessionFactory is running or how it's configured, > > but it's a good thing that different SessionFactory instances won't > > have to repeat the initialization of that field over and over. > > > > Thanks, > > Sanne > > > > 1 - > > > https://github.com/hibernate/hibernate-orm/pull/1198/files#diff-9f3d2f3cd0828afe20be0db68694f7a0L151 > > > > On 28 April 2016 at 09:58, Vlad Mihalcea > wrote: > > > Hi, > > > > > > While reviewing this PR: > > > > > > https://github.com/hibernate/hibernate-orm/pull/1198/files > > > > > > I realized that we have some static fields which might cause some > > problems > > > when we deploy two or more SessionFactories in the same container (e.g. > > > Spring). > > > The fix suggests that we should use synchronised, as indicated by > Sonar, > > > but I think we should avoid the static fields altogether. > > > > > > Every instance variable must be confined to an object that's confined > to > > > the same SessionFactory root object. > > > Without static fields, we can make sure that nothing escapes a given > > > SessionFactory. > > > > > > Let me know what you think. > > > > > > Vlad > > > _______________________________________________ > > > 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 hardy at hibernate.org Thu Apr 28 08:38:19 2016 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 28 Apr 2016 14:38:19 +0200 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core In-Reply-To: References: Message-ID: <20160428123819.GA5974@nineveh.local> Hi, On Thu, 28-Apr-2016 13:15, Gunnar Morling wrote: > Or, yet better, change the method definition in the upstream component > (HCANN) so its accessible without jumping through reflective hoops. +1 :-) --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160428/8b5e703c/attachment-0001.bin From steve at hibernate.org Thu Apr 28 08:49:54 2016 From: steve at hibernate.org (Steve Ebersole) Date: Thu, 28 Apr 2016 12:49:54 +0000 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core In-Reply-To: <20160428123819.GA5974@nineveh.local> References: <20160428123819.GA5974@nineveh.local> Message-ID: Or better better yet let's get moving from HCANN to Jandex! :) Bottom line, this depends on specific cases. On Thu, Apr 28, 2016 at 7:38 AM Hardy Ferentschik wrote: > Hi, > > On Thu, 28-Apr-2016 13:15, Gunnar Morling wrote: > > Or, yet better, change the method definition in the upstream component > > (HCANN) so its accessible without jumping through reflective hoops. > > +1 :-) > > --Hardy > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev From hardy at hibernate.org Thu Apr 28 10:15:36 2016 From: hardy at hibernate.org (Hardy Ferentschik) Date: Thu, 28 Apr 2016 16:15:36 +0200 Subject: [hibernate-dev] Usage of static fields throughout Hibernate Core In-Reply-To: References: <20160428123819.GA5974@nineveh.local> Message-ID: <20160428141536.GA6653@nineveh.local> On Thu, 28-Apr-2016 12:49, Steve Ebersole wrote: > Or better better yet let's get moving from HCANN to Jandex! :) Amen! :-) --Hardy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 496 bytes Desc: not available Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20160428/de22db31/attachment.bin From sanne at hibernate.org Thu Apr 28 16:59:07 2016 From: sanne at hibernate.org (Sanne Grinovero) Date: Thu, 28 Apr 2016 21:59:07 +0100 Subject: [hibernate-dev] Jackson vs Gson Message-ID: I'm wondering why the Elasticsearch client for Hibernate Search is using Gson, and not Jackson as JSON codec? Especially as we already have Jackson as a dependency for both Search (via Avro), OGM (via Couchbase), and it's also used within WildFly and Camel, we might need to change this. Sorry if I forgot the reasons, I vaguely remember this came up but I couldn't find it on the list. Thanks, Sanne From bhuvangu at gmail.com Fri Apr 29 00:10:46 2016 From: bhuvangu at gmail.com (Bhuvan Gupta) Date: Fri, 29 Apr 2016 09:40:46 +0530 Subject: [hibernate-dev] hibernate and transaction using method annotation Message-ID: Hello All, Link to question and discussion: http://stackoverflow.com/questions/36920695/hibernate-and-transaction-using-method-annotation Below i have pasted whats in the link: Help/suggestion/advise/data points is really appreciated. Thanks in Advance: ------------------------------------------ Firstly, I have given few data points. Next will be the problem described. ------------------------------ *DATA POINTS:* *[D1]* In Hibernate and Annotation and managed objects world, what i have seen a common pattern like @Transactionalpublic void createStuff(..){// get entity manager and call persist and other operatation}@Transactionalpublic SomeDtoObject getStuff(..){// get entity manager and call find and getter to polulate a object to return} In managed beans the Hibernate transaction is started and commited when we call this methods. Hibernate doc says (link ): The most common pattern in a multi-user client/server application is session-per-request. *[D2]* Also it is advised that connection to database should be pooled using connection pool library C3P0 as stated on postgres documentation (link ): Pg will usually complete the same 10,000 transactions faster by doing them 5, 10 or 20 at a time than by doing them 500 at a time. *[D3]* Also with JDBC *Given a single connection we can run one transaction at a time and as many statement as we like within that transaction.Its upto the application(C3P0) to make sure that two different thread executing two different transactional method should not use same connection and one should wait before calling the other method .* ------------------------------ *Problem:* Now if we use the managed bean transaction pattern using annotation along with a connection pool(*Let say only with 1 connection*) with hibernate and session-per-request Also let say the code is something like @Transactionalpublic SomeDtoObject getStuff(..){// get entity manager and call find and getter to polulate a object to returnSomeEntity se = entityManager.find(someentity, primaryKey);//create Dtos// access someEntity to all over this method to create SomeDtoObject that we have to return.// also may access some file on system to fetch some data is order to populate someDtoObject.// overall let say the method take 150 milli second to do all its work} Now imagine there are two different thread(T1, T2) called for getStuff(...) T1 will enter the method and will acquire jdbc connection from connection pool. And when T2 will reach entityManager.find the C3P0 will check that there is no connection left it will put T2 on hold till T1 complete the execution which will take around 150 milli second. Ideally, Given that getStuff(...) is going to do read only querys, both thread can use same connection and dont hold thread from executing queries. In above case we are keep that connection idle and also keeping the thread to wait. *MAIN QUESTION* *Is there a way i can say to hibernate that a particular hibernate transaction is readonly and hibernate can then reuse an already acquired connection instead of asking for a new connection from the connection pool ?* ------------------------------ *Few solution found/suggested:(not convincing)* 1 If you are so much worried, dont use transaction using annotation, use hibernate session yourself..... no i like that pattern :) 2 Hibernate provide a ConnectionReleaselink option which can be set to after_statement. *First* Hibernate C3P0 connection pool provider does not support after_statement. *Second* it will be a overhead just release and reacquire a connection. From mihalcea.vlad at gmail.com Fri Apr 29 02:16:29 2016 From: mihalcea.vlad at gmail.com (Vlad Mihalcea) Date: Fri, 29 Apr 2016 09:16:29 +0300 Subject: [hibernate-dev] hibernate and transaction using method annotation In-Reply-To: References: Message-ID: Hi, I answered your question on SO, but, next time, please use the forum ( https://forum.hibernate.org/ ) or Twitter to send the SO question link. This mailing list is dedicated to discussions about developing Hibernate. Thanks, Vlad On Fri, Apr 29, 2016 at 7:10 AM, Bhuvan Gupta wrote: > Hello All, > > Link to question and discussion: > > > http://stackoverflow.com/questions/36920695/hibernate-and-transaction-using-method-annotation > > Below i have pasted whats in the link: > > Help/suggestion/advise/data points is really appreciated. > > Thanks in Advance: > > ------------------------------------------ > > Firstly, I have given few data points. > Next will be the problem described. > ------------------------------ > > *DATA POINTS:* > *[D1]* In Hibernate and Annotation and managed objects world, what i have > seen a common pattern like > > @Transactionalpublic void createStuff(..){// get entity manager and > call persist and other operatation}@Transactionalpublic SomeDtoObject > getStuff(..){// get entity manager and call find and getter to > polulate a object to return} > > In managed beans the Hibernate transaction is started and commited when we > call this methods. > > Hibernate doc says (link > < > https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html > > > ): > > The most common pattern in a multi-user client/server application is > session-per-request. > > *[D2]* Also it is advised that connection to database should be pooled > using connection pool library C3P0 as stated on postgres documentation > (link > ): > > Pg will usually complete the same 10,000 transactions faster by doing them > 5, 10 or 20 at a time than by doing them 500 at a time. > > *[D3]* Also with JDBC > > *Given a single connection we can run one transaction at a time and as many > statement as we like within that transaction.Its upto the application(C3P0) > to make sure that two different thread executing two different > transactional method should not use same connection and one should wait > before calling the other method .* > ------------------------------ > > *Problem:* > Now if we use the managed bean transaction pattern using annotation along > with a connection pool(*Let say only with 1 connection*) with hibernate and > session-per-request > Also let say the code is something like > > @Transactionalpublic SomeDtoObject getStuff(..){// get entity manager > and call find and getter to polulate a object to returnSomeEntity se = > entityManager.find(someentity, primaryKey);//create Dtos// access > someEntity to all over this method to create SomeDtoObject that we > have to return.// also may access some file on system to fetch some > data is order to populate someDtoObject.// overall let say the method > take 150 milli second to do all its work} > > Now imagine there are two different thread(T1, T2) called for getStuff(...) > T1 will enter the method and will acquire jdbc connection from connection > pool. > And when T2 will reach entityManager.find the C3P0 will check that there is > no connection left it will put T2 on hold till T1 complete the execution > which will take around 150 milli second. > > Ideally, Given that getStuff(...) is going to do read only querys, both > thread can use same connection and dont hold thread from executing queries. > In above case we are keep that connection idle and also keeping the thread > to wait. > > *MAIN QUESTION* > *Is there a way i can say to hibernate that a particular hibernate > transaction is readonly and hibernate can then reuse an already acquired > connection instead of asking for a new connection from the connection pool > ?* > ------------------------------ > > *Few solution found/suggested:(not convincing)* > > 1 > < > https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html > > > If > you are so much worried, dont use transaction using annotation, use > hibernate session yourself..... no i like that pattern :) > 2 Hibernate > provide a ConnectionReleaselink > < > https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html#transactions-connection-release > > > option > which can be set to after_statement. > *First* Hibernate C3P0 connection pool provider does not support > after_statement. > *Second* it will be a overhead just release and reacquire a connection. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > From bhuvangu at gmail.com Fri Apr 29 02:35:19 2016 From: bhuvangu at gmail.com (Bhuvan Gupta) Date: Fri, 29 Apr 2016 12:05:19 +0530 Subject: [hibernate-dev] hibernate and transaction using method annotation In-Reply-To: References: Message-ID: Got it On Fri, Apr 29, 2016 at 11:46 AM, Vlad Mihalcea wrote: > Hi, > > I answered your question on SO, but, next time, please use the forum ( > https://forum.hibernate.org/ ) or Twitter to send the SO question link. > This mailing list is dedicated to discussions about developing Hibernate. > > Thanks, > Vlad > > On Fri, Apr 29, 2016 at 7:10 AM, Bhuvan Gupta wrote: > >> Hello All, >> >> Link to question and discussion: >> >> >> http://stackoverflow.com/questions/36920695/hibernate-and-transaction-using-method-annotation >> >> Below i have pasted whats in the link: >> >> Help/suggestion/advise/data points is really appreciated. >> >> Thanks in Advance: >> >> ------------------------------------------ >> >> Firstly, I have given few data points. >> Next will be the problem described. >> ------------------------------ >> >> *DATA POINTS:* >> *[D1]* In Hibernate and Annotation and managed objects world, what i have >> seen a common pattern like >> >> @Transactionalpublic void createStuff(..){// get entity manager and >> call persist and other operatation}@Transactionalpublic SomeDtoObject >> getStuff(..){// get entity manager and call find and getter to >> polulate a object to return} >> >> In managed beans the Hibernate transaction is started and commited when we >> call this methods. >> >> Hibernate doc says (link >> < >> https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html >> > >> ): >> >> The most common pattern in a multi-user client/server application is >> session-per-request. >> >> *[D2]* Also it is advised that connection to database should be pooled >> using connection pool library C3P0 as stated on postgres documentation >> (link >> ): >> >> Pg will usually complete the same 10,000 transactions faster by doing them >> 5, 10 or 20 at a time than by doing them 500 at a time. >> >> *[D3]* Also with JDBC >> >> *Given a single connection we can run one transaction at a time and as >> many >> statement as we like within that transaction.Its upto the >> application(C3P0) >> to make sure that two different thread executing two different >> transactional method should not use same connection and one should wait >> before calling the other method .* >> ------------------------------ >> >> *Problem:* >> Now if we use the managed bean transaction pattern using annotation along >> with a connection pool(*Let say only with 1 connection*) with hibernate >> and >> session-per-request >> Also let say the code is something like >> >> @Transactionalpublic SomeDtoObject getStuff(..){// get entity manager >> and call find and getter to polulate a object to returnSomeEntity se = >> entityManager.find(someentity, primaryKey);//create Dtos// access >> someEntity to all over this method to create SomeDtoObject that we >> have to return.// also may access some file on system to fetch some >> data is order to populate someDtoObject.// overall let say the method >> take 150 milli second to do all its work} >> >> Now imagine there are two different thread(T1, T2) called for >> getStuff(...) >> T1 will enter the method and will acquire jdbc connection from connection >> pool. >> And when T2 will reach entityManager.find the C3P0 will check that there >> is >> no connection left it will put T2 on hold till T1 complete the execution >> which will take around 150 milli second. >> >> Ideally, Given that getStuff(...) is going to do read only querys, both >> thread can use same connection and dont hold thread from executing >> queries. >> In above case we are keep that connection idle and also keeping the thread >> to wait. >> >> *MAIN QUESTION* >> *Is there a way i can say to hibernate that a particular hibernate >> transaction is readonly and hibernate can then reuse an already acquired >> connection instead of asking for a new connection from the connection pool >> ?* >> ------------------------------ >> >> *Few solution found/suggested:(not convincing)* >> >> 1 >> < >> https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html >> > >> If >> you are so much worried, dont use transaction using annotation, use >> hibernate session yourself..... no i like that pattern :) >> 2 Hibernate >> provide a ConnectionReleaselink >> < >> https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/transactions.html#transactions-connection-release >> > >> option >> which can be set to after_statement. >> *First* Hibernate C3P0 connection pool provider does not support >> after_statement. >> *Second* it will be a overhead just release and reacquire a connection. >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > From gunnar at hibernate.org Fri Apr 29 03:24:27 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 29 Apr 2016 09:24:27 +0200 Subject: [hibernate-dev] Jackson vs Gson In-Reply-To: References: Message-ID: Gson is used by Jest (our client for talking to Elasticsearch) internally. So we could change our own JSON serialization routines to work with Jackson or even plain StringBuilder if we liked (we took care to make the usage of Gson an implementation detail), but the dependency to Gson would still be needed. We could reconsider the usage of Jest altogether, but I'd hope that's a discussion we can have at a later point, so to focus on getting the first Tech Preview out to users? --Gunnar 2016-04-28 22:59 GMT+02:00 Sanne Grinovero : > I'm wondering why the Elasticsearch client for Hibernate Search is > using Gson, and not Jackson as JSON codec? > > Especially as we already have Jackson as a dependency for both Search > (via Avro), OGM (via Couchbase), and it's also used within WildFly and > Camel, we might need to change this. > > Sorry if I forgot the reasons, I vaguely remember this came up but I > couldn't find it on the list. > > 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 Sat Apr 30 10:06:08 2016 From: steve at hibernate.org (Steve Ebersole) Date: Sat, 30 Apr 2016 14:06:08 +0000 Subject: [hibernate-dev] Various expectation changes in hibernate-core after consolidating hibernate-entitymanager In-Reply-To: References: Message-ID: We are seeing this too in your documentation tests. So its ok to just change those to wrap the writes/flushes in a transaction? (they are not now) On Tue, Apr 26, 2016 at 10:09 AM Vlad Mihalcea wrote: > Hi, > > It's fine if we stick to the JPA spec so that only read ops are allowed to > be executed outside of a transactional context. Most applications use > either Java EE or Spring, so transaction boundaries are usually enforced > anyway. > > It's also fine to throw an exception if the object being checked within > the Persistence Context is not an entity. This might break some existing > use cases, but we are covered by the JPA spec :D > > In the getTransaction() case, I still believe we should offer two > strategies: a JPA and a native one, the choice being made based on the > current bootstrap procedure or some configuration property. > > Vlad > > On Tue, Apr 26, 2016 at 5:53 PM, Steve Ebersole > wrote: > >> 2. "Another change in expectation is in regards to operations outside of >>> a transaction" - in JPA we can execute queries outside a transaction, >>> but any write will fail if there is no transactional context, which is >>> reasonable for me too. If Hibernate allows writes outside of a >>> transactional context, that's definitely a thing we should not support >>> anyway. >>> >> >> Well we'll agree to disagree about the validity of allowing queries >> outside the scope of a transaction; it does not matter, because JPA says it >> should be allowed, so we have to allow that. >> >> However, historically Hibernate allowed writes outside the scope of a >> transaction as well (auto-commit support), so that is what I am talking >> about. After pulling over HEM logic we now have some test failures due to >> tests trying to write data outside of an explicit transaction ( >> javax.persistence.TransactionRequiredException). >> >> So I propose we continue to expect that as a failure starting in 5.2. >> For queries we will continue to supports it, but only because JPA requires >> us to; not because it is a valid concept. >> >> >> >>> 3. "Asking a Session if is contains (Session/EntityManager#contains) a >>> non-entity" - we can handle this with the separate exception handler >>> strategies to retain both JPA and Hibernate behaviors. >>> >> >> Why? This is exactly the kind of thing I have in mind when I talk about >> the unnecessary complexity. Clearly asking if the Session contains a >> boolean e.g. is complete non-sense. If JPA requires that condition to >> throw an exception, why even worry about the other case? >> >> >> >> >>> 4. "Accessing Session/EntityManager#getTransaction. JPA says that is >>> only allowed for JDBC transactions. Hibernate always allows it." - I'd >>> choose the Hibernate behavior because I don;t see how it can cause any >>> issue and it's an enhancement as well. >>> >> >> Well that's great in principle. But JPA actually requires an exception >> be thrown when #getTransaction() is called in the JTA case. So there is no >> simple "just allow it as an extension" solution, we'd have to specific >> allow users to opt-in to allowing that. >> >> >