Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Emmanuel Bernard
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.

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Scott Marlow
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-

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Steve Ebersole
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 exc

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Sanne Grinovero
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

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Emmanuel Bernard
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

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Steve Ebersole
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

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Scott Marlow
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 Jir

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Steve Ebersole
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

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Scott Marlow
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 >

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Gunnar Morling
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 m

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Sanne Grinovero
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 ye

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread 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 i

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Steve Ebersole
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:

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Sanne Grinovero
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 regist

Re: [hibernate-dev] 6.0 planning

2016-04-04 Thread Gunnar Morling
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 Hibernat

Re: [hibernate-dev] 6.0 planning

2016-04-01 Thread Vlad Mihalcea
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

Re: [hibernate-dev] 6.0 planning

2016-04-01 Thread Petar Tahchiev
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.

Re: [hibernate-dev] 6.0 planning

2016-04-01 Thread 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 re

Re: [hibernate-dev] 6.0 planning

2016-04-01 Thread Steve Ebersole
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 bigg

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Gail Badner
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 E

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Steve Ebersole
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 hi

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Gail Badner
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 change

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Steve Ebersole
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

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Steve Ebersole
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, > > > > I

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Steve Ebersole
Possibly. Depends what differences you mean exactly On Thu, Mar 31, 2016, 7:23 AM Vlad Mihalcea wrote: > 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. > Doe

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Petar Tahchiev
+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 Enti

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread 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 wrote:

Re: [hibernate-dev] 6.0 planning

2016-03-31 Thread Hardy Ferentschik
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 di