Column order seems to play a role after migration from 8.1 to 9.1 if sequences are used

From: Andreas Arens <andreas(dot)arens(at)list(dot)lu>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Column order seems to play a role after migration from 8.1 to 9.1 if sequences are used
Date: 2016-04-21 08:59:21
Message-ID: OF4E296DA5.2727C8FF-ONC1257F9B.0047C62D-C1257F9C.003160F7@list.lu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Hello,

I don't know if the root cause of my observation is effectively
JDBC-related, but I thought it might be the best starting point.

TL:DR: After migrating a PosgreSQL DB from 8.1 to 9.1, I had to reorder the
columns of a table to make sure the primary key column that is
automatically filled by a sequence, is the first one in the table. This was
not an issue with 8.1. The problem - during INSERT - only occurs via JDBC.
When using the CLI (i.e. psql), it works fine.

The details of what I've observed:

In preparing a major system upgrade for a legacy application, I tested the
migration of the PostgreSQL server from version 8.1 to 9.1 (on Ubuntu LTS
12.04). On top of the database I use JBoss AS 7.1 with Hibernate, JDBC and
Java 1.7.
I tested with different but recent JDBC drivers for the Java 1.7 platform
(i.e. postgresql-9.3-1102.jdbc41.jar, postgresql-9.4.1208.jre7.jar). The
entity beans are specified to have their primary key (Integer value)
generated by the database via a sequence:

In the bean:

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "id")
public java.lang.Integer getId()
{
return id;
}

In the table:

\d phrases
Table "phrases"
Column | Type | Modifiers
-----------+----------------------+----------------------------------------------------------------------
phrase | text |
frequency | integer | default 4
language | character varying(3) |
id | bigint | not null default nextval
('phrases_id_seq'::regclass)
Indexes:
"phrases_pkey" PRIMARY KEY, btree (id)

However, after switching to the 9.1 server, I got following error message:

WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] SQL Error: 0,
SQLState: 22003
ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] Bad value for type
int : lklkh

Increasing the log levels provided me with following details:

DEBUG [org.hibernate.SQL] insert into phrases (frequency, language, phrase)
values (?, ?, ?)
TRACE [org.hibernate.type.descriptor.sql.BasicBinder] binding parameter [1]
as [INTEGER] - 4
TRACE [org.hibernate.type.descriptor.sql.BasicBinder] binding parameter [2]
as [VARCHAR] - ger
TRACE [org.hibernate.type.descriptor.sql.BasicBinder] binding parameter [3]
as [VARCHAR] - lklkh
WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] SQL Error: 0,
SQLState: 22003
ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] Bad value for type
int : lklkh

Performing the INSERT via CLI worked nicely:

INSERT INTO phrases (frequency, language, phrase) VALUES (4, 'ger',
'lklh');
INSERT 0 1

This led me to the assumption that there was something wrong with the JDBC
driver or the hibernate layer, but none of the tested modifications made
the problem go away. When searching for the given SQL error code & state, I
stumbled on a stackoverflow post (
http://stackoverflow.com/questions/25977903/hibernate-columns-mismatch-on-persistance
), and indeed, after I have re-ordered the columns in the table moving the
id column to the first position, it works without a flaw.

\d phrases
Table "phrases"
Column | Type | Modifiers
-----------+----------------------+----------------------------------------------------------------------
id | bigint | not null default nextval
('phrases_id_seq'::regclass)
phrase | text |
frequency | integer | default 4
language | character varying(3) |
Indexes:
"phrases_pkey" PRIMARY KEY, btree (id)

As it took me quite a while to figure out this work around, I wanted to
share this with the community and ask the question, if you have any ideas
what the actual root cause is. Please point me to any resources, if that is
a known and justified behaviour of the database. Otherwise, I hope this
might help others in similar situations.

Cheers,
Andreas

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2016-04-21 10:15:00 Re: Column order seems to play a role after migration from 8.1 to 9.1 if sequences are used
Previous Message Bear Giles 2016-04-20 15:34:37 Kerberos problem with pg_ident that happens with JDBC but not with PSQL.