[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-java
Subject:    Re: JDBC MySQL design question
From:       "Jeff Kilbride" <jeff () kilbride ! com>
Date:       2002-06-19 18:31:52
[Download RAW message or body]

Well, she stated that she needed the data "later", so I assumed she didn't
want to keep the connection open. Personally, I do a lot of local caching --
keep the data locally for an hour and then flush the cache, to lighten the
load on the DB -- and I implement most of that with HashMaps. Otherwise, I
agree. It's easier to just use the ResultSet directly. I haven't taken a
look at JDBC 3.0, yet, and I don't have any idea when mm.mysql will be
compliant. Disconnected ResultSets would be a nice addition -- but then I'd
have to rewrite a bunch of code. Can't win for losing...   :(

Thanks,
--jeff

----- Original Message -----
From: "Scott Hodson" <scott@ubero.com>
To: "'Jeff Kilbride'" <jeff@kilbride.com>
Sent: Wednesday, June 19, 2002 10:54 AM
Subject: RE: JDBC MySQL design question


> Why not just use the Resultset objects?  They are essentially the same?
> I guess the issue would be that they keep the connection to the DB open.
> JDBC 3.0 solves that and you can now have disconnected result sets.
>
> Any idea on when MM.MySQL will be JDBC 3.0 compliant?
>
> -----Original Message-----
> From: Jeff Kilbride [mailto:jeff@kilbride.com]
> Sent: Wednesday, June 19, 2002 10:37 AM
> To: Java MySQL
> Subject: Re: JDBC MySQL design question
>
>
> I second the Map idea. Whenever I pull info from the database, I usually
> store it in an array of HashMaps, where the keys equal the column names.
> Makes it very easy to loop through data.
>
> --jeff
>
> ----- Original Message -----
> From: <jlafontaine@lyon-partdieu.sema.slb.com>
> To: "Peter T. Abplanalp" <pta@psaconsultants.com>; "Java + MySQL List"
> <java@lists.mysql.com>
> Sent: Wednesday, June 19, 2002 9:26 AM
> Subject: RE: JDBC MySQL design question
>
>
> > I would do as Peter said.
> > If you don't want to create an author object, just use a Map with the
> > name of the fields as keys and the values of the fields as values of
> > the Map.
> >
> >
> > -----Message d'origine-----
> > De : Peter T. Abplanalp [mailto:pta@psaconsultants.com] Envoyé :
> > mercredi 19 juin 2002 17:59 À : Java + MySQL List
> > Objet : Re: JDBC MySQL design question
> >
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, Jun 19, 2002 at 11:41:53AM -0400, Laura Findley wrote:
> > >
> > > So... my options seem to be... store the ResultSet info in an 1)
> > > array,
> 2)
> > > vector or 3) perhaps create another MySQL table. Since I have 5
> > > fields
> (3
> > > Strings, 2 int) I need to store... it seems like it would be best to
> just
> > > create another MySQL table.
> >
> > i would not use 1 as it would be difficult to keep track of all the
> > data associated with each author.
> >
> > i would go for option 2 with a twist.  i would create an author
> > object, populate it with the first result set stuff and stick them in
> > a vector.  you might even think about using an app server like jboss
> > and make the author an entity bean but that may be a little overkill
> > for a newbie.
> >
> > i would not use 3 either.  this seems to me to be a very ugly way to
> > do this, especially if you are going to have multiple users accessing
> > the app at the same time.
> >
> > > If anyone knows of good websites/books that discuss storing & using
> > > ResultSet info, I'd really appreciate it. I've been looking at
> > >
> >
> http://developer.java.sun.com/developer/onlineTraining/Database/JDBC20In
> tro/
> > > & have a few books on Java but none that are really helping with
> > > this.
> >
> > the java.sun.com docs and tutorials are pretty good.  as i said above,
>
> > i would also look into j2ee.  depending on the complexity of the app,
> > it might be overkill.
> > - --
> >
> > Peter Abplanalp
> >
> > Email:   pta@psaconsultants.com
> > PGP:     pgp.mit.edu
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.7 (GNU/Linux)
> >
> > iD8DBQE9EKo4ggA8sH0iRXQRAqBqAJ47TdlDK679W0z42rSQYKna2oky5wCeJwey
> > 5OdyDFwTaSIvr9ALGQuY1RI=
> > =WiYX
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > Please check "http://www.mysql.com/Manual_chapter/manual_toc.html"
> > before posting. To request this thread, e-mail
> > java-thread3853@lists.mysql.com
> >
> > To unsubscribe, send a message to the address shown in the
> > List-Unsubscribe header of this message. If you cannot see it, e-mail
> > java-unsubscribe@lists.mysql.com instead.
> >
> > ---------------------------------------------------------------------
> > Please check "http://www.mysql.com/Manual_chapter/manual_toc.html"
> > before posting. To request this thread, e-mail
> > java-thread3854@lists.mysql.com
> >
> > To unsubscribe, send a message to the address shown in the
> > List-Unsubscribe header of this message. If you cannot see it, e-mail
> > java-unsubscribe@lists.mysql.com instead.
> >
>
>
> ---------------------------------------------------------------------
> Please check "http://www.mysql.com/Manual_chapter/manual_toc.html"
> before posting. To request this thread, e-mail
> java-thread3855@lists.mysql.com
>
> To unsubscribe, send a message to the address shown in the
> List-Unsubscribe header of this message. If you cannot see it, e-mail
> java-unsubscribe@lists.mysql.com instead.
>
>
>


---------------------------------------------------------------------
Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
posting. To request this thread, e-mail java-thread3856@lists.mysql.com

To unsubscribe, send a message to the address shown in the
List-Unsubscribe header of this message. If you cannot see it,
e-mail java-unsubscribe@lists.mysql.com instead.

[prev in list] [next in list] [prev in thread] [next in thread]