From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Tom Dunstan <tom(at)tomd(dot)cc> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hudson, Derrick" <dhudson(at)redcom(dot)com>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] JPA + enum == Exception |
Date: | 2013-02-08 11:33:15 |
Message-ID: | CADK3HHJmejkbv8QHUTs4hX_OiAaUyohL7NrVjZLaKUtzwimT7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
Tom,
How would setString know that the enum is actually an enum ? setString only
takes a string ?
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Feb 8, 2013 at 12:45 AM, Tom Dunstan <tom(at)tomd(dot)cc> wrote:
> Hi Tom!
>
> On 8 February 2013 15:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > AFAIK this is just business as usual with JDBC: setString() implies that
> > the parameter is of a string type. It'll fall over if the type actually
> > required is anything but a string. (I'm no Java expert, but I seem to
> > recall that using setObject instead is the standard workaround.)
> >
> > Enums are not suffering any special hardship here, and I'd be against
> > weakening the type system to give them a special pass.
>
> Yes, you can use setObject(1, "enumval", Types.OTHER). I was hoping
> that setString might work, as mapping java enum values to strings in
> the database is a very common ORM technique that is built into
> basically all major ORMs including all that support the JPA standard,
> and it leads to people using varchars instead of typesafe enums in
> their dbs. If setString worked, people could migrate their schemas to
> the typesafe versions without touching any code. Using setObject
> people need to write a custom converter in most of those systems, and
> configure its use for each enum that they have. This then also makes
> swapping database backends difficult (for people who care about that
> sort of thing), since the jdbc calls are now different for postgresql
> vs anything else.
>
> Anyway, if there's no nice way to do it in the backend without adding
> implicit casts, and you're not happy with the costs of that as a
> solution, I guess that's that. I guess I was hoping that a text value
> parameter to a prepared statement could be treated as input when the
> type didn't match, but I don't know if that's feasible, and I guess
> it's probably opening the door to confusing error messages when
> someone provides the wrong type accidentally.
>
> Thanks
>
> Tom
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-02-08 11:47:15 | Re: Identity projection |
Previous Message | Magnus Hagander | 2013-02-08 10:46:33 | Re: Comment typo |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2013-02-08 14:13:11 | Re: Timestamp vs. Java Date/Timestamp |
Previous Message | Dave Cramer | 2013-02-08 11:09:42 | Re: Publish artifacts to Maven central |