Skip site navigation (1) Skip section navigation (2)

Re: org.postgresql.Serialize

From: Peter T Mount <peter(at)retep(dot)org(dot)uk>
To: Jeff Duffy <jduffy(at)greatbridge(dot)com>
Cc: PgSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: org.postgresql.Serialize
Date: 2001-01-30 08:56:14
Message-ID: 980844974.3a7681ae9f68c@webmail.retep.org.uk (view raw or flat)
Thread:
Lists: pgsql-jdbc
Quoting Jeff Duffy <jduffy(at)greatbridge(dot)com>:

> Hello,
> 
>  I've discovered that I have paralleling some of the nifty
> serialization
> work done in the Postgres JDBC driver, and I'd like to contribute a
> patch after I get the complex stuff working.
> After looking at the code, I have a couple of questions to throw out
> for
> anyone who'd like to comment:

It's been a while since I touched that class, but here goes...

> 1. Is there a reason I'm missing why the tye of object passed for
> storage shouldn't just be obtained by using reflection? Something like:

I thought I used reflection to get both the class name and the 
variables/objects contained within it.

> 
> // (o predeclared)
> public Serializer(Object obj);
>             o = obj;
>  
>             // get the name and load one.
>             String name = o.toString();
> 
>             // strips "class " from the string returned
>             int q = name.indexOf(" ");
>             className = name.substring(q + 1);
>             ...
> Then use the class loader to get one, or cast this one.

It should be loading the class, then using reflection setting each 
variable/object within it.

[all this is from memory, it was about 2 years ago when I wrote it]

> 
> 2. A lot of the grunt work involved is mapping the more complex objects
> to Postgres native ones. I'm building a list (and the code) to attempt
> to support as much of the 1.3 API as possible. 

Yes, Serialize was written with only JDBC1.2 (JDK1.1.3) was out. JDBC2.0 has a 
better method (partly implemented in 7.1), and this week (I'm on a Advanced 
Java course) I'm seeing possible enhancements to object persistence than what 
we have got currently.

We have a lot of old code sitting under getObject()/setObject() that could be 
replaced.

> 
>  This ends up generating some middling complex column types
> Vectors, Lists, etc. translate to arrays, dictionary types translate to
> 
> matrices, etc). Does anyone have experience with possible speed issues
> related to querying complex data types in Postgres?
> 
> 3. I have been creating the tables that map to classes on the fly,
> avoiding the need to 'predeclare' a table before storing objects in it
> as the driver does with create(). This will, however, require some
> decent caching to avoid significant overhead from checking the db to
> see
> if a table describing the class already exists. Any recommendations on
> leveraging the system catalog to help speed this up (other than just
> SELECTing them each time?). 

This is the big problem with our current implementation. One way around it is 
possibly on the first call to getObject()/setObject() we prefetch the available 
tables so the query overhead is reduced.

> 
> 4. I've also been pondering how to allow the user to query for and
> return objects based on the field values without implementing some
> nasty
> SQL extension. Currently I'm restricted to retrieving objects based on
> a
> single attribute/value pair, which obviously isn't going to be flexible
> enough.
> Any comments on an acceptable syntax to say "Give me all of the objects
> of
> class java.util.HashMap that have a key named 'driver' without creating
> full-blown SQL?
> 
>  The issue is that I'd like to keep the query mechanism encapsulated in
> the class, and not have the underlying table structure visible to the
> querying code.

Answer: EJB, which I'm pondering about at the moment (in the background wont do 
anything until I've caught up).

> 
> 5. Should all Strings be stored as text? This is the only way I can see
> avoiding truncation, but it might end up being slow.

Tough one. create() only knows its a String, so it creates it as a text because 
it doesn't know how big those strings are going to be. If you are manually 
creating the tables, you know what sizes they are going to be, so you can 
create them a varchar or whatever.

create() was intended only as a helper.

Peter

-- 
Peter Mount peter(at)retep(dot)org(dot)uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/

In response to

pgsql-jdbc by date

Next:From: Peter T MountDate: 2001-01-30 09:02:43
Subject: Re: to much process
Previous:From: Joseph ShraibmanDate: 2001-01-29 23:57:20
Subject: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group