Re: Register arbitrary types Framework - Mailing list pgsql-jdbc
From | Markus Schaber |
---|---|
Subject | Re: Register arbitrary types Framework |
Date | |
Msg-id | 20040311132722.639a3d7b@kingfisher.intern.logi-track.com Whole thread Raw |
In response to | Re: Register arbitrary types Framework (Kris Jurka <books@ejurka.com>) |
List | pgsql-jdbc |
Hi, Kris, On Thu, 11 Mar 2004 00:55:20 -0500 (EST) Kris Jurka <books@ejurka.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@logi-track.com | www.logi-track.com
pgsql-jdbc by date: