New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jdbc metadata vs PreparedStatement conflict #364

Open
ross-cohen opened this Issue Aug 24, 2015 · 23 comments

Comments

Projects
None yet
7 participants
@ross-cohen

ross-cohen commented Aug 24, 2015

The column type reported by the JDBC metadata (columnsResultSet.getInt("DATA_TYPE")) for an enum colum is Types.VARCHAR; however, if I try to set the value of an enum column through a PreparedStatement using the reported Types.VARCHAR, an exception is thrown saying I need to cast the value.

Thus, both
preparedStatement.setString(1, stringValue)
preparedStatement.setObject(1, stringValue, Types.VARCHAR)
throw an exception.

However,
preparedStatement.setObject(1, stringValue, Types.OTHER)
completes successfully.

Whatever column type is reported by the connection metadata should also work
in a PreparedStatement. So either the metadata should report Types.OTHER,
or preparedStatement.setString(1, stringValue) should work. The reported Types
and what a PreparedStatement will accept should be consistent.

My current workaround is to set the connection property "stringtype" to "unspecified".

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Sep 7, 2015

Member

Anyone care to comment on what this might break ?

Member

davecramer commented Sep 7, 2015

Anyone care to comment on what this might break ?

@kryptt

This comment has been minimized.

Show comment
Hide comment
@kryptt

kryptt Sep 15, 2015

Actually, after upgrading to 1202 the driver seems to arbitrarily report enums as either VARCHAR or OTHER, even when calling the same metadata.
I mentioned this in tpolecat/doobie/issues/221. For people who are keen on maintaining type information across this boundary, it would be essential for enums to report as Types.OTHER with the enum type.

kryptt commented Sep 15, 2015

Actually, after upgrading to 1202 the driver seems to arbitrarily report enums as either VARCHAR or OTHER, even when calling the same metadata.
I mentioned this in tpolecat/doobie/issues/221. For people who are keen on maintaining type information across this boundary, it would be essential for enums to report as Types.OTHER with the enum type.

@jpstrube

This comment has been minimized.

Show comment
Hide comment
@jpstrube

jpstrube Sep 22, 2015

We just migrated from version 9.2 to 9.3 and this issue breaks our code because we have to rely on the types reported in the metadata to build PreparedStatements. The problem seems to be lines 2467-2468 in AbstractJdbc2DatabaseMetaData.
Is there any other way to get the type that may be used in PreparedStatements?

jpstrube commented Sep 22, 2015

We just migrated from version 9.2 to 9.3 and this issue breaks our code because we have to rely on the types reported in the metadata to build PreparedStatements. The problem seems to be lines 2467-2468 in AbstractJdbc2DatabaseMetaData.
Is there any other way to get the type that may be used in PreparedStatements?

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Sep 22, 2015

Member

I'm waiting for a decent test case to fix this.

Dave Cramer

On 22 September 2015 at 09:35, Jan Strube notifications@github.com wrote:

We just migrated from version 9.2 to 9.3 and this issue breaks our code
because we have to rely on the types reported in the metadata to build
PreparedStatements. The problem seems to be lines 2467-2468 in
AbstractJdbc2DatabaseMetaData.
Is there any other way to get the type that may be used in
PreparedStatements?


Reply to this email directly or view it on GitHub
#364 (comment).

Member

davecramer commented Sep 22, 2015

I'm waiting for a decent test case to fix this.

Dave Cramer

On 22 September 2015 at 09:35, Jan Strube notifications@github.com wrote:

We just migrated from version 9.2 to 9.3 and this issue breaks our code
because we have to rely on the types reported in the metadata to build
PreparedStatements. The problem seems to be lines 2467-2468 in
AbstractJdbc2DatabaseMetaData.
Is there any other way to get the type that may be used in
PreparedStatements?


Reply to this email directly or view it on GitHub
#364 (comment).

@chschroe74

This comment has been minimized.

Show comment
Hide comment
@chschroe74

