[hibernate-dev] Jira

A heads up that Atlassian will sometime soon be restarting the Jira instance to fix the 500 errors when accessing project pages. They are aware of the problem and are awaiting a proper fix, but in the meantime they believe a restart will solve the problem in the short term.

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] HHH-10478 : OperationContext

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

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

[hibernate-dev] 5.1 now branched; master is 6.0

Following along the earlier discussion I went ahead and branched off 5.1 and made master baseline Java 8. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

Re: [hibernate-dev] HHH-9440 Support for Java 8: parameter names

On Mon, Mar 28, 2016 at 1:22 PM Lovro Pandzic wrote: > I am confused how you are "mind mapping" PreparedStatement parameters and >> entity construction into the same conversation. We are not instantiating >> entities based on PreparedStatement parameters >> > > I'm

[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

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

So I think for the time being I'd be fine if WF didn't add anything implicitly at all for OGM. 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

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

On 31 March 2016 at 10:09, Davide D'Alto wrote: >> Although I don't see a big issue in demanding to add a specific module >> dependency. It's documented and I don't think I remember any user report >> complaining about it. People also add dependencies to their Maven POM :) >

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

> Although I don't see a big issue in demanding to add a specific module > dependency. It's documented and I don't think I remember any user report > complaining about it. People also add dependencies to their Maven POM :) +1 On Thu, Mar 31, 2016 at 7:39 AM, Gunnar Morling

Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

2016-03-30 18:15 GMT+02:00 Sanne Grinovero : > I'm reviewing how we expect people to use the Hibernate OGM modules on > WildFly. > > Scott mentioned that the JPA subsystem of WildFly automatically adds > the "org.hibernate.ogm" module when the >