Enum type in Postgresql

627 views
Skip to first unread message

Dennis

unread,
Aug 17, 2011, 4:40:51 PM8/17/11
to Ebean ORM
Postgresql has Enum type like this:
create type "payment_type" AS enum
( 'CASH', 'COD', 'BANK', 'CREDIT' );

I tried to map using

public enum PaymentType
{
@EnumValue("CASH")
CASH ("Cash"),
...

but got an exception while saving:
org.postgresql.util.PSQLException: ERROR: column "payment_type" is of
type payment_type_enum but expression is of type character varying
Hint: You will need to rewrite or cast the expression.

Does ebean supports it? Can I map enum with @EnumValue to that type?

Rob Bygrave

unread,
Aug 17, 2011, 5:17:42 PM8/17/11
to eb...@googlegroups.com
> Does ebean supports it? Can I map enum with @EnumValue to that type?

No, not by default. Enum types are mapped to java.sql.Types.VARCHAR or java.sql.Types.INTEGER. 

Do you see great value in using a Postgres Enum over a Varchar?

Cheers, Rob.

Dennis

unread,
Aug 18, 2011, 5:04:14 AM8/18/11
to Ebean ORM
Only advantage I see now is keeping table size smaller while having
human-readable values.
But size is not an issue, at least now. I'm developing new application
with ebean from scratch, so it's not problem to move to varchar-based
enums at this stage.

BTW, it's first time I use Ebean after using hibernate in several
projects. And it's like a breath of fresh air. I like your approach.
Only disadvantage I see now - "Ebean" sounds funny in russian. Hehe :)
To be fair "Ibatis" was funny too before they renamed :)


On 18 авг, 00:17, Rob Bygrave <robin.bygr...@gmail.com> wrote:
> > Does ebean supports it? Can I map enum with @EnumValue to that type?
>
> No, not by default. Enum types are mapped to java.sql.Types.VARCHAR or
> java.sql.Types.INTEGER.
>
> Do you see great value in using a Postgres Enum over a Varchar?
>
> Cheers, Rob.
>

Durchholz, Joachim

unread,
Aug 18, 2011, 6:30:06 AM8/18/11
to eb...@googlegroups.com
Just my 2c on that one:

> Do you see great value in using a Postgres Enum over a Varchar?

No need to write an extra CHECK constraint. Minor point, we're talking about a few extra developer minutes here.
In situations where the database is an authoritative source of semantics, the metadata is easier to exploit for automatically transporting that semantics into the application. In those situations, the value would indeed be great.

In situations where the Java side is authoritative for semantics, I don't see value either.

Regards,
Jo
Reply all
Reply to author
Forward
0 new messages