Re: Register arbitrary types Framework

Hi, Kris,

On Thu, 18 Mar 2004 12:16:13 -0500 (EST)
Kris Jurka <books@ejurka.com> wrote:

> Well this cleanup is something I'm actually more interested in, my
> work on adding COPY support to the driver has kind of stalled because
> I need the ability to read/write internal data types and all of this
> knowledge is contained in the Statement/ResultSet classes.

Okay, so maybe my Ideas will have a good side-effect :-)

> > (*) 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.
>
> Yes, this is an issue I hadn't considered and am interested to see
> your reply.

Okay, here are my thoughts:


- Have the user explicitly register them. Each factory instance has a
list of SQL types and a list of java classes it knows to process, and
the factory creator must know all possible subclasses. Most of the
simple classes (Integer, String etc.) are declared final, so they don't
have any problems. This also works fine for PostGIS or JTS Geometries
where we create different java subclasses of Geometry from the same SQL
type, because the Factory knows what to create (just as PGGeometry does
now).

However, whenenever the user intends to setObject() his own subclasses
of those known classes, he has to manually register those classes (e. G.
by providing his own factory derivate).


- Fall-back factory probing. The factory functions have a probe()
method that returns true when the factory believes to be able to
handle the java class. Whenever we don't find the class in our hash,
we probe the factories until the first"hit", and register this factory
for the class.

The probe() method can internally use instanceof or
reflection. This way it is possible to test for Interfaces or to handle
all Objects that have a getSQLrepresentation() bean property etc...


- Super-Class probing. Whenever we don't know the class, we try with the
getSuperclass() result instead. This is repeated until we get to
java.lang.Object which has a "write-only" factory calling toString().

This can be enhanced by calling the getInterfaces() method on every
tested class, and look whether we have a registration for one of the
implemented Interfaces (which are represented by Class objects, too).


Disclaimer: It's late, and so I can't guarantee that above thoughts are
understandable. And I did not yet think about Arrays and primitive
types...

Thanks for your patience,
Markus
--
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