Обсуждение: JPOX Types.CHAR error
I'm playing around with JPOX right now trying to get things to work, but
I'm having a problem with mapping the Java types to the JDBC types it
seems like. JPOX comes back and tells me that the JDBC driver doesn't
support Types.CHAR, which I find very hard to believe.
I'm running PostgreSQL 8.1.2 (just on my testing box) and I have JDBC
driver postgresql-8.1-405.jdbc3.jar. I also have the latest (1.1.0)
JPOX jars and the jdo2-api-2.0.jar. I'm running on an XP machine with
Java 1.5.0_6. Any help would be great, thanks!
Here's the stack trace:
22:47:00,978 (main) ERROR [JPOX.SchemaTool] - An exception was thrown
during the operation of SchemaTool. Please refer to the log for full
details. The following may help : Failed to generate new Mapping of type
org.jpox.store.rdbms.mapping.CharRDBMSMapping, exception : JDBC type
"Types.CHAR" not supported by the JDBC driver. Please check your
specification of "jdbc-type" and the driver capabilities.
org.jpox.store.exceptions.UnsupportedDataTypeException: JDBC type
"Types.CHAR" not supported by the JDBC driver. Please check your
specification of "jdbc-type" and the driver capabilities.
at
org.jpox.store.rdbms.adapter.DatabaseAdapter.getTypeInfo(DatabaseAdapter
.java:706)
at
org.jpox.store.rdbms.mapping.CharRDBMSMapping.getTypeInfo(CharRDBMSMappi
ng.java:205)
at
org.jpox.store.rdbms.mapping.CharRDBMSMapping.initialize(CharRDBMSMappin
g.java:187)
at
org.jpox.store.rdbms.mapping.CharRDBMSMapping.<init>(CharRDBMSMapping.ja
va:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.jpox.store.rdbms.mapping.RDBMSMappingFactory.createMapping(RDBMSMapp
ingFactory.java:78)
at
org.jpox.store.rdbms.mapping.AbstractRDBMSMappingManager.createDatastore
Mapping(AbstractRDBMSMappingManager.java:460)
at
org.jpox.store.mapping.SingleFieldMapping.prepareDatastoreMapping(Single
FieldMapping.java:103)
at
org.jpox.store.mapping.SingleFieldMapping.<init>(SingleFieldMapping.java
:66)
at
org.jpox.store.mapping.BaseStringMapping.<init>(BaseStringMapping.java:5
7)
at
org.jpox.store.mapping.StringMapping.<init>(StringMapping.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.jpox.store.mapping.MappingFactory.createMapping(MappingFactory.java:
114)
at
org.jpox.store.mapping.AbstractMappingManager.getMapping(AbstractMapping
Manager.java:348)
at
org.jpox.store.rdbms.table.ClassTable.addFieldMetaData(ClassTable.java:4
30)
at
org.jpox.store.rdbms.table.ClassTable.manageClass(ClassTable.java:392)
at
org.jpox.store.rdbms.table.ClassTable.initializeForClass(ClassTable.java
:775)
at
org.jpox.store.rdbms.table.ClassTable.initialize(ClassTable.java:277)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(R
DBMSManager.java:2656)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2268)
at
org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.j
ava:2124)
at
org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:577)
at org.jpox.SchemaTool.createSchemaTables(SchemaTool.java:225)
at org.jpox.SchemaTool.main(SchemaTool.java:855)
-Jason Porter
On Mon, 15 May 2006, Jason Porter wrote: > I'm playing around with JPOX right now trying to get things to work, but > I'm having a problem with mapping the Java types to the JDBC types it > seems like. JPOX comes back and tells me that the JDBC driver doesn't > support Types.CHAR, which I find very hard to believe. > > 22:47:00,978 (main) ERROR [JPOX.SchemaTool] - An exception was thrown > during the operation of SchemaTool. Please refer to the log for full > details. The following may help : Failed to generate new Mapping of type > org.jpox.store.rdbms.mapping.CharRDBMSMapping, exception : JDBC type > "Types.CHAR" not supported by the JDBC driver. Please check your > specification of "jdbc-type" and the driver capabilities. > at > org.jpox.store.rdbms.adapter.DatabaseAdapter.getTypeInfo(DatabaseAdapter > .java:706) > > at > org.jpox.store.rdbms.mapping.CharRDBMSMapping.getTypeInfo(CharRDBMSMappi > ng.java:205) A quick check reveals nothing obviously wrong with how DatabaseMetaData.getTypeInfo returns data for Types.CHAR. The best thing to do would probably add some debugging code to JPOX to show how it sets up its type information and what it thinks is has available when the failing call is made. Kris Jurka
> A quick check reveals nothing obviously wrong with how > DatabaseMetaData.getTypeInfo returns data for Types.CHAR. Well that depends on your point of view ;-) PSQL 8.1-405 JDBC driver now returns SQL type "char" as Types.OTHER (instead of Types.CHAR), and returns "bpchar" as Types.CHAR. Since PSQL has always supported "char" as Types.CHAR (since it kinda seems reasonable), JPOX uses that as the default ... and it is no longer there (yet is in PSQL 8.0). I can set up JPOX to fake this type for users so they see no change but it would make more sense (to me) to have the JDBC driver return consistent with previous incarnations. Maybe there was a good reason why "char" is no longer Types.CHAR ? -- Andy
On Tue, 16 May 2006, Andy Jefferson wrote:
>> A quick check reveals nothing obviously wrong with how
>> DatabaseMetaData.getTypeInfo returns data for Types.CHAR.
>
> Well that depends on your point of view ;-)
> PSQL 8.1-405 JDBC driver now returns SQL type "char" as Types.OTHER (instead
> of Types.CHAR), and returns "bpchar" as Types.CHAR. Since PSQL has always
> supported "char" as Types.CHAR (since it kinda seems reasonable), JPOX uses
> that as the default ... and it is no longer there (yet is in PSQL 8.0). I can
> set up JPOX to fake this type for users so they see no change but it would
> make more sense (to me) to have the JDBC driver return consistent with
> previous incarnations. Maybe there was a good reason why "char" is no longer
> Types.CHAR ?
>
I'm not sure there's a good reason that "char" isn't returned as
Types.CHAR, but you definitely want to be using bpchar as the default
mapping for Types.CHAR. The type "char" is a single byte datatype
that is really only used for internal system catalogs and is not to be
confused with char(N). One of the bugs you're probably seeing is
that the postgresql jdbc driver does not return the results of
DatabaseMetaData.getTypeInfo sorted according to the javadoc spec of
closest match, but instead returns data in random order.
jurka=# create table chartest (a "char", b char, c char(5));
CREATE TABLE
jurka=# \d chartest
Table "public.chartest"
Column | Type | Modifiers
--------+--------------+-----------
a | "char" |
b | character(1) |
c | character(5) |
jurka=# select a.attname,t.typname FROM pg_attribute a, pg_type t where
a.atttypid = t.oid and a.attrelid = 'chartest'::regclass::oid and a.attnum
> 0;
attname | typname
---------+---------
a | char
c | bpchar
b | bpchar
(3 rows)
Kris Jurka
> I'm not sure there's a good reason that "char" isn't returned as > Types.CHAR, but you definitely want to be using bpchar as the default > mapping for Types.CHAR. Thanks for the reply Kris. Only one question. Has "bpchar" existed in Postgresql for some time (e.g versions 7.0 onwards) or is it recent ? We (JPOX) need to support many versions of Postgresql and I don't want to change historical support here. -- Andy
On Tuesday 16 May 2006 10:57, Andy Jefferson wrote: > > I'm not sure there's a good reason that "char" isn't returned as > > Types.CHAR, but you definitely want to be using bpchar as the default > > mapping for Types.CHAR. > > Thanks for the reply Kris. Only one question. Has "bpchar" existed in > Postgresql for some time (e.g versions 7.0 onwards) or is it recent ? We > (JPOX) need to support many versions of Postgresql and I don't want to > change historical support here. Also, I cannot do bpchar(100) whereas I can do char(100) ... the precision returned by getTypeInfo is limited to 9 for bpchar whereas is 65000 for char. -- Andy
> Also, I cannot do bpchar(100) whereas I can do char(100) ... the precision > returned by getTypeInfo is limited to 9 for bpchar whereas is 65000 for > char. Ignore that. All Postgresql types returned by getTypeInfo() return the precision as 9 ... whatever that is supposed to mean. Any chance that Postgresql JDBC will one day return correct info for the precision ? It would make life a hell of a lot easier for systems that use the results of its JDBC method calls. -- Andy
On Tue, 16 May 2006, Andy Jefferson wrote: >> I'm not sure there's a good reason that "char" isn't returned as >> Types.CHAR, but you definitely want to be using bpchar as the default >> mapping for Types.CHAR. > > Thanks for the reply Kris. Only one question. Has "bpchar" existed in > Postgresql for some time (e.g versions 7.0 onwards) or is it recent ? We > (JPOX) need to support many versions of Postgresql and I don't want to change > historical support here. > bpchar is available in all versions from 7.0 on. Kris Jurka
On Tue, 16 May 2006, Andy Jefferson wrote: >> Also, I cannot do bpchar(100) whereas I can do char(100) ... the precision >> returned by getTypeInfo is limited to 9 for bpchar whereas is 65000 for >> char. > > Ignore that. All Postgresql types returned by getTypeInfo() return the > precision as 9 ... whatever that is supposed to mean. Any chance that > Postgresql JDBC will one day return correct info for the precision ? It > would make life a hell of a lot easier for systems that use the results > of its JDBC method calls. > Improvements have already been made in this are for the 8.2 driver (which can be used against older database versions). It currently reports 10485760 as the precision for bpchar. The complication on your part is that bpchar is kind of an internal type name and you've already noticed that you can't say CREATE TABLE t (a bpchar(5)). The grammar only supports the precision attribute on the external spelling of the type name, char or character. I'm not sure how the pg jdbc driver can help you know this. Kris Jurka