Re: getObject()

Sorry, they were until this morning probably older than Aug 24, I
rebuilt them from source last evening

Dave

-----Original Message-----
From: pgsql-jdbc-owner(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Antonio Fiol
Bonnín
Sent: September 24, 2001 11:43 AM
To: Antonio Fiol Bonnín; pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] getObject()

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(at)anoncvs(dot)postgresql(dot)org:/projects/cvsroot login
>
> password: postgresql
>
>
> cvs -d :pserver:anoncvs(at)anoncvs(dot)postgresql(dot)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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster