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