PostgreSQL JDBC - Again the JSCreator and Metadata issues

Author

Again the JSCreator and Metadata issues

pedro farinha

2005-11-17, 3:24 am

Hi,
I am testing the new JSC2 early access and I come across a old
problem....getResultMetaData null values (I think).
In JSC 1 the driver works fine but on this early access version it
doesn't.
I am posting what I think is relevant of the trace.
I am not sure if this is a issue with the driver or the JSC it self so I
am posting this into here as well as into the EAfeedback program.

any ideas?

psql Version is 8.0.1
JDBC postgresql-8.1-404.jdbc2ee.jar or postgresql-8.1-404.jdbc3.jar.

java.lang.RuntimeException: java.sql.SQLException: Invalid column
display size. Cannot be less than zero
at
com.sun.data.provider.impl. CachedRowSetDataProv
ider. getMetaData(CachedRo
wSetDataProvider.java:1299)
at
com.sun.data.provider.impl. CachedRowSetDataProv
ider. getFieldKeys(CachedR
owSetDataProvider.java:485)
at
com.sun.rave.propertyeditors.binding.data. BindValueToDataProvi
derPanel. propertyChanged(Bind
ValueToDataProviderP
anel.java:415)
at
com.sun.rave.insync.live.LiveUnit. firePropertyChanged(
LiveUnit.java:1755)

(...)

Caused by: java.sql.SQLException: Invalid column display size. Cannot be
less than zero
at
javax.sql.rowset.RowSetMetaDataImpl. setColumnDisplaySize
(RowSetMetaDataImpl.java:267)
at
com.sun.sql.rowset.CachedRowSetXImpl. initMetaData(CachedR
owSetXImpl.java:872)
at
com.sun.sql.rowset.CachedRowSetXImpl. getMetaData(CachedRo
wSetXImpl.java:2337)
at
com.sun.data.provider.impl. CachedRowSetDataProv
ider. getMetaData(CachedRo
wSetDataProvider.java:1297)

Kris Jurka

2005-11-18, 8:24 pm

On Thu, 17 Nov 2005, pedro farinha wrote:

> I am testing the new JSC2 early access and I come across a old
> problem....getResultMetaData null values (I think). In JSC 1 the driver
> works fine but on this early access version it doesn't. I am posting
> what I think is relevant of the trace. I am not sure if this is a issue
> with the driver or the JSC it self so I am posting this into here as
> well as into the EAfeedback program.
>
> java.lang.RuntimeException: java.sql.SQLException: Invalid column
> display size. Cannot be less than zero
> at
> com.sun.data.provider.impl. CachedRowSetDataProv
ider. getMetaData(CachedRo
wSetDataProvider.java:1299)

I believe you have a variable length field in your table. Sun's
CachedRowSet implementation examines the ResultSetMetaData and creates its
own copy of it. The postgresql JDBC driver returns -1 for
ResultSetMetaData. getColumnDisplaySize
() meaning unknown for variable
length fields, like say a column of type "text". Sun does not like this
value and reports an error. In the past we've tried to ask Sun for some
advice in this area and got nothing in response. Other than -1 the
only other real defensible value for getColumnDisplaySize
would
probably be Integer.MAX_VALUE. We've been concerned that GUIs would
try to actually use this provided value and they would blow up, but
the only complaints we've heard are from people disliking the -1
value and this problem doesn't seem to be going away.

I suggest we try returning Integer.MAX_VALUE for a while and see what
complaints we get. Objections?

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

pedro farinha

2005-11-18, 8:24 pm

Hi Kris,
I have made a new post into the creator Feedback program, referring
you're assumptions and solutions. Lets see if we can get any news from
them before doing the changes, if any.
I haven't tried it yet but I will try to verify that the problem is
really related with "variable size fields". If it is we can always say
"in order to use creator you must not use variable size fields".
I will try to test with a table with all fields with fixed size, then
with fields with variable size and see what I'll hit.
On my post to the feedback program I raised the question of
int.MAX_VALUE and what would be the impact of it. I also suggested a
"default value" which while not correct may not impact much into the
real implementation and also the magic number "0". What does it mean
when you have a column with size = 0? . As you can see I am not very
familiar with DB structures at all, thus the probably stupid question,
what is the size of a "blob" column ? can it be fixed?.

thanks for you're help.

On Fri, 2005-11-18 at 18:41, Kris Jurka wrote:

> On Thu, 17 Nov 2005, pedro farinha wrote:
>
>
> I believe you have a variable length field in your table. Sun's
> CachedRowSet implementation examines the ResultSetMetaData and creates its
> own copy of it. The postgresql JDBC driver returns -1 for
> ResultSetMetaData. getColumnDisplaySize
() meaning unknown for variable
> length fields, like say a column of type "text". Sun does not like this
> value and reports an error. In the past we've tried to ask Sun for some
> advice in this area and got nothing in response. Other than -1 the
> only other real defensible value for getColumnDisplaySize
would
> probably be Integer.MAX_VALUE. We've been concerned that GUIs would
> try to actually use this provided value and they would blow up, but
> the only complaints we've heard are from people disliking the -1
> value and this problem doesn't seem to be going away.
>
> I suggest we try returning Integer.MAX_VALUE for a while and see what
> complaints we get. Objections?
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

