db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Date Sat, 03 Mar 2007 17:33:44 GMT
Mamta Satoor wrote:
> Hi,
> I noticed that PreparedStatement.executeQuery(like several other JDBC 
> methods) sets up the context stack by calling setupContextStack in 
> EmbeddedStatement's executeStatement method(line 1118). But when setXXX 
> methods are called on PreparedStatement, we do not create a context 
> stack. Why do we not need the context setting for setXXX methods?

Pushing and popping the context stack is an expensive operation, 
requiring to do this on every setXXX() call would have a severe 
performance impact on Derby. Setting (and getting) values should be 
simply setting a value in a DataValueDescriptor and thus has no need to 
setup the context.

> The reason for my question is I ran following simple query in ij
> connect 'jdbc:derby:c:/dellater/db1';
> CREATE TABLE TSTAB (I int, STATUS_TS  Timestamp, PROPERTY_TS Timestamp);
> prepare p as 'select STATUS_TS  from tstab where status_ts = ?';
> execute p using 'values (''20'')';
> When trying to debug through the last statement above ***execute p using 
> 'values (''20'')';***, I found that we reach 
> SQLTimestamp.setValue(String theValue) method. In this method, we try to 
> determine the locale by going through the Context stack but since none 
> was setup for setXXX methods, we always use a null locale irrespective 
> of what territory the database was created with. That doesn't seem like 
> the right thing to do and the reason this is happening is because no 
> context stack was set up for this particular JDBC api.

Sounds like a bug. I do think that the existing code that obtains the 
locale is approaching the problem in entirely the wrong way and probably 
should be written from scratch. E.g. if a data type is locale dependent 
for its string conversion then it should have a setValue(String) method 
that has an additional argument that specifies the locale (either as a 
Locale, a LocaleFinder or some other effective object).


View raw message