agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] readBytes() / writeBytes()
13+ messages / 0 participants
[nested] [flat]
* [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-21 20:28
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-21 20:28 UTC (permalink / raw)
Hi,
I just stumbled about the readBytes() / writeBytes() methods from
SQLInputFromChunk / SQLOutputFromChunk classes.
They seem to assume that every array has a 2-byte length header.
Where does this assumption come from? Are there some internal data types
that use this format?
I ask because I'm currently writing a pljava interface for the PostGIS
datatypes, and my hope was that readBytes() just reads the whole
(variable-length) datatype into the byte array.
Another issue is the endianness. For double, I assume that, at least on
IEEE floating point platforms, the layout is endian free. But readInt()
etc. seem to use big endian regardless of the underlying platform.
So it seems that I have to use readByte() and put everything together in
the right order on myself, right?
Btw, is does the stream include the 4-byte length header for variable
length datatypes? The examples seem to cover only fixed-size types.
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/20060921/fb5f2f43/attachment.bin;
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 08:17 `
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 08:17 UTC (permalink / raw)
Markus Schaber wrote:
> Hi,
>
> I just stumbled about the readBytes() / writeBytes() methods from
> SQLInputFromChunk / SQLOutputFromChunk classes.
>
> They seem to assume that every array has a 2-byte length header.
>
Those classes are part of the JNI interface. They map to the internal PostgreSQL StringInfo
structure. They are *not* intended for any other use.
Kind Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 08:38 `
2006-09-22 08:48 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 2 replies; 13+ messages in thread
From: @ 2006-09-22 08:38 UTC (permalink / raw)
Hi, Thomas,
Thomas Hallgren wrote:
>> I just stumbled about the readBytes() / writeBytes() methods from
>> SQLInputFromChunk / SQLOutputFromChunk classes.
>>
>> They seem to assume that every array has a 2-byte length header.
>>
> Those classes are part of the JNI interface. They map to the internal
> PostgreSQL StringInfo structure. They are *not* intended for any other use.
Ok, it seems I've been mislead by reading the docs and source, sorry.
Please tell me, what's their use, if not implementing datatype mappings?
As far as I can see, they're the only implementations of the
SQLInput/ SQLOutput interfaces one uses to implement a custom data type.
So, when mapping a datatype (like the ComplexTuple example delivered
with pljava), one is actually using those classes.
And as the storage format of the PostGIS datatypes is determined by the
C implementation in liblwgeom.so, I have to adhere to that format.
I have to understand how SQLInputFromChunk and SQLOutputFromChunk
work, to find the most efficient implementation while still being
compatible to that predefined binary format.
As it looks now, my only possibility seems to find out the native
endianness of the machine, and then read the data byte-for-byte via
readByte(), and then put it together for myself. Most of the code should
be copyable from the WKB parsers I've already written, so no real
effort, but I'm still afraid that calling a native function per byte
will not perform best.
Thanks for your patience,
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/38121583/attachment.bin;
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 08:48 `
2006-09-22 08:54 ` [Pljava-dev] readBytes() / writeBytes()
1 sibling, 1 reply; 13+ messages in thread
From: @ 2006-09-22 08:48 UTC (permalink / raw)
Hi, Thomas,
Markus Schaber wrote:
> So, when mapping a datatype (like the ComplexTuple example delivered
> with pljava), one is actually using those classes.
Sorry, I meant the ComplexScalar interface, as the PostGIS geometries
are no composite types from PostgreS' view.
Sadly, there are no examples for custom datatypes with variable size, so
I've to extrapolate from the given fixed-length examples, and the
details I know about the C implementation of variable-sized datatypes.
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/dd764584/attachment.bin;
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:48 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 08:54 `
0 siblings, 0 replies; 13+ messages in thread
From: @ 2006-09-22 08:54 UTC (permalink / raw)
Markus Schaber wrote:
> Sadly, there are no examples for custom datatypes with variable size, so
> I've to extrapolate from the given fixed-length examples, and the
> details I know about the C implementation of variable-sized datatypes.
>
AFAIK, they all start with a 4 byte header denoting the length. So your mapping starts by
doing a readInt() and then you base the rest on that.
Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 08:50 `
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
1 sibling, 1 reply; 13+ messages in thread
From: @ 2006-09-22 08:50 UTC (permalink / raw)
Markus Schaber wrote:
> Hi, Thomas,
>
> Thomas Hallgren wrote:
>
>
>>> I just stumbled about the readBytes() / writeBytes() methods from
>>> SQLInputFromChunk / SQLOutputFromChunk classes.
>>>
>>> They seem to assume that every array has a 2-byte length header.
>>>
>>>
>> Those classes are part of the JNI interface. They map to the internal
>> PostgreSQL StringInfo structure. They are *not* intended for any other use.
>>
>
> Ok, it seems I've been mislead by reading the docs and source, sorry.
> Please tell me, what's their use, if not implementing datatype mappings?
>
>
Their use *is* to implement datatype mappings. PostgreSQL's receive/send
functions use the StringInfo to pass datastructures.
> As far as I can see, they're the only implementations of the
> SQLInput/ SQLOutput interfaces one uses to implement a custom data type.
>
>
You use SQLInput/SQLOutput to map all datatypes but the pre-mapped ones
(i.e. int, long, float, etc.) with PL/Java.
> So, when mapping a datatype (like the ComplexTuple example delivered
> with pljava), one is actually using those classes.
>
>
Correct. But there's more to it. Please read:
http://wiki.tada.se/wiki/display/pljava/Mapping+an+SQL+type+to+a+Java+class.
There's an example mapping the PostgreSQL geometric point type to a Java
class.
> And as the storage format of the PostGIS datatypes is determined by the
> C implementation in liblwgeom.so, I have to adhere to that format.
>
>
Yes you do. But that should not be a problem.
> I have to understand how SQLInputFromChunk and SQLOutputFromChunk
> work, to find the most efficient implementation while still being
> compatible to that predefined binary format.
>
> As it looks now, my only possibility seems to find out the native
> endianness of the machine, and then read the data byte-for-byte via
> readByte(), and then put it together for myself. Most of the code should
> be copyable from the WKB parsers I've already written, so no real
> effort, but I'm still afraid that calling a native function per byte
> will not perform best.
>
>
You should not bother with endianess. The implementation deals with that.
Kind Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 13:18 `
2006-09-22 13:29 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 13:18 UTC (permalink / raw)
Hi, Thomas,
Thomas Hallgren wrote:
> AFAIK, they all start with a 4 byte header denoting the length. So
> your mapping starts by doing a readInt() and then you base the rest
> on that.
From my tests, that 4 byte header is cut of, the SQLInput starts at the
first "real" data byte.
>> As it looks now, my only possibility seems to find out the native
>> endianness of the machine, and then read the data byte-for-byte via
>> readByte(), and then put it together for myself. Most of the code
>> should be copyable from the WKB parsers I've already written, so no
>> real effort, but I'm still afraid that calling a native function
>> per byte will not perform best.
>>
> You should not bother with endianess. The implementation deals with
> that.
At leas on my machine (i386 architecture), the doubles I read in get
scrambled when using readDouble(). However, when I swap the bytes, I get
the correct results. From looking at the code, readDouble() & co seem to
assume network byte order, instead of using the native endianness of the
machine. But for reading PostGIS geometry data, I've to parse the native
format, as that is what the C code uses.
So I will resort to read byte-for-byte.
Thanks for your patience,
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/dbb2cdf8/attachment.bin;
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 13:29 `
2006-09-22 14:22 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 13:29 UTC (permalink / raw)
Hi Markus,
I should have checked before I spoke. I see now that the implementation
is incorrect. The intended functionality should of course be that the 4
byte integer is intact when present and that all endianness is taken
care of. This is a bug of course and I'll fix that eventually. Sorry for
the confusion.
Regards,
Thomas Hallgren
Markus Schaber wrote:
> Hi, Thomas,
>
> Thomas Hallgren wrote:
>
>
>> AFAIK, they all start with a 4 byte header denoting the length. So
>> your mapping starts by doing a readInt() and then you base the rest
>> on that.
>>
>
> From my tests, that 4 byte header is cut of, the SQLInput starts at the
> first "real" data byte.
>
>
>>> As it looks now, my only possibility seems to find out the native
>>> endianness of the machine, and then read the data byte-for-byte via
>>> readByte(), and then put it together for myself. Most of the code
>>> should be copyable from the WKB parsers I've already written, so no
>>> real effort, but I'm still afraid that calling a native function
>>> per byte will not perform best.
>>>
>>>
>> You should not bother with endianess. The implementation deals with
>> that.
>>
>
> At leas on my machine (i386 architecture), the doubles I read in get
> scrambled when using readDouble(). However, when I swap the bytes, I get
> the correct results. From looking at the code, readDouble() & co seem to
> assume network byte order, instead of using the native endianness of the
> machine. But for reading PostGIS geometry data, I've to parse the native
> format, as that is what the C code uses.
>
> So I will resort to read byte-for-byte.
>
> Thanks for your patience,
> Markus
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/pljava-dev
>
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:29 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 14:22 `
2006-09-22 14:42 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 14:22 UTC (permalink / raw)
Hi, Thomas,
Thomas Hallgren wrote:
> I should have checked before I spoke. I see now that the implementation
> is incorrect. The intended functionality should of course be that the 4
> byte integer is intact when present and that all endianness is taken
> care of. This is a bug of course and I'll fix that eventually. Sorry for
> the confusion.
No problem.
Fixing that now will break all datatypes that already use the interface
(forcing a dump/reload of the database when they upgrade).
At least, if there are any. :-)
What's the best way to fix it? Using native functions for reading the
values?
I can try to contribute when you like.
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/f734af3c/attachment.bin;
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:29 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:22 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 14:42 `
2006-09-22 15:11 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 14:42 UTC (permalink / raw)
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.
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.
I'm not too concerned with backward compatibility on this. The current
behavior is severely broken. It must be fixed.
> I can try to contribute when you like.
>
>
Yes, please do! Give it a try and submit a patch. My time is very
limited these days.
Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:29 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:22 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:42 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 15:11 `
2006-09-22 15:25 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 15:11 UTC (permalink / raw)
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;
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:29 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:22 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:42 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 15:11 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 15:25 `
2006-09-22 16:10 ` [Pljava-dev] readBytes() / writeBytes()
0 siblings, 1 reply; 13+ messages in thread
From: @ 2006-09-22 15:25 UTC (permalink / raw)
Markus Schaber wrote:
> 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?
>
>
The problem is that you often don't know the length when you start
writing. And there's no way to do a seek and go back and rewrite once
you're done. But as you mention, asymmetry is not good and far from
everyone will consult the documentation.
A good compromise is perhaps to to introduce the check that you suggest
but also allow the length to be zero? That way you will always need to
write the length and if it's not known at that time, you just write zero
and PL/Java will assign it once you're done writing.
> 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.
>
>
In most cases (for small datatypes) you'll only loose with that
approach. If it's very common that you write long sequences of data, it
will be a win (reallocation is not cheap). I'd leave it for now and
perhaps make it configurable sometime in the future.
Regards,
Thomas Hallgren
^ permalink raw reply [nested|flat] 13+ messages in thread
* [Pljava-dev] readBytes() / writeBytes()
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:38 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:50 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:18 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 13:29 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:22 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 14:42 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 15:11 ` [Pljava-dev] readBytes() / writeBytes()
2006-09-22 15:25 ` [Pljava-dev] readBytes() / writeBytes()
@ 2006-09-22 16:10 `
0 siblings, 0 replies; 13+ messages in thread
From: @ 2006-09-22 16:10 UTC (permalink / raw)
Hi, Thomas,
Thomas Hallgren wrote:
> A good compromise is perhaps to to introduce the check that you suggest
> but also allow the length to be zero? That way you will always need to
> write the length and if it's not known at that time, you just write zero
> and PL/Java will assign it once you're done writing.
Yes, that sounds good. In that case, we should make the check mandatory,
and throw an exception when an explicit size is mismatching.
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/e183515e/attachment.bin;
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2006-09-22 16:10 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-09-21 20:28 [Pljava-dev] readBytes() / writeBytes()
2006-09-22 08:17 `
2006-09-22 08:38 `
2006-09-22 08:48 `
2006-09-22 08:54 `
2006-09-22 08:50 `
2006-09-22 13:18 `
2006-09-22 13:29 `
2006-09-22 14:22 `
2006-09-22 14:42 `
2006-09-22 15:11 `
2006-09-22 15:25 `
2006-09-22 16:10 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox