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

Re: Register arbitrary types Framework

From: Markus Schaber <schabios(at)logi-track(dot)com>
To: PostGreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Cc: Kris Jurka <books(at)ejurka(dot)com>
Subject: Re: Register arbitrary types Framework
Date: 2004-03-18 14:28:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Hi, Kris,

On Wed, 17 Mar 2004 02:29:07 -0500 (EST)
Kris Jurka <books(at)ejurka(dot)com> wrote:

> I did not receive your reply through the list for some reason, but I 
> stumbled across it in the archives:

Strange... I'll send you a Cc: to be on the safe side :-)

> 	But this problem is why I prefer the second solution using
> 	factories although it is more work to start with. The factory 
> 	instances basically have 2 methods - one for reading and
> 	another one for writing.
> With getObject you can register the factory with a pg internal type
> name that the driver knows, but with setObject you have nothing to
> determine which (if any) factory to use other than the object itself. 
> You could work on some kind of reflection based scheme, but this is
> certainly not symmetric with how getObject works.

Every Object's class can be obtained with the getClass() method. So (as
I weakly hinted in my original post) we can have a Map with the
classes (or fully qualified class names) as keys, and the factories as
values. Using a HashMap as Map, this allows us to find the factory in
constant time (*).

I also think that the current setObject(int, Object) using an 13-branch
if(instanceof)-else construct could be sped up by this - of course, at
the cost of creating the appropriate factory classes. 

On the other hand, this allows some code cleanup by moving most of the
type specific code out of the statement and resultset classes, degrading
the specific setXXX methods to simple wrappers. But this is not my
primary intention - IMHO, it's more like a positive side effect to
have the possibility. It has to be discussed whether this refactoring is
appropriate regarding design and speed issues.

Thanks for your patience,

(*) Of course, correct handling of subclasses is a little more tricky,
but I already have some ideas on how to handle this problem. But
as I don't want to overload this message, I'll outline them in another

markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 z├╝rich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com |

In response to


pgsql-jdbc by date

Next:From: WaldomiroDate: 2004-03-18 15:10:37
Subject: Select for Update
Previous:From: as1024Date: 2004-03-18 01:09:14
Subject: textfiles

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