chschroe74 Oct 12, 2015

The changed behavior was introduced by commit 0da850b which deliberately changed the data type returned by DatabaseMetaData.getColumns from OTHER to VARCHAR. The reasoning for this change seems to reach back to this discussion on the jdbc mailing list.
The question is: Which is the expected behavior? What type should be returned by getColumns for an enum column? And if PreparedStatement.getObject now returns a string, why does setString on the other hand not work for enums?

chschroe74 commented Oct 12, 2015

The changed behavior was introduced by commit 0da850b which deliberately changed the data type returned by DatabaseMetaData.getColumns from OTHER to VARCHAR. The reasoning for this change seems to reach back to this discussion on the jdbc mailing list.
The question is: Which is the expected behavior? What type should be returned by getColumns for an enum column? And if PreparedStatement.getObject now returns a string, why does setString on the other hand not work for enums?

@vlsi

This comment has been minimized.

Show comment
Hide comment
@vlsi

vlsi Oct 12, 2015

Member

why does setString on the other hand not work for enums?

Can you please provide a testcase & exception when setString does not work?

I am not sure if it should work, but it would be nice to add an explicit test into the codebase to disambiguate.

Here are the current tests and they seem somehow work when using setString for enum:


Here's Tom Lane's "it is better to ban setString for enum" reasoning: http://www.postgresql.org/message-id/22027.1360684244@sss.pgh.pa.us

Member

vlsi commented Oct 12, 2015

why does setString on the other hand not work for enums?

Can you please provide a testcase & exception when setString does not work?

I am not sure if it should work, but it would be nice to add an explicit test into the codebase to disambiguate.

Here are the current tests and they seem somehow work when using setString for enum:


Here's Tom Lane's "it is better to ban setString for enum" reasoning: http://www.postgresql.org/message-id/22027.1360684244@sss.pgh.pa.us

@kryptt

This comment has been minimized.

Show comment
Hide comment
@kryptt

kryptt Oct 12, 2015

from my perspective it should NOT work.

Part of the utility derived by enums is the typesafety that verifies the possible values.

if someone wants to recieve / send arbitrary strings they should use myenumfield::varchar and $1::myenumtype respectively.

kryptt commented Oct 12, 2015

from my perspective it should NOT work.

Part of the utility derived by enums is the typesafety that verifies the possible values.

if someone wants to recieve / send arbitrary strings they should use myenumfield::varchar and $1::myenumtype respectively.

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Oct 12, 2015

Member

As far as I recall the reason this was added was to get rid of the hoops
one has to jump through to use hibernate with enums. IMHO constraints are
much better way to get the type safety you are looking for but that's just
my opinion. (Try adding a value to an enum in an earlier version of pg).

That being said it would appear that this change has introduced a
regression. I think having a connection parameter which controls this
behaviour would be in order.

Dave Cramer

On 12 October 2015 at 09:40, Rodolfo Hansen notifications@github.com
wrote:

from my perspective it should NOT work.

Part of the utility derived by enums is the typesafety that verifies the
possible values.

if someone wants to recieve / send arbitrary strings they should use
myenumfield::varchar and $1::myenumtype respectively.


Reply to this email directly or view it on GitHub
#364 (comment).

Member

davecramer commented Oct 12, 2015

As far as I recall the reason this was added was to get rid of the hoops
one has to jump through to use hibernate with enums. IMHO constraints are
much better way to get the type safety you are looking for but that's just
my opinion. (Try adding a value to an enum in an earlier version of pg).

That being said it would appear that this change has introduced a
regression. I think having a connection parameter which controls this
behaviour would be in order.

Dave Cramer

On 12 October 2015 at 09:40, Rodolfo Hansen notifications@github.com
wrote:

from my perspective it should NOT work.

Part of the utility derived by enums is the typesafety that verifies the
possible values.

if someone wants to recieve / send arbitrary strings they should use
myenumfield::varchar and $1::myenumtype respectively.


