Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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 >>>

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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:

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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,

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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. >>

Re: [hibernate-dev] 6.0 planning

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 >>

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

+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 >

Re: [hibernate-dev] 6.0 planning

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

Re: [hibernate-dev] 6.0 planning

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

[hibernate-dev] 6.0 planning

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