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 Wed, 06 Sep 2000 15:09:35 GMT
> > > > 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.

Thanks. Very helpful! I use Access when developing locally but the
production server is using MS SQL Server 7.0, but I was still using the
bridge. I'll look around to see if there's a native JDBC suite for SQL7
(know of any?).

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

Just curious, why is that? If the default is "no", you can't just test in an
<xsl:if> for the attribute? Not recommended?

I was about to start writing my own taglibs, should I not use default values
for attributes and check for their existence?

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

Ok. That makes sense.

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



View raw message