Reply to this email directly or view it on GitHub
#364 (comment).

@kryptt

This comment has been minimized.

Show comment
Hide comment
@kryptt

kryptt Oct 12, 2015

Why didn't Hibernate just use myenumfield::varchar and $1::myenumtype internally in their drivers so their users can have the experience they want? In any case, a connection parameter sounds like a decent proposition.

There is probably also something else at play, because I get the column reported sometimes as OTHER, sometimes as String. Unfortunately, I haven't been able to narrow down how/why this is happening..

kryptt commented Oct 12, 2015

Why didn't Hibernate just use myenumfield::varchar and $1::myenumtype internally in their drivers so their users can have the experience they want? In any case, a connection parameter sounds like a decent proposition.

There is probably also something else at play, because I get the column reported sometimes as OTHER, sometimes as String. Unfortunately, I haven't been able to narrow down how/why this is happening..

@chschroe74

This comment has been minimized.

Show comment
Hide comment
@chschroe74

chschroe74 Oct 12, 2015

Indeed the behavior of setString and setObject with respect to enum types is already controlled by the connection parameter stringtype (as can be seen from the test cases). If this parameter is set to unspecified, then both methods accept a string and seem to correctly cast it before passing a query to the database. If the parameter is set to another value, an insert or update query fails with a database error.
However, the column type returned by DatabaseMetaData.getColumns is independent from the parameter and is always returned as VARCHAR (instead of OTHER as in earlier versions).

@kryptt I cannot reproduce the value returned as OTHER with the current version of the driver.

chschroe74 commented Oct 12, 2015

Indeed the behavior of setString and setObject with respect to enum types is already controlled by the connection parameter stringtype (as can be seen from the test cases). If this parameter is set to unspecified, then both methods accept a string and seem to correctly cast it before passing a query to the database. If the parameter is set to another value, an insert or update query fails with a database error.
However, the column type returned by DatabaseMetaData.getColumns is independent from the parameter and is always returned as VARCHAR (instead of OTHER as in earlier versions).

@kryptt I cannot reproduce the value returned as OTHER with the current version of the driver.

@kryptt

This comment has been minimized.

Show comment
Hide comment
@kryptt

kryptt Oct 12, 2015

@chschroe74

Using org.postgresql:postgresql:9.4-1204-jdbc42, this is the type information I'm getting (via doobie):

[info] Query0[Account] defined at account-queries.scala:70                                                                                                                                                                           [355/1401]
[info]   SELECT
[info]   a.id,
[info]   a.owner_id,
[info]   a.state,
[info]   a.domain,
[info]   a.billing_address_id
[info]   FROM core.accounts a
[info]   WHERE a.id = ?
[info]   + SQL Compiles and Typechecks
[info]   + P01 Long  →  BIGINT (int8)
[info]   + C01 id                 BIGINT  (int8)                    NOT NULL  →  Long
[info]   + C02 owner_id           BIGINT  (int8)                    NOT NULL  →  Long
[info]   + C03 state              OTHER   ("core"."resource_state") NOT NULL  →  ResourceState

the state enum is correctly identified and mapped... and my test suite runs to completion successfully, however, about once in every 4 or 5 runs of the test suite I get failures like this one:

[info] Update0 defined at school-queries.scala:113
[info]   UPDATE core.school_years SET state = ?
[info]   WHERE  school_id = ? AND period_id = ?
[info]   + SQL Compiles and Typechecks
[error]   x P01 ResourceState  →  VARCHAR (resource_state)
[error]    x ResourceState is not coercible to VARCHAR (resource_state) according to the JDBC
[error]      specification. Fix this by changing the schema type to OTHER, or the Scala type
[error]      to String or Color or Permission. (school-queries.scala:113)

Where now the type is being reported as VARCHAR (as opposed to OTHER).

This happens for both UPDATES and SELECTS

