cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject RE: new sql logicsheet!
Date Wed, 06 Sep 2000 06:49:38 GMT
On Tue, 5 Sep 2000, Per Kreipke wrote:

> > > This behaviour is allowed by JDBC. ResultSet javadoc states "For maximum
> > > portability, ResultSet columns within each row should be read in
> > > left-to-right order and each column should be read only once."
> >
> > Geez. Pardon my language, but that is simply ass.
> 
> I love tech talk :) It's a shitty constraint but it might help speed up lots
> of implementations, which JDBC needs as far as I can tell (or maybe it's the
> JDBC-ODBC bridge that's slow).

note that the JDBC-ODBC bridge is terrible and is really not recommended
for use in production environments - not only is it slow only implements
JDBC minimally, it's known to have thread safety issues under certain
circumstances. if you're stuck with access, i'm pretty sure there is a
type 4 driver for access specifically (i could easily be wrong tho).
access itself has been known to corrupt data when multiple processes are
operating on the database simultaneously. my take - access is fine for
rapid prototyping if you get off on that kind of thing but use a real
database (mysql, postgresql, oracle, etc.) for storing real data.

> > > The problem in esql is that you can get data in a ResultSet in a number
> > > of different ways (get-date, get-time, get-timestamp just to mention a
> > > few) so the cache has to be smarter. Maybe adding a cache for
> > > getString() results would be enough for most cases ?
> >
> > I reckon we could stick a hashtable or something in front of the
> > resultset, but we can't just get strings or else you won't be able to
> > nicely format dates or real numbers. but if we get objects instead, we
> > have to write our own getXXXX methods for strings, ints, reals,
> > etc. instead of relying on the ResultSet. hmmm...
> 
> How about declaring whatever you decide as an optional feature that doesn't
> get used by default? E.g. no copies of any objects or strings are made
> unless you ask for this cached-value feature. It could be an attribute of
> the <esql:results> tag.
> 
> <esql:results cacheValues="yes">....

yeah, that's probably worthwhile. icky to code in conditionally tho.

> Naive question: isn't a ResultSet a container of other simpler objects that
> could be stored in the hashtable/cache-container instead of strings?

nope. ResultSet is an interface which describes how to access data from a
SQL query. Implementations of ResultSet may well put the queried data into
a container from which they retrieve it, or they may well leave the byte
stream uninterpreted until a column is retrieved. You can probably always
call the getObject method and retrieve a column's value as a java object,
but then you're going to have to handle the casting when someone tries to
retrieve it as a string, an int, a date, a double, etc.

i think i'll probably simply stick to getString if the user wants me to
cacheValues.

- donald


Mime
View raw message