Re: datatype conversion thoughts

Hi, Oliver,

On Tue, 12 Oct 2004 10:30:23 +1300
Oliver Jowett <oliver(at)opencloud(dot)com> wrote:

> To avoid threading/object creation issues you might want to look at a
> strategy/flyweight implementation where the per-type codec objects are
> stateless and are passed all the context they need, i.e:
>
> interface ParameterCodec {
> String getTextFormat(Object parameter);
> byte[] getBinaryFormat(Object parameter);
> void streamAsBinary(Object parameter, PGstream toStream);
> // etc.
> }

Sounds like a good idea, lightweight and stateless factories. Those instances

By using an abstract superclass instead of an interface, we could gain
default implementations (that use .toString() for getTextFormat or throw
an exception for unsupported operations), and thus avoid code
duplication.

But on the other hand, an interface would be more flexible, and we could
still provide an implementing class containing such default code that
users could (but don't have to) use.

> For the ResultSet side and binary data, I was looking at reading the
> entire DataRow message into a single array and passing array offsets to
> the codecs. That should help reduce the amount of garbage generation:
> we'd have one bytearray per row, not one per row per column.

Good idea. Less object instantiations and less garbage is always
positive.

> For results where we do not yet have a binary-format parser, I realized
> we can convert them to text on demand fairly easily: issue a "SELECT ?"
> passing the uninterpretable binary data as the parameter value (with
> correct type OID), and ask for results in text format.

This sounds genious. If we don't know how to deal, ask the server as it
is guaranteed to have the knowledge.

> This should
> hopefully mean we can do binary format results by default without having
> to do an extra roundtrip to Describe the statement before every
> execution (to work out which result columns to make binary); you only
> pay the roundtrip cost when the user asks for a non-binary value, which
> should hopefully be rare (e.g. external PGobject implementations that
> haven't been updated for the changes).

I think this is a cost we can pay, all PGObject implementations I know
are open source and so the new system can be adopted rather quick.

> I've done some more detailed design, mostly in my head at the moment; if
> you want I can send you more details.

Please feel invited! :-)

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