[info] Query0[School.View] defined at school-queries.scala:48                                                                                                                                                                        [556/6254]
[info]   
[info]   SELECT
[info]   s.id,
[info]   s.code,
[info]   s.collegeboard_code,
[info]   ig.name,
[info]   ig.state,
[info]   ig.parent_id
[info]   FROM
[info]   core.schools s
[info]   INNER JOIN
[info]   core.institution_groups ig ON s.id = ig.id
[info]   WHERE
[info]   s.id = ?
[info]   
[info]   + SQL Compiles and Typechecks
[info]   + P01 Long  →  BIGINT (int8)
[info]   + C01 id                BIGINT  (int8)           NOT NULL  →  Long
[info]   + C02 code              VARCHAR (varchar)        NULL      →  Option[String]
[info]   + C03 collegeboard_code VARCHAR (varchar)        NULL      →  Option[String]
[info]   + C04 name              VARCHAR (varchar)        NOT NULL  →  String
[error]   x C05 state             VARCHAR (resource_state) NOT NULL  →  ResourceState
[error]    x VARCHAR (resource_state) is not coercible to ResourceState according to the JDBC
[error]      specification or any defined mapping. Fix this by changing the schema type to

Like I said, I haven't been able to isolate what's going on here, except that I get columns reported as either VARCHAR or OTHER arbitrarily. This happens not only in tests, but also as the application is running and the web server is responding to REST calls...

kryptt commented Oct 12, 2015

@chschroe74

Using org.postgresql:postgresql:9.4-1204-jdbc42, this is the type information I'm getting (via doobie):

[info] Query0[Account] defined at account-queries.scala:70                                                                                                                                                                           [355/1401]
[info]   SELECT
[info]   a.id,
[info]   a.owner_id,
[info]   a.state,
[info]   a.domain,
[info]   a.billing_address_id
[info]   FROM core.accounts a
[info]   WHERE a.id = ?
[info]   + SQL Compiles and Typechecks
[info]   + P01 Long  →  BIGINT (int8)
[info]   + C01 id                 BIGINT  (int8)                    NOT NULL  →  Long
[info]   + C02 owner_id           BIGINT  (int8)                    NOT NULL  →  Long
[info]   + C03 state              OTHER   ("core"."resource_state") NOT NULL  →  ResourceState

the state enum is correctly identified and mapped... and my test suite runs to completion successfully, however, about once in every 4 or 5 runs of the test suite I get failures like this one:

[info] Update0 defined at school-queries.scala:113
[info]   UPDATE core.school_years SET state = ?
[info]   WHERE  school_id = ? AND period_id = ?
[info]   + SQL Compiles and Typechecks
[error]   x P01 ResourceState  →  VARCHAR (resource_state)
[error]    x ResourceState is not coercible to VARCHAR (resource_state) according to the JDBC
[error]      specification. Fix this by changing the schema type to OTHER, or the Scala type
[error]      to String or Color or Permission. (school-queries.scala:113)

Where now the type is being reported as VARCHAR (as opposed to OTHER).

This happens for both UPDATES and SELECTS

[info] Query0[School.View] defined at school-queries.scala:48                                                                                                                                                                        [556/6254]
[info]   
[info]   SELECT
[info]   s.id,
[info]   s.code,
[info]   s.collegeboard_code,
[info]   ig.name,
[info]   ig.state,
[info]   ig.parent_id
[info]   FROM
[info]   core.schools s
[info]   INNER JOIN
[info]   core.institution_groups ig ON s.id = ig.id
[info]   WHERE
[info]   s.id = ?
[info]   
[info]   + SQL Compiles and Typechecks
[info]   + P01 Long  →  BIGINT (int8)
[info]   + C01 id                BIGINT  (int8)           NOT NULL  →  Long
[info]   + C02 code              VARCHAR (varchar)        NULL      →  Option[String]
[info]   + C03 collegeboard_code VARCHAR (varchar)        NULL      →  Option[String]
[info]   + C04 name              VARCHAR (varchar)        NOT NULL  →  String
[error]   x C05 state             VARCHAR (resource_state) NOT NULL  →  ResourceState
[error]    x VARCHAR (resource_state) is not coercible to ResourceState according to the JDBC
[error]      specification or any defined mapping. Fix this by changing the schema type to

