org.postgresql.Serialize - Mailing list pgsql-jdbc
From | Jeff Duffy |
---|---|
Subject | org.postgresql.Serialize |
Date | |
Msg-id | Pine.LNX.4.21.0101272344090.30608-100000@cairhien.alanne.com Whole thread Raw |
Responses |
Re: org.postgresql.Serialize
|
List | 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
pgsql-jdbc by date: