Thread: Again the JSCreator and Metadata issues

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.CachedRowSetDataProvider.getMetaData(CachedRowSetDataProvider.java:1299)
at com.sun.data.provider.impl.CachedRowSetDataProvider.getFieldKeys(CachedRowSetDataProvider.java:485)
at com.sun.rave.propertyeditors.binding.data.BindValueToDataProviderPanel.propertyChanged(BindValueToDataProviderPanel.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(CachedRowSetXImpl.java:872)
at com.sun.sql.rowset.CachedRowSetXImpl.getMetaData(CachedRowSetXImpl.java:2337)
at com.sun.data.provider.impl.CachedRowSetDataProvider.getMetaData(CachedRowSetDataProvider.java:1297)

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.CachedRowSetDataProvider.getMetaData(CachedRowSetDataProvider.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

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 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.CachedRowSetDataProvider.getMetaData(CachedRowSetDataProvider.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

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


>>> Kris Jurka <books@ejurka.com>  >>>

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

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

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 setTransactionIsolation(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_TRANSACTION);
System.out.println("Cannot change transaction isolation level in the middle of a transaction. Old TransactionIsolation "+getTransactionIsolation()+
" new unset TransactionIsolation "+level);

String isolationLevelName = getIsolationLevelName(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(isolationLevelSQL); // nb: no BEGIN triggered
}


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

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

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/pgsql-jdbc/2005-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