Like I said, I haven't been able to isolate what's going on here, except that I get columns reported as either VARCHAR or OTHER arbitrarily. This happens not only in tests, but also as the application is running and the web server is responding to REST calls...

@kryptt

This comment has been minimized.

Show comment
Hide comment
@kryptt

kryptt Oct 12, 2015

Here is the first query failing instead:

[info] Query0[Account] defined at account-queries.scala:70
[info]   SELECT
[info]   a.id,
[info]   a.owner_id,
[info]   a.state,
[info]   a.domain,
[info]   a.billing_address_id
[info]   FROM core.accounts a
[info]   WHERE a.id = ?
[info]   + SQL Compiles and Typechecks
[info]   + P01 Long  →  BIGINT (int8)
[info]   + C01 id                 BIGINT  (int8)           NOT NULL  →  Long
[info]   + C02 owner_id           BIGINT  (int8)           NOT NULL  →  Long
[error]   x C03 state              VARCHAR (resource_state) NOT NULL  →  ResourceState
[error]    x VARCHAR (resource_state) is not coercible to ResourceState according to the JDBC
[error]      specification or any defined mapping. Fix this by changing the schema type to
[error]      OTHER or JAVAOBJECT, or the Scala type to String or Color or Permission. (account-queries.scala:70)

Additionally, setting the stringtype connection paramter to either varchar or unspecified has no effect on this behaviour.

kryptt commented Oct 12, 2015

Here is the first query failing instead:

[info] Query0[Account] defined at account-queries.scala:70
[info]   SELECT
[info]   a.id,
[info]   a.owner_id,
[info]   a.state,
[info]   a.domain,
[info]   a.billing_address_id
[info]   FROM core.accounts a
[info]   WHERE a.id = ?
[info]   + SQL Compiles and Typechecks
[info]   + P01 Long  →  BIGINT (int8)
[info]   + C01 id                 BIGINT  (int8)           NOT NULL  →  Long
[info]   + C02 owner_id           BIGINT  (int8)           NOT NULL  →  Long
[error]   x C03 state              VARCHAR (resource_state) NOT NULL  →  ResourceState
[error]    x VARCHAR (resource_state) is not coercible to ResourceState according to the JDBC
[error]      specification or any defined mapping. Fix this by changing the schema type to
[error]      OTHER or JAVAOBJECT, or the Scala type to String or Color or Permission. (account-queries.scala:70)

Additionally, setting the stringtype connection paramter to either varchar or unspecified has no effect on this behaviour.

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Oct 13, 2015

Member

If the java program is working correctly does this suggest another issue
somewhere else ?

Dave Cramer

On 12 October 2015 at 11:28, Rodolfo Hansen notifications@github.com
wrote:

Here is the first query failing instead:

[info] Query0[Account] defined at account-queries.scala:70
[info] SELECT
[info] a.id,
[info] a.owner_id,
[info] a.state,
[info] a.domain,
[info] a.billing_address_id
[info] FROM core.accounts a
[info] WHERE a.id = ?
[info] + SQL Compiles and Typechecks
[info] + P01 Long → BIGINT (int8)
[info] + C01 id BIGINT (int8) NOT NULL → Long
[info] + C02 owner_id BIGINT (int8) NOT NULL → Long
[error] x C03 state VARCHAR (resource_state) NOT NULL → ResourceState
[error] x VARCHAR (resource_state) is not coercible to ResourceState according to the JDBC
[error] specification or any defined mapping. Fix this by changing the schema type to
[error] OTHER or JAVAOBJECT, or the Scala type to String or Color or Permission. (account-queries.scala:70)


Reply to this email directly or view it on GitHub
#364 (comment).

