Re: org.postgresql.Serialize

Quoting Jeff Duffy <jduffy@greatbridge.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@retep.org.uk
PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/