Re: [HACKERS] JPA + enum == Exception
Dave Cramer <pg@fastcrypt.com>
From: Dave Cramer <pg@fastcrypt.com>
To: Tom Dunstan <tom@tomd.cc>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Hudson, Derrick" <dhudson@redcom.com>, "Marc G. Fournier" <scrappy@hub.org>, "pgsql-jdbc@postgresql.org" <pgsql-jdbc@postgresql.org>
Date: 2013-02-08T11:33:15Z
Lists: pgsql-hackers
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@tomd.cc> wrote: > Hi Tom! > > On 8 February 2013 15:25, Tom Lane <tgl@sss.pgh.pa.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc >