db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: PreparedStatement.setXXX methods do not set up ContextStack. Is that right and if so, why?
Date Mon, 05 Mar 2007 06:48:23 GMT
Another solution that I have been thinking of is to have the locale
dependents datatypes by aware of their locale so they can use that locale
information in their locale sensitive methods. So, for eg, in the ij script
example that we are discussing, SQLTimestamp in it's constructor should get
the Locale/LocaleFinder/some other effective object (copying Dan's line
literally here) and locale sensitive methods like setValue can simply find
the locale info in it's class itself.

So, in other words, rather than passing the locale info to the locale
sensitive methods, pass it to the locale sensitive datatype in it's
constructor and use that locale info in all the locale sensitive methods in
that datatype class.

How does this sound?
Mamta


On 3/3/07, Daniel John Debrunner <djd@apache.org> wrote:
>
> Mamta Satoor wrote:
> ******part of mail snipped here******


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

Mime
View raw message