2:21 p.m.
Hi all,
This has crossed my mind for a few times: should we provide a programmatic
API in Hibernate ORM for mapping entities, as an alternative mapping
definition source to annotations and XML? I.e. something similar to the
programmatic mapping APIs we have in Hibernate Validator and Search.
It'd probably be a fair bit of work (though giving lots of fun with API
design), but I can see how it could be appealing to folks preferring
API-style ways of configuring their stack, which seems more and more en
vogue these days. Using lambda expressions would be attractive especially
when it comes to plugging in custom behaviours, e.g. for value generators.
Any thoughts?
--Gunnar
4:40 a.m.
Anyone with thoughts on this? To elaborate, here's what I have in mind:
EntityMapping mapping = session.addEntityMapping();
mapping.entity( Person.class )
.table( "PERSONS" )
.property( "personId" )
.id()
.strategy( Strategy.IDENTITY )
.property( "phoneNumbers" )
.oneToMany()
.mappedBy( "person" )
.property( "favouriteColor" )
.converter( ColorConverter.class );
I'm curious whether others think that'd be useful or not.
Vlad, perhaps you have any insights from the field?
Cheers,
--Gunnar
2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
Hi all,
This has crossed my mind for a few times: should we provide a programmatic
API in Hibernate ORM for mapping entities, as an alternative mapping
definition source to annotations and XML? I.e. something similar to the
programmatic mapping APIs we have in Hibernate Validator and Search.
It'd probably be a fair bit of work (though giving lots of fun with API
design), but I can see how it could be appealing to folks preferring
API-style ways of configuring their stack, which seems more and more en
vogue these days. Using lambda expressions would be attractive especially
when it comes to plugging in custom behaviours, e.g. for value generators.
Any thoughts?
--Gunnar
5:30 a.m.
That would be great for framework developers as well.
Il 24 ott 2017 12:01, "Gunnar Morling" <gunnar(a)hibernate.org> ha scritto:
Anyone with thoughts on this? To elaborate, here's what I have in
mind:
EntityMapping mapping = session.addEntityMapping();
mapping.entity( Person.class )
.table( "PERSONS" )
.property( "personId" )
.id()
.strategy( Strategy.IDENTITY )
.property( "phoneNumbers" )
.oneToMany()
.mappedBy( "person" )
.property( "favouriteColor" )
.converter( ColorConverter.class );
I'm curious whether others think that'd be useful or not.
Vlad, perhaps you have any insights from the field?
Cheers,
--Gunnar
2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
> Hi all,
>
> This has crossed my mind for a few times: should we provide a
programmatic
> API in Hibernate ORM for mapping entities, as an alternative mapping
> definition source to annotations and XML? I.e. something similar to the
> programmatic mapping APIs we have in Hibernate Validator and Search.
>
> It'd probably be a fair bit of work (though giving lots of fun with API
> design), but I can see how it could be appealing to folks preferring
> API-style ways of configuring their stack, which seems more and more en
> vogue these days. Using lambda expressions would be attractive especially
> when it comes to plugging in custom behaviours, e.g. for value
generators.
>
> Any thoughts?
>
> --Gunnar
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:08 a.m.
Of course you pick the easy case to illustrate :) A single entity with
nothing but basic attributes or self-referential associations is going to
be relatively simple. The trickier stuff is adding 2 entities with
association between them, "property-ref" FKs, etc. Then your fluent API is
not so fluent.
Overall I can see the utility of this but:
1. I'm not sure your intention here with exposing this from Session, but
a huge -1 to in any way allowing this even after the SessionFactory is
built.
2. Related to this, I can definitely see exposing this to build the
boot-time model as in the org.hibernate.mapping package - but not so much
the runtime model. Ultimately as we move to Jandex for describing the
boot-time model specifically I can see this API building those structures.
3. Not a high priority for me. In fact between 6 and then the Jandex
work I mentioned, I do not foresee having time to work on this
On Tue, Oct 24, 2017 at 6:36 AM Alessio Stalla <alessiostalla(a)gmail.com>
wrote:
That would be great for framework developers as well.
Il 24 ott 2017 12:01, "Gunnar Morling" <gunnar(a)hibernate.org> ha
scritto:
> Anyone with thoughts on this? To elaborate, here's what I have in mind:
>
> EntityMapping mapping = session.addEntityMapping();
> mapping.entity( Person.class )
> .table( "PERSONS" )
> .property( "personId" )
> .id()
> .strategy( Strategy.IDENTITY )
> .property( "phoneNumbers" )
> .oneToMany()
> .mappedBy( "person" )
> .property( "favouriteColor" )
> .converter( ColorConverter.class );
>
> I'm curious whether others think that'd be useful or not.
>
> Vlad, perhaps you have any insights from the field?
>
> Cheers,
>
> --Gunnar
>
>
>
>
> 2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
>
> > Hi all,
> >
> > This has crossed my mind for a few times: should we provide a
> programmatic
> > API in Hibernate ORM for mapping entities, as an alternative mapping
> > definition source to annotations and XML? I.e. something similar to the
> > programmatic mapping APIs we have in Hibernate Validator and Search.
> >
> > It'd probably be a fair bit of work (though giving lots of fun with API
> > design), but I can see how it could be appealing to folks preferring
> > API-style ways of configuring their stack, which seems more and more en
> > vogue these days. Using lambda expressions would be attractive
especially
> > when it comes to plugging in custom behaviours, e.g. for value
> generators.
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> >
> _______________________________________________
> 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
8:38 a.m.
2017-10-24 15:08 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
Of course you pick the easy case to illustrate :) A single entity
with
nothing but basic attributes or self-referential associations is going to
be relatively simple. The trickier stuff is adding 2 entities with
association between them, "property-ref" FKs, etc. Then your fluent API is
not so fluent.
Yeah, I just made up something quickly to ignite the discussion. I also
expect it to be more complex when done completely.
Overall I can see the utility of this but:
1. I'm not sure your intention here with exposing this from Session,
but a huge -1 to in any way allowing this even after the SessionFactory is
built.
Ah, I knew I'd get that wrong ;)
I just meant to illustrate there's *some* entry point into the API, full
ack it should be on the SF/EMF level of course.
1. Related to this, I can definitely see exposing this to build the
boot-time model as in the org.hibernate.mapping package - but not so much
the runtime model. Ultimately as we move to Jandex for describing the
boot-time model specifically I can see this API building those structures.
2. Not a high priority for me. In fact between 6 and then the Jandex
work I mentioned, I do not foresee having time to work on this
Sure. But it's great to know that you'd find it useful and can imagine
adding it. Thanks!
On Tue, Oct 24, 2017 at 6:36 AM Alessio Stalla <alessiostalla(a)gmail.com>
wrote:
> That would be great for framework developers as well.
>
> Il 24 ott 2017 12:01, "Gunnar Morling" <gunnar(a)hibernate.org> ha
scritto:
>
> > Anyone with thoughts on this? To elaborate, here's what I have in mind:
> >
> > EntityMapping mapping = session.addEntityMapping();
> > mapping.entity( Person.class )
> > .table( "PERSONS" )
> > .property( "personId" )
> > .id()
> > .strategy( Strategy.IDENTITY )
> > .property( "phoneNumbers" )
> > .oneToMany()
> > .mappedBy( "person" )
> > .property( "favouriteColor" )
> > .converter( ColorConverter.class );
> >
> > I'm curious whether others think that'd be useful or not.
> >
> > Vlad, perhaps you have any insights from the field?
> >
> > Cheers,
> >
> > --Gunnar
> >
> >
> >
> >
> > 2017-10-13 21:21 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
> >
> > > Hi all,
> > >
> > > This has crossed my mind for a few times: should we provide a
> > programmatic
> > > API in Hibernate ORM for mapping entities, as an alternative mapping
> > > definition source to annotations and XML? I.e. something similar to
> the
> > > programmatic mapping APIs we have in Hibernate Validator and Search.
> > >
> > > It'd probably be a fair bit of work (though giving lots of fun with
> API
> > > design), but I can see how it could be appealing to folks preferring
> > > API-style ways of configuring their stack, which seems more and more
> en
> > > vogue these days. Using lambda expressions would be attractive
> especially
> > > when it comes to plugging in custom behaviours, e.g. for value
> > generators.
> > >
> > > Any thoughts?
> > >
> > > --Gunnar
> > >
> > >
> > _______________________________________________
> > 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:21 a.m.
On Tue, Oct 24, 2017 at 8:38 AM Gunnar Morling <gunnar(a)hibernate.org> wrote:
Sure. But it's great to know that you'd find it useful and
can imagine
adding it. Thanks!
In fact we have similar requirement in ORM itself for hibernate-envers,
but again the initial expectation is supporting this at the boot-model
level, not the runtime-model level. Ultimately I'd like to use Jandex as
the thing that is built - for many reasons.
2597
days inactive
2608
days old
5 comments
3 participants
participants (3)
-
Alessio Stalla -
Gunnar Morling -
Steve Ebersole