Support for Arrays of Composite Types

[eliasbalasis]

I discovered that although user defined types registration is implemented in version 9.2-1002 the JDBC driver does not take advantage of it

any attempt to map user defined types ends with exception

java.sql.SQLFeatureNotSupportedException: Method org.postgresql.jdbc4.Jdbc4Array.getArrayImpl(long,int,Map) is not yet implemented.

I have used both PGConnection.addDataType and Jdbc4Array,gerArray(Map<String, Class <?>>)
both techniques ended with the exception above

I have located the source code part that generates the Exception and observed that the exception is always generated when the base type is not one of the default types

it seems support for user defined types is incomplete
are there any plans for finishing this implementation in the future?
are there any workarounds I am not aware of? or a replacement technique?

[valgog]

Hello,

you can try to use https://github.com/zalando/java-sproc-wrapper. We are just finishing working on merging of https://github.com/danielnowak/sproc-spring-mapper into the code of the sproc-wrapper and optimizing caching for the mapping tree. So I hope, that after tests of the changes are done this week, we will push the changes to the java-sproc-wrapper repository.

The current code is fully functional and is used at my company in production environment very successfully.

Regards,

-- Valentin

[eliasbalasis]

Thank you,

I have discovered something new

surprisingly Jdbc4Array,gerResultSet() takes advantage of PGConnection.addDataType user defined type registrations
however Jdbc4Array,gerResultSet(Map<String,Class<?>>) reports "notImplemented" error

nevertheless, the rest is relatively easy

register subclasses of PGobject with PGConnection.addDataType
then call Jdbc4Array,gerResultSet()
finally, use PGObject,getValue() to get a String representation of the user defined type and translate that to a Java representation

I still wonder why Jdbc4Array.getArray(), Jdbc4Array.getArray(Map<String,Class>) and JsbcArray.getResultSet(Map>) report "notImplemented" error

[davecramer]

Mostly due to lack of time. Patches gladly accepted.

Dave Cramer

On Thu, Jun 20, 2013 at 1:31 PM, eliasbalasis notifications@github.comwrote:

Thank you,

I have discovered something new

surprisingly Jdbc4Array,gerResultSet() takes advantage of
PGConnection.addDataType user defined type registrations
however Jdbc4Array,gerResultSet(Map>) reports "notImplemented" error

nevertheless, the rest is relatively easy

register subclasses of PGobject with PGConnection.addDataType
then call Jdbc4Array,gerResultSet()
finally, use PGObject,getValue() to get a String representation of the
user defined type and translate that to a Java representation

I still wonder why Jdbc4Array.getArray(), Jdbc4Array.getArray(Map>) and
JsbcArray.getResultSet(Map>) report "notImplemented" error

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/63#issuecomment-19768689
.

[eliasbalasis]

I understand,

unfortunately lack of time is a common issue

I will keep it in mind

[valgog]

So if translating a string representation of our type is not a problem, then of cause you can do like you described.

But if you start transferring relatively complex objects (arrays of types containing arrays or quoted texts) mapping them to Java objects is not so trivial.

[eliasbalasis]

Indeed,

the more complex the user defined type the more complex the construction of the Java representation

however, it seems that this is the recommended way to handle user defined types translation

register PGobject descendant and implement translation from PG string representation
moreover, this is what implementations of well-known composite type registrations do
(see. PGmoney, PGpolygon, PGcircle, PGpoint, etc.)

[eliasbalasis]

I was thinking,

are there any generalized parsers for PG string representations to assist translation to Java representation?

[valgog]

You should be able to use the parser that sproc-wrapper is using. And please give me feedback, why you do not consider it an option.

[eliasbalasis]

That sounds good,

I wanted to avoid the burden of adding one more framework and the related learning curve / effort to the project

however, the use of a generalized parser, included in s-proc as you are saying, makes it more appealing

I will check it out

[davecramer]

Have you resolved this ?

[ringerc]

See also Issue #24

[OrangeDog]

This appears to be fixed in 9.4.1208.

[davecramer]

stale