From: schabi at logix-tt.com (Markus Schaber)
Date: Sun, 01 Oct 2006 14:38:37 +0200
Subject: [Pljava-dev] VarLenTuple example code
In-Reply-To: <451FAC50.9060100@tada.se>
References: <451BD0B1.8000408@logix-tt.com>	<451BD2F4.60202@tada.se>
	<451BD650.2080201@logix-tt.com>	<451BDB5E.1020107@tada.se>
	<451BE12B.6060809@logix-tt.com>	<451BF32A.7000405@tada.se>
	<451CF211.7000000@logix-tt.com>	<451CFAAD.9030603@tada.se>
	<451D0B0B.4010008@logix-tt.com>	<451D10E0.8020003@tada.se>
	<451D2198.7050202@logix-tt.com>	<451D2849.8030109@tada.se>
	<451D3702.5070802@logix-tt.com> <451FAC50.9060100@tada.se>
Message-ID: <451FB6CD.7070808@logix-tt.com>

Hi, Thomas,

Thomas Hallgren wrote:

> I.e. a fullblown type implementation would then have 6 methods (4
> static) and look like this:
> 
> // The new static interface
> //
> public static void input(String input, SQLData output) throws
> SQLException { ... }
> public static String output(SQLData input) throws SQLException { ... }

Using a String in input/output looks like a good compromise between
usability and speed.

I'd prefer to have a CharSequence in both places (especially as we could
use a StringBuilder in output then), but as they're @since 1.5, String
seems the better choice.

> public static void receive(SQLData input, SQLData output) throws
> SQLException { ... }
> public static void send(SQLData input, SQLData output) throws
> SQLException { ... }

Did you mean SQLInput/SQLOutput instead of SQLData here?

> // The SQLData interface
> //
> public void readSQL(SQLData input, String typename) throws SQLException
> { ... }
> public void writeSQL(SQLData output) throws SQLException { ... }

SQLInput/SQLOutput here, too, I guess. :-)

And a simple mapping for an existing Datatype still needs to implement
only those two, excellent.

> What do you think?

I think it's a good idea. Someone who wants to have the object
representation in input/output and/or send/receive can still use the
readSQL/writeSQL methods of an instance he created itsself. I'll recode
my VarLenTuple example to work this way, and explain the alternatives
using comments.

There's one little problem I currently see: We'll need 2 implementations
of SQLInput and SQLOutput. One for machine endianness (to parse C), and
one for network byte order (to parse D).

Or maybe we have both a Big and Little endian implementation, and the
UDT[] syntax contains a hint on which byte order to use (Big=Network,
Little, Native=whatever the machine has), with the defaults of Network
for B and Native for C.

Having two fixed-endian implementations will even be more efficient
compared to the current one that has an if() in every method, in case
the Jit does not grasp it.

Btw, do you have any idea if and how other databases implement the UDT
mapping for java?

Thanks,
Markus