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).
Dan.
