1:57 p.m.
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.
2:22 p.m.
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
2:23 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:38 p.m.
+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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)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
2:40 p.m.
Possibly. Depends what differences you mean exactly
On Thu, Mar 31, 2016, 7:23 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com> 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.
Does it mean that we eliminate those differences as well?
Vlad
On Thu, Mar 31, 2016 at 2:57 PM, Steve Ebersole <steve(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
2:43 p.m.
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(a)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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3 p.m.
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 <steve(a)hibernate.org> 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(a)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(a)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(a)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(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
9:28 p.m.
I would like to see OperationContext introduced.
On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole <steve(a)hibernate.org> 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 <steve(a)hibernate.org>
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(a)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(a)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(a)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(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:51 p.m.
Is it ready?
On Thu, Mar 31, 2016, 2:28 PM Gail Badner <gbadner(a)redhat.com> wrote:
I would like to see OperationContext introduced.
On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole <steve(a)hibernate.org>
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 <steve(a)hibernate.org>
> 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(a)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(a)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(a)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(a)lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev(a)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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
10:06 p.m.
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 <steve(a)hibernate.org>
wrote:
Is it ready?
On Thu, Mar 31, 2016, 2:28 PM Gail Badner <gbadner(a)redhat.com> wrote:
> I would like to see OperationContext introduced.
>
> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole <steve(a)hibernate.org>
> 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 <steve(a)hibernate.org>
>> 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(a)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(a)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(a)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(a)lists.jboss.org
>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > >
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev(a)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(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
1:32 p.m.
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 <hardy(a)hibernate.org>
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
9:07 p.m.
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 <gbadner(a)redhat.com> 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 <steve(a)hibernate.org>
wrote:
> Is it ready?
>
> On Thu, Mar 31, 2016, 2:28 PM Gail Badner <gbadner(a)redhat.com> wrote:
>
>> I would like to see OperationContext introduced.
>>
>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole <steve(a)hibernate.org>
>> 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 <steve(a)hibernate.org>
>>> 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(a)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(a)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(a)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(a)lists.jboss.org
>>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> > >
>>> >> > _______________________________________________
>>> >> > hibernate-dev mailing list
>>> >> > hibernate-dev(a)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(a)lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
9:41 p.m.
Is there any plans for reactive support in Hibernate6?
2016-04-01 22:07 GMT+03:00 Steve Ebersole <steve(a)hibernate.org>:
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 <gbadner(a)redhat.com> 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 <steve(a)hibernate.org>
> wrote:
>
>> Is it ready?
>>
>> On Thu, Mar 31, 2016, 2:28 PM Gail Badner <gbadner(a)redhat.com> wrote:
>>
>>> I would like to see OperationContext introduced.
>>>
>>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole <steve(a)hibernate.org>
>>> 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
<steve(a)hibernate.org>
>>>> 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(a)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(a)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(a)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(a)lists.jboss.org
>>>> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> > >
>>>> >> > _______________________________________________
>>>> >> > hibernate-dev mailing list
>>>> >> > hibernate-dev(a)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(a)lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >>
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)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
9:53 p.m.
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 <paranoiabla(a)gmail.com>
wrote:
Is there any plans for reactive support in Hibernate6?
2016-04-01 22:07 GMT+03:00 Steve Ebersole <steve(a)hibernate.org>:
> 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 <gbadner(a)redhat.com> 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 <steve(a)hibernate.org>
> > wrote:
> >
> >> Is it ready?
> >>
> >> On Thu, Mar 31, 2016, 2:28 PM Gail Badner <gbadner(a)redhat.com>
wrote:
> >>
> >>> I would like to see OperationContext introduced.
> >>>
> >>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole
<steve(a)hibernate.org
>
> >>> 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
<steve(a)hibernate.org
>
> >>>> 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(a)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(a)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(a)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(a)lists.jboss.org
> >>>> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>> >> > >
> >>>> >> > _______________________________________________
> >>>> >> > hibernate-dev mailing list
> >>>> >> > hibernate-dev(a)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(a)lists.jboss.org
> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>> >>
> >>>> >
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev(a)lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> >>>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:59 p.m.
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 <steve(a)hibernate.org>:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:55 p.m.
On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org> 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 <steve(a)hibernate.org>:
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:07 p.m.
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 <sanne(a)hibernate.org> wrote:
On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org>
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 <steve(a)hibernate.org>:
>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:08 p.m.
I think this is reasonable. Is there a Jira for it?
On Mon, Apr 4, 2016, 6:59 AM Gunnar Morling <gunnar(a)hibernate.org> 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 <steve(a)hibernate.org>:
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
3:10 p.m.
On 4 April 2016 at 14:07, Steve Ebersole <steve(a)hibernate.org> 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 <sanne(a)hibernate.org> wrote:
>
> On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org> 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 <steve(a)hibernate.org>:
> >
> >> 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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3:24 p.m.
Now there is: https://hibernate.atlassian.net/browse/HHH-10669 :)
Thanks!
2016-04-04 15:08 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
I think this is reasonable. Is there a Jira for it?
On Mon, Apr 4, 2016, 6:59 AM Gunnar Morling <gunnar(a)hibernate.org> 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 <steve(a)hibernate.org>:
>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
4:19 p.m.
On 04/04/2016 08:55 AM, Sanne Grinovero wrote:
On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org>
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 <steve(a)hibernate.org>:
>
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:32 p.m.
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 <smarlow(a)redhat.com> wrote:
On 04/04/2016 08:55 AM, Sanne Grinovero wrote:
> On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org> 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 <steve(a)hibernate.org>:
>>
>>> 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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:37 p.m.
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 <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
On 04/04/2016 08:55 AM, Sanne Grinovero wrote:
> On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org
<mailto:gunnar@hibernate.org>> 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 <steve(a)hibernate.org
<mailto:steve@hibernate.org>>:
>>
>>> 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(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:48 p.m.
So there we go :)
On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smarlow(a)redhat.com> 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 <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
> On 04/04/2016 08:55 AM, Sanne Grinovero wrote:
> > On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org
> <mailto:gunnar@hibernate.org>> 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 <steve(a)hibernate.org
> <mailto:steve@hibernate.org>>:
> >>
> >>> 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(a)lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org <mailto:
hibernate-dev(a)lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
5:29 p.m.
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 <paranoiabla(a)gmail.com>
wrote:
> Is there any plans for reactive support in Hibernate6?
>
> 2016-04-01 22:07 GMT+03:00 Steve Ebersole <steve(a)hibernate.org>:
>
> > 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 <gbadner(a)redhat.com> 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
<steve(a)hibernate.org>
> > > wrote:
> > >
> > >> Is it ready?
> > >>
> > >> On Thu, Mar 31, 2016, 2:28 PM Gail Badner <gbadner(a)redhat.com>
wrote:
> > >>
> > >>> I would like to see OperationContext introduced.
> > >>>
> > >>> On Thu, Mar 31, 2016 at 6:00 AM, Steve Ebersole
<steve(a)hibernate.org
> >
> > >>> 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
<steve(a)hibernate.org
> >
> > >>>> 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(a)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(a)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(a)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(a)lists.jboss.org
> > >>>> >> > >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>> >> > >
> > >>>> >> > _______________________________________________
> > >>>> >> > hibernate-dev mailing list
> > >>>> >> > hibernate-dev(a)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(a)lists.jboss.org
> > >>>> >>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>> >>
> > >>>> >
> > >>>> _______________________________________________
> > >>>> hibernate-dev mailing list
> > >>>> hibernate-dev(a)lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>>
> > >>>
> > >>>
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:36 p.m.
On 4 April 2016 at 15:48, Steve Ebersole <steve(a)hibernate.org> wrote:
So there we go :)
On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smarlow(a)redhat.com> 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!
5:55 p.m.
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 <sanne(a)hibernate.org> wrote:
On 4 April 2016 at 15:48, Steve Ebersole <steve(a)hibernate.org>
wrote:
> So there we go :)
>
> On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smarlow(a)redhat.com> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:25 p.m.
On 04/04/2016 11:36 AM, Sanne Grinovero wrote:
On 4 April 2016 at 15:48, Steve Ebersole <steve(a)hibernate.org>
wrote:
> So there we go :)
>
> On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smarlow(a)redhat.com> 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.
6:36 p.m.
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 <sanne(a)hibernate.org> wrote:
> On 4 April 2016 at 15:48, Steve Ebersole <steve(a)hibernate.org> wrote:
> > So there we go :)
> >
> > On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smarlow(a)redhat.com> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2944
days inactive
2948
days old
28 comments
9 participants
participants (9)
-
Emmanuel Bernard -
Gail Badner -
Gunnar Morling -
Hardy Ferentschik -
Petar Tahchiev -
Sanne Grinovero -
Scott Marlow -
Steve Ebersole -
Vlad Mihalcea