Member

davecramer commented Oct 13, 2015

If the java program is working correctly does this suggest another issue
somewhere else ?

Dave Cramer

On 12 October 2015 at 11:28, Rodolfo Hansen notifications@github.com
wrote:

Here is the first query failing instead:

[info] Query0[Account] defined at account-queries.scala:70
[info] SELECT
[info] a.id,
[info] a.owner_id,
[info] a.state,
[info] a.domain,
[info] a.billing_address_id
[info] FROM core.accounts a
[info] WHERE a.id = ?
[info] + SQL Compiles and Typechecks
[info] + P01 Long → BIGINT (int8)
[info] + C01 id BIGINT (int8) NOT NULL → Long
[info] + C02 owner_id BIGINT (int8) NOT NULL → Long
[error] x C03 state VARCHAR (resource_state) NOT NULL → ResourceState
[error] x VARCHAR (resource_state) is not coercible to ResourceState according to the JDBC
[error] specification or any defined mapping. Fix this by changing the schema type to
[error] OTHER or JAVAOBJECT, or the Scala type to String or Color or Permission. (account-queries.scala:70)


Reply to this email directly or view it on GitHub
#364 (comment).

@kryptt

This comment has been minimized.

Show comment
Hide comment
@kryptt

kryptt Oct 13, 2015

