[Pljava-dev] readBytes() / writeBytes()

From: schabi at logix-tt(dot)com (Markus Schaber)
To:
Subject: [Pljava-dev] readBytes() / writeBytes()
Date: 2006-09-22 15:11:29
Message-ID: 4513FD21.5080608@logix-tt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

Hi, Thomas,

Thomas Hallgren wrote:

> Markus Schaber wrote:
>> What's the best way to fix it? Using native functions for reading the
>> values?
>
> It's two fixes basically. The endian stuff can be fixed in Java and
> directly in the SQLOutputToChunk and SQLInputFromChunk classes. The
> methods should mimic what java.nio.DirectByteBuffer does.
> java.nio.ByteOrder.nativeOrder() gives the native ordering.

Ah, great. I'll look into it.

> The four byte offset stuff must be fixed in the C file that corresponds
> to the SQLInputFromChunk. There's no need to fix for the output since
> such a fix will introduce an ambiguity. The length is determined by the
> number of bytes written anyway, so why introduce a need to go back and
> add it. Important to document this behavior though.

Its assymetric when we read the length on input, but don't write it on
output, I would hesitate to use this assymetry.

Maybe the code should check whether the length header is equal to the
real length, and raise a warning otherwise?

Additionally, the underlying code could intercept an writeInt() at
offset 0, and allocate the underyling StringInfo to the right size. This
avoids repeated reallocation on larger values. (Geometries representing
country borders can easily get several MB large.) But, on the other
hand, this would slow down all writeInt() calls, so I don't know whether
it's worth the effort.

> I'm not too concerned with backward compatibility on this. The current
> behavior is severely broken. It must be fixed.

Ok, I fully agree.

Thanks,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20060922/d4f608de/attachment.bin>

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message Thomas Hallgren 2006-09-22 15:25:18 [Pljava-dev] readBytes() / writeBytes()
Previous Message Thomas Hallgren 2006-09-22 14:42:01 [Pljava-dev] readBytes() / writeBytes()