Re: PGobject overhaul (was Re: tightening up on use of oid
От | Markus Schaber |
---|---|
Тема | Re: PGobject overhaul (was Re: tightening up on use of oid |
Дата | |
Msg-id | 20041029185758.0ae72196@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответ на | PGobject overhaul (was Re: tightening up on use of oid 0) (Oliver Jowett <oliver@opencloud.com>) |
Список | pgsql-jdbc |
Hi, Oliver, On Thu, 28 Oct 2004 15:18:13 +1300 Oliver Jowett <oliver@opencloud.com> wrote: > - Implementations of PGobject should provide a ctor taking a single > String; this is called by the driver to construct non-null objects. Is it possible to use a static factory function instead? This would make it possible to produce different subclasses depending on the String, which would be useful e. G. for PostGIS, als all the geometry classes share the same postgres type "geometry". > When we come to do binary-format types, I'd expect we would have a > subinterface (PGbinaryobject?) that adds whatever methods are needed for > binary parameter formatting. Objects that implement PGbinaryobject > become candidates for binary transfer. What do you think about the factory / handler object approach that AFAIR was discussed here some days ago? So the driver gets registered one PGfactory for every postgres type, and this factory then has methods to transform objects to text and binary representation and vice-versa. This would allow us to read and write instances of third-party defined classes that don't implement any postgres specific interface. We still could have a default factory implementation that gets used whenever any legacy application uses PGObject subclasses. 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 по дате отправления: