Re: getObject()
От | Antonio Fiol Bonnín |
---|---|
Тема | Re: getObject() |
Дата | |
Msg-id | 3BAF5484.EE095C1B@w3ping.com обсуждение исходный текст |
Ответ на | getObject() (Antonio Fiol Bonnín <fiol@w3ping.com>) |
Ответы |
Re: getObject()
|
Список | pgsql-jdbc |
Hi Rene, I am wondering if the driver I am using is outdated (the functionality I am looking for seems to be already implemented, since Aug 24). In fact, I see what you saw about the cache, and looking into it a bit deeper, the cache is effectively updated (at least, on CVS HEAD). Could anyone tell me the date of the driver jars present on http://jdbc.fastcrypt.com ? If it's older than Aug 24, maybe the solution consists simply on creating the new jar files. Thank you very much. Antonio BTW: Brian Weller told me that: > The cvs server recently changed, use this instead: > > cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot login > > password: postgresql > > > cvs -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot co pgsql End of Brian Weller e-mail. Thank you very much, Brian. I (Antonio Fiol Bonnín) wrote some time ago: > Rene Pijlman wrote: > > > On Fri, 21 Sep 2001 17:26:20 +0200, you wrote: > > >When looking at the traffic that is going in and out of my machine, I > > >see many (a real lot of) times the same request. Something like: > > > > > >select typname from pg_type where oid = XXX > > > > > >where XXX is a number (23, 1184, or maybe others) > > > > > >As I use the getObject method to retrieve the different ocjects > > >contained in the resultset (I can't tell whether it's going to be an > > >number or a timestamp beforehand), I imagine that this select statement > > >is the one that helps getObject choose the right type. But, as every row > > >in the resultset will have the same column types, couldn't some caching > > >accelerate everything a lot? > > > > Looking at the source, I see signs of a caching mechanism in > > org.postgresql.Connection.getSQLType(), but at first glance it > > seems that this method doesn't actually add the type it > > retrieves to its own cache. That could very well be the cause of > > the problem. > > That will help, probably. > > > Do you intend to fix this yourself, or are you seeking help from > > this list? If so, it would be nice if you could post a small > > program that reproduces the problem. Its probably very simple, > > but that way we can be sure we're looking at the same problem. > > I was going to try it myself. However, I have not been able to get the > current sources from CVS, as stated below. (I have just retried) > > > >I have tried to connect to CVS, but instructions on > > >http://www.ca.postgresql.org/devel-corner/docs/postgres/cvs.html > > >did not work for me. I got: > > >cvs login: authorization failed: server postgresql.org rejected access > > >to /home/projects/pgsql/cvsroot for user anoncvs > > > > The CVS system is being migrated and there are lots of posts > > about it on the pgsql-hackers list. I'm not sure what the latest > > status is. The latest information should be on > > http://developer.postgresql.org/, but because of the recent > > shutdown of Great Bridge the system is in flux. > > I used the information present on that site. > > If you can have a look at it, what I do is a > > select a::integer, b::timestamp, c::float from table; > > and then I populate vectors by stating > > myVectorA.add(rs.getObject("a")); > > and the same for b and c. > > table has quite a few rows (about 100 to 700, average 250). > > When the code executes, if I start a network packet capture (after many > packets have already passed), I see the stated request about the types (and > presumably its response) going up and down. > > I am using the precompiled driver for Java 1.2 found on > http://jdbc.fastcrypt.com. > > Thank you very much if you may help, either by letting me access the current > source or by providing repaired binaries ;-) > > Now seriously, I am willing to repair this, if possible. > > Thanks. > > Antonio > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
В списке pgsql-jdbc по дате отправления: