7:46 a.m.
On 26 August 2016 at 12:51, Steve Ebersole <steve(a)hibernate.org> wrote:
PGSQL has some enum support I know. The problem has always been that
they
are mapped to "special" type codes (think java.sql.Types) which makes it
difficult to work with in ORM.
That's very interesting. So in an ideal world, could we propose for
JPA 2.2 to add a new option to the enum type?
This could be "NATIVE", or maybe even better "AUTO".
Thanks,
Sanne
On Fri, Aug 26, 2016 at 6:18 AM Gunnar Morling
<gunnar(a)hibernate.org> wrote:
>
> > I guess we could, but it's sad that we'd still have to default to the
> > "wrong" mapping,
> > at least for all those people who won't read all of our docs.
>
> The default for our custom @Enumerated could be NATIVE, but I agree people
> need to know about that instead of the JPA one.
>
> > Would that live in OGM or ORM ?
>
> Good question, depends on whether there is any RDBMS with native enum
> support?
>
>
> 2016-08-26 13:02 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> > On 26 August 2016 at 10:34, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > > How about having a custom @Enumerated annotation which offers NATIVE
> > > as
> > an
> > > additional choice?
> >
> > I guess we could, but it's sad that we'd still have to default to the
> > "wrong" mapping,
> > at least for all those people who won't read all of our docs.
> >
> > Would that live in OGM or ORM ?
> >
> > >
> > > 2016-08-26 10:16 GMT+02:00 Emmanuel Bernard
<emmanuel(a)hibernate.org>:
> > >>
> > >> Can you give HotRod's example of native enum - I imagine Protobuf
?
> >
> > From the OGM testsuite:
> >
> > @Entity
> > public class Bookmark {
> >
> > public enum Classifier {
> > HOME, WORK
> > }
> >
> > @Id
> > private String id;
> > @Enumerated(EnumType.STRING)
> > private Classifier classifier;
> > [...]
> > }
> >
> > Is mapped as:
> >
> > message Bookmark {
> > required string id = 1;
> > optional string classifier = 2;
> > [...]
> >
> > (correctly as it's explicitly requesting a STRING EnumType)
> >
> > A more "native" Protobuf mapping would look like:
> >
> > enum Classifier {
> > HOME = 0;
> > WORK = 1;
> > }
> >
> > message Bookmark {
> > required string id = 1;
> > optional Classifier classifier = 2;
> > [...]
> >
> > I had already implemented this, just realising later that there's no
> > way to enable this better looking mapping.
> >
> > >>
> > >> The issue I see is that ordinal could be an acceptable explicit
> > >> decision
> > >> that would not be available to the user if you use default as native.
> > >>
> > >> I'm tempted to go native all the time at the detriment of people
that
> > >> need high customization.
> >
> > I'd be tempted too as the second mapping looks much more natural,
> > however this would break things for people who need it to be an
> > integer, e.g. if they have other clients who expect an int.
> > On the other hand, the "I need compatibility with another client"
> > argument is quite weak, as at this stage the Hot Rod Dialect generates
> > its own schema and pretty much mandates using the one it generates.
> >
> > Proposal: I have it mapped as "native enums" by default, and give a
> > global configuration property to honour the annotations instead? This
> > would be a global setting though, so if one wants one attribute
> > "native encoded" and another "int encoded" that wouldn't
be possible.
> >
> > Thanks,
> > Sanne
> >
> > >>
> > >> Emmanuel
> > >>
> > >> On Mon 2016-08-15 18:14, Sanne Grinovero wrote:
> > >> > In the context of Hibernate OGM, it turns out that some
datastores
> > >> > have a rather nice "native" support for enums.
> > >> >
> > >> > We aim to map each property of the user's domain model to its
most
> > >> > appropriate "physical type", unless the choice is
overriden by the
> > >> > an
> > >> > explicit user request.
> > >> >
> > >> > In the case of an Enum, JPA annotations such as @Enumerated have
an
> > >> > attribute EnumType to choose the physical representation:
> > >> >
> > >> > public enum EnumType {
> > >> > /** Persist enumerated type property or field as an integer.
*/
> > >> > ORDINAL,
> > >> >
> > >> > /** Persist enumerated type property or field as a string. */
> > >> > STRING
> > >> > }
> > >> >
> > >> > However, there's no support for a "NATIVE". Also,
the annotation
> > >> > specifies that "ORDINAL" is the default value so I
can't just
> > >> > assume
> > >> > that the user didn't specify anything and we're good to
use our own
> > >> > NATIVE implementation.
> > >> >
> > >> > Assuming that we can't change the JPA spec, any suggestion on
when
> > >> > I
> > >> > could have the Hot Rod dialect for OGM to actually produce a
"nice"
> > >> > mapping into native enums?
> > >> >
> > >> > I'm tempted to just use natives all the time; In the case in
which
> > >> > the
> > >> > user opted for "STRING" I could drop a warning - or
decide to
> > >> > honour
> > >> > that - but in case of ORDINAL I just can't tell if it's a
default
> > >> > choice or not so I think a warning would be too much.
> > >> >
> > >> > Another alternative would be that I "go native" when
the
> > >> > @Enumerated
> > >> > annotation isn't specified at all: looks like this mapping is
valid
> > >> > according to ORM as it seems to treat it as if there was an
> > >> > implicit
> > >> > @Enumerated annotation; I'm not happy about having to rely on
> > >> > people
> > >> > to not use an explicit annotation though.
> > >> >
> > >> > Thanks,
> > >> > Sanne
> > >> > _______________________________________________
> > >> > 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