Re: Register arbitrary types Framework - Mailing list pgsql-jdbc
From | Markus Schaber |
---|---|
Subject | Re: Register arbitrary types Framework |
Date | |
Msg-id | 20040318152808.54cdfc39@kingfisher.intern.logi-track.com Whole thread Raw |
In response to | Re: Register arbitrary types Framework (Kris Jurka <books@ejurka.com>) |
Responses |
Re: Register arbitrary types Framework
Re: Register arbitrary types Framework |
List | pgsql-jdbc |
Hi, Kris, On Wed, 17 Mar 2004 02:29:07 -0500 (EST) Kris Jurka <books@ejurka.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, Markus (*) 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 Followup. -- 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@logi-track.com | www.logi-track.com
pgsql-jdbc by date: