cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@supereva.it>
Subject Re: new sql logicsheet!
Date Wed, 06 Sep 2000 07:29:38 GMT
----- Original Message ----- 
From: "Donald Ball" <balld@webslingerZ.com>


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

Yup. On an NT machine my program with Access and ODBC bridge
brings down the whole JVM after closing something like five connections!

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

Oh no, now what do I do? :-(
Ok, at interim I'll synch the querying.
IT REALLY SUCKS! :-(

>  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