Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] JPA + enum == Exception

From: Kris Jurka <books(at)ejurka(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 16:26:27
Message-ID: alpine.BSO.2.00.1302081124290.16163@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc

On Fri, 8 Feb 2013, Tom Dunstan wrote:

> 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.)
> >
> 
> 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.

The other workaround is to use the url parameter stringtype=unspecified to 
have setString always bind to unknown instead of varchar, which then 
shouldn't require any code changes.

Kris Jurka



In response to

Responses

pgsql-hackers by date

Next:From: Adrian KlaverDate: 2013-02-08 16:39:04
Subject: Re: Bug, Feature, or what else?
Previous:From: Greg Sabino MullaneDate: 2013-02-08 16:24:53
Subject: Re: Considering Gerrit for CFs

pgsql-jdbc by date

Next:From: Stephen NelsonDate: 2013-02-08 16:35:52
Subject: Re: Publish artifacts to Maven central
Previous:From: Dave CramerDate: 2013-02-08 14:39:04
Subject: Re: Publish artifacts to Maven central

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group