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

org.postgresql.Serialize

From: Jeff Duffy <jduffy(at)greatbridge(dot)com>
To: PgSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: org.postgresql.Serialize
Date: 2001-01-28 05:36:11
Message-ID: Pine.LNX.4.21.0101272344090.30608-100000@cairhien.alanne.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
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:


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:

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

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. 

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

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.

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.

Jeff

-- 
Errors have occurred.
We won't tell you where or why.
Lazy programmers.
		-- Hacking haiku


Responses

pgsql-jdbc by date

Next:From: Didier BretinDate: 2001-01-29 09:02:30
Subject: to much process
Previous:From: Bruce MomjianDate: 2001-01-28 04:26:15
Subject: Re: Open 7.1 items

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