Re: datatype conversion thoughts
От | Markus Schaber |
---|---|
Тема | Re: datatype conversion thoughts |
Дата | |
Msg-id | 20041012194610.75a0c530@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответ на | datatype conversion thoughts (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
Hi, Kris, [Sorry for the duplicate message - I really should learn how to configure my mailer, this message should have gone to the list directly.] On Sat, 9 Oct 2004 02:19:37 -0500 (EST) Kris Jurka <books@ejurka.com> wrote: > One way of doing this would be provide a PGDataType abstract class > that provided every getXXX method (getInt, getFloat, getBoolean, ...) > which had a default implementation of saying "Invalid conversion...". > Then for each datatype an implementation would be provided that could > parse the underlying data and perform whatever conversions that are > applicable on it. This would work the same way on the reverse side > (converting from java -> pg) as the implementation would provide a > method for converting to the format pg is expecting. That sounds great. I assume the PGDataType subclasses would be used like factories. When carefully crafted, this could even allow the PGDataType factory to directly instantiate classes like org.postgis.Point or JTS geometry classes to be returned by getObject(), without need to subclassing PGObject. This would allow to unify custom and built-in data types, including ability to override built-ins. <shameless rant - consume with a grain of salt> One of the most annoying aspects of the current PGObject approach is that the current architecture instantiates the custom data types and then passes the data to them via setValue. The jdbc driver only knows its a geometry object, but not the appropriate subclass (Point, Polygon etc.) which is encoded in the data itsself. So currently, PGGeometry and other PGObject subclasses are factories that create and remember the appropriate geometry subclass in setValue. Then the user calls getObject() to get the PGGeometry wrapper, and then the getGeometry() method to get the actual geometry class. Another drawback is lacking support for binary transfer, the getValue() and setValue() only work with slow and inefficient String representations. This even lead to the development of wkb4j that uses a hex encoded binary representation to speed-up reading, see http://wkb4j.sourceforge.net/ </rant> This would need a "backwards-mapping" from setObject classes to the PGDataType factory for writing data. This could be accomplished by combining a Map where the PGDataTypes register the classes they know to handle, and a probing scheme with auto-caching for the case someone puts subclasses into setObject. Your concept would render my "Register arbitrary types framework" demand obsolete (which I posted here on March 10, and then abandoned temporarily). BTW, this would even allow someone to transparently emulate other manufacturers drivers by writing e. G. a PGDataType implementation that handles oracle spatial GIS objects. This could ease the transition to PostgreSQL (provided the user has the appropriate license for the oracle java classes that would still be needed). So, I'd give a +10 on this suggestion. Or am I completely misleaded? 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 по дате отправления: