Re: Register arbitrary types Framework

Hi, Kris,

On Thu, 11 Mar 2004 00:55:20 -0500 (EST)
Kris Jurka <books(at)ejurka(dot)com> wrote:

> I see what you are getting at, but I don't see this as all that
> useful. How is this much better than creating a PGObject adapter
> class to bridge the differences between your object and the driver?

In my eyes, it has the following advantages:

- Less overhead. For every read Object, an additional wrapper has to be
instantiated just to be thrown away afterwards.

- More readable code. For every getObject(), you need an additional line
to call getGeometry() or whatever unwrapping method you use.

- Unification for the user with "internal" Objects like TimeStamp,
Integer or String, where getObject() returns the Object directly.

- Possible simplification of the Driver code as we may even change the
forementioned internal Objects to use the new type system, they're just
preloaded into the type table.

- This way, we could even allow the Users to "override" the internal
types, e. G. to return Collections instead of Arrays, or customized/
localized calendar objects instead of TimeStamps etc.

- We can have one set of Geometry Java Objects for different SQL
databases, and we only have to mess with it at the database/driver
specific connection initialization, but not in the code that fires the
queries.

> Wouldn't you need to make some kind of modification to the JTS object
> when doing a setObject() call? I find it difficult to see its
> toString() implementation mapping directly to a pg server side type.

Luckily, both JTS and PostGIS Objects return their WKT representation
when calling toString(), and PostGreSQL understands this.

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.

> Perhaps you could give us some more specifics on the database types
> involved and why getObject has to return an instance of your object
> instead of an intermediary.

Currently, we have PostGIS geometries in the database, which can be read
into PostGIS Java objects and JTS Java objects by using the PostGIS
Wrapper rsp. our own JTS Wrapper.

Our app itsself doesn't know anything about the wrappers (and doesn't
want to know because it is designet to transparently support other I/O
methods, too). And as our Queries are generic and user-configurable, and
support other built-in types as timestamps, currently our SQL layer
calls an unwrap() method after each getObject(). This unwrap() function
tests for known Wrapper classes and calls their getGeometry() or similar
method.

Thanks,
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(at)logi-track(dot)com | www.logi-track.com