Kevin Grittner

2005-11-21, 8:24 pm

No objection here -- I don't know how else to interpret the docs
for this method, which is supposed to return:

"the normal maximum number of characters allowed as the width
of the designated column"

Any GUI app should be prepared to truncate or wrap large values.

-Kevin

[color=darkred]

On Thu, 17 Nov 2005, pedro farinha wrote:

I believe you have a variable length field in your table. Sun's
CachedRowSet implementation examines the ResultSetMetaData and creates
its
own copy of it. The postgresql JDBC driver returns -1 for
ResultSetMetaData. getColumnDisplaySize
() meaning unknown for variable
length fields, like say a column of type "text". Sun does not like this

value and reports an error. In the past we've tried to ask Sun for some

advice in this area and got nothing in response. Other than -1 the
only other real defensible value for getColumnDisplaySize
would
probably be Integer.MAX_VALUE. We've been concerned that GUIs would
try to actually use this provided value and they would blow up, but
the only complaints we've heard are from people disliking the -1
value and this problem doesn't seem to be going away.

I suggest we try returning Integer.MAX_VALUE for a while and see what
complaints we get. Objections?

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Kris Jurka

2005-11-23, 8:24 pm

On Fri, 18 Nov 2005, Kris Jurka wrote:

> [People don't like -1 for getColumnDisplaySize
()]
>
> I suggest we try returning Integer.MAX_VALUE for a while and see what
> complaints we get. Objections?
>

I've adjusted this in cvs. Please try out one of these jars and let us
know how that works out.

http://ejurka.com/pgsql/jars/pf/

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

pedro farinha

2005-11-25, 3:23 am

Hi Kris,
The binding and display works fine with the
postgresql-8.2dev-500pf.jdbc3.jar, I am using Java1.5 (Creator ships
with it) so I didn't try neither the "EE" or jdbc2 version, but I reckon
it should not be a problem
Thanks for that.

Can you tell me if this fix (if that) will be included in the cvs? or in
a snapshot? I would like to make a reference to it on the Sun forum.

One other issue:
On the early-access feedback discussion there are some issues relating
with changing the transaction isolation level in the middle of the
transaction. You know anything about it?

Matthias Jakob posted a solution/workaround, which is basically removing
the exception. see below.

Thanks again for fixing this.

public void setTransactionIsolat
ion(int level) throws SQLException
{
if (protoConnection. getTransactionState(
) !=
ProtocolConnection.TRANSACTION_IDLE)
//throw new PSQLException(GT.tr("Cannot change transaction isolation
level in the middle of a transaction."),
// PSQLState. ACTIVE_SQL_TRANSACTI
ON);
System.out.println("Cannot change transaction isolation level in the
middle of a transaction. Old TransactionIsolation

" +getTransactionIsola
tion()+
" new unset TransactionIsolation
"+level);

String isolationLevelName = getIsolationLevelNam
e(level);
if (isolationLevelName == null)
throw new PSQLException(GT.tr("Transaction isolation level {0} not
supported.", new Integer(level)), PSQLState.NOT_IMPLEMENTED);

String isolationLevelSQL = "SET SESSION CHARACTERISTICS AS TRANSACTION
ISOLATION LEVEL " + isolationLevelName;
execSQLUpdate(isolat
ionLevelSQL); // nb: no BEGIN triggered
}

On Wed, 2005-11-23 at 22:01, Kris Jurka wrote:

> On Fri, 18 Nov 2005, Kris Jurka wrote:
>
>
> I've adjusted this in cvs. Please try out one of these jars and let us
> know how that works out.
>
> http://ejurka.com/pgsql/jars/pf/
>
> Kris Jurka
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql
.org so that your
> message can get through to the mailing list cleanly

Kris Jurka

2005-11-25, 3:23 am

On Fri, 25 Nov 2005, pedro farinha wrote:

> Can you tell me if this fix (if that) will be included in the cvs? or in
> a snapshot? I would like to make a reference to it on the Sun forum.

Yes, this has been added in cvs, but I've yet to produce a new development
release. Due to some other driver events I'll put out a new dev release
on the official website in the next few days.

> One other issue:
> On the early-access feedback discussion there are some issues relating
> with changing the transaction isolation level in the middle of the
> transaction. You know anything about it?
>

See this message for an explanation:

http://archives.postgresql.org/pgsq...11/msg00112.php

I believe the spec suggested deferring the changing of isolation levels
until the next transaction begins, but we decided that could mask serious
coding errors because the isolation level wasn't actually changing at the
time of the call. Revisiting this is an option, but it still seems like a
bad idea to me.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Sponsored Links