cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <>
Subject RE: new sql logicsheet!
Date Tue, 05 Sep 2000 20:19:59 GMT
> > I had this sort of problem with M$ Access that refuses getting the same
> > row/column more than two or three times.
> > The workaround was use a HashMap as a cache in front of
> > ResultSet.getString()
> >
> > 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).

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

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


View raw message