Yes, I suspect the specifics of how it is being called is triggering an edge case for the driver / db.. :(

kryptt commented Oct 13, 2015

Yes, I suspect the specifics of how it is being called is triggering an edge case for the driver / db.. :(

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Oct 13, 2015

Member

Hmmmm... I actually suspect that it is elsewhere, but I'm willing to be
proven wrong.

Dave Cramer

On 13 October 2015 at 10:06, Rodolfo Hansen notifications@github.com
wrote:

Yes, I suspect the specifics of how it is being called is triggering an
edge case for the driver / db.. :(


Reply to this email directly or view it on GitHub
#364 (comment).

Member

davecramer commented Oct 13, 2015

Hmmmm... I actually suspect that it is elsewhere, but I'm willing to be
proven wrong.

Dave Cramer

On 13 October 2015 at 10:06, Rodolfo Hansen notifications@github.com
wrote:

Yes, I suspect the specifics of how it is being called is triggering an
edge case for the driver / db.. :(


Reply to this email directly or view it on GitHub
#364 (comment).

@rjahn

This comment has been minimized.

Show comment
Hide comment
@rjahn

rjahn Sep 20, 2016

Any updates?

rjahn commented Sep 20, 2016

Any updates?

@rjahn

This comment has been minimized.

Show comment
Hide comment
@rjahn

rjahn Sep 20, 2016

The JVx framework has a generic database access mechanism. This detects enum types and automatically shows comboboxes on the UI. The detection is broken with newer driver versions because of the datatype change. We did the enum detection if sqltype was OTHER. We won't check for enum values for every data type because it makes metadata detection horrible slow.

rjahn commented Sep 20, 2016

The JVx framework has a generic database access mechanism. This detects enum types and automatically shows comboboxes on the UI. The detection is broken with newer driver versions because of the datatype change. We did the enum detection if sqltype was OTHER. We won't check for enum values for every data type because it makes metadata detection horrible slow.

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Sep 22, 2016

Member

I'm not sure what the ask is here? What do you want the driver to do ?

Dave Cramer

On 20 September 2016 at 17:54, rjahn notifications@github.com wrote:

The JVx framework has a generic database access mechanism. This detects
enum types and automatically shows comboboxes on the UI. The detection is
broken with newer driver versions because of the datatype change. We did
the enum detection if sqltype was OTHER. We won't check for enum values for
every data type because it makes metadata detection horrible slow.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#364 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAYz9lKWWTS8pdH1xxrd5cU4VdwiPww7ks5qsFYYgaJpZM4FxAKP
.

Member

davecramer commented Sep 22, 2016

I'm not sure what the ask is here? What do you want the driver to do ?

Dave Cramer

On 20 September 2016 at 17:54, rjahn notifications@github.com wrote:

The JVx framework has a generic database access mechanism. This detects
enum types and automatically shows comboboxes on the UI. The detection is
broken with newer driver versions because of the datatype change. We did
the enum detection if sqltype was OTHER. We won't check for enum values for
every data type because it makes metadata detection horrible slow.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#364 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAYz9lKWWTS8pdH1xxrd5cU4VdwiPww7ks5qsFYYgaJpZM4FxAKP
.

@vlsi

This comment has been minimized.

Show comment
Hide comment
@vlsi

vlsi Sep 22, 2016

Member

@davecramer , the issue is parametermetadata for enum returns VARCHAR, while it should return OTHER.
It does sound like a driver defect.

Member

vlsi commented Sep 22, 2016

@davecramer , the issue is parametermetadata for enum returns VARCHAR, while it should return OTHER.
It does sound like a driver defect.

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Sep 22, 2016

Member

There are some issues with hibernate with enums. To be honest I just tell
people not to use them. constraints are much easier,

Did we change the metadata for enums recently ?

Dave Cramer

On 22 September 2016 at 12:37, Vladimir Sitnikov notifications@github.com
wrote:

@davecramer https://github.com/davecramer , the issue is
parametermetadata for enum returns VARCHAR, while it should return OTHER.
It does sound like a driver defect.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#364 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAYz9pvL56z3xFnfBGG0szeaf0-JHdNfks5qsq7ggaJpZM4FxAKP
.

Member

davecramer commented Sep 22, 2016

There are some issues with hibernate with enums. To be honest I just tell
people not to use them. constraints are much easier,

Did we change the metadata for enums recently ?

Dave Cramer

On 22 September 2016 at 12:37, Vladimir Sitnikov notifications@github.com
wrote:

@davecramer https://github.com/davecramer , the issue is
parametermetadata for enum returns VARCHAR, while it should return OTHER.
It does sound like a driver defect.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#364 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAYz9pvL56z3xFnfBGG0szeaf0-JHdNfks5qsq7ggaJpZM4FxAKP
.

@vlsi

This comment has been minimized.

Show comment
Hide comment
@vlsi

vlsi Sep 22, 2016

Member

Hibernate might indeed want "VARCHAR" way of dealing with enums.

The second comment mentions "after upgrading to 1202 the", so it might be something with 1202.
I don't think there were recent enum-related changes.

Member

vlsi commented Sep 22, 2016

Hibernate might indeed want "VARCHAR" way of dealing with enums.

The second comment mentions "after upgrading to 1202 the", so it might be something with 1202.
I don't think there were recent enum-related changes.

@rjahn

This comment has been minimized.

Show comment
Hide comment
@rjahn

rjahn Sep 22, 2016

Exaxtly. The old driver returned OTHER instead of VARCHAR. Last "working" driver version was 9.2-1004-jdbc41.

If you call getColumnType(index) of a ResultSetMetaData, the return value will be VARCHAR and not OTHER.

What about a property to en/disable old behaviour?

rjahn commented Sep 22, 2016

Exaxtly. The old driver returned OTHER instead of VARCHAR. Last "working" driver version was 9.2-1004-jdbc41.

If you call getColumnType(index) of a ResultSetMetaData, the return value will be VARCHAR and not OTHER.

What about a property to en/disable old behaviour?

@vlsi

This comment has been minimized.

Show comment
Hide comment
@vlsi

vlsi Sep 22, 2016

Member

So here's the change: #68

What about a property to en/disable old behaviour?

I'm afraid there might be someone who would ask for both behaviors at the same time to please hibernate and JVx

Member

vlsi commented Sep 22, 2016

So here's the change: #68

What about a property to en/disable old behaviour?

I'm afraid there might be someone who would ask for both behaviors at the same time to please hibernate and JVx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment