[fdo-dev] Byte order of non-geometry bind/define buffers

[Gavin Cramer]

Hi, Mateusz.  I saw this, and your elaboration off-line about the "char
* address".

All of the RDBMS API's that we have dealt with (OCI, ODBC, etc)
automatically convert to the local byte order.  If PostgreSQL doesn't do
this, your RDBI driver will have to apply endian conversion to the data
at execute/fetch time as needed.  You can experiment with doing this
directly on the data buffers to get it going, but it would need
reconsideration later to see if a separate conversion buffer is needed
for each binary column (to avoid scrambling the caller's data).  Either
way, this is probably faster than doing conversion to text.

Regarding the "char * address" parameter, yes, it is just a pointer to
the start of the bound data, be it text or binary.  It pre-dates ANSI C,
otherwise it would have been a "void *".  The value is simply cast to
"char *" from all types.  If there is an array of data, the parameter
value is still just the address of the first byte of that array.

For basic data types (char arrays, ints, doubles -- not objects, e.g.
geometries), there is NO notion of "array of pointers", etc.  If there
is an array to handle multiple rows at once, the data is just a plain
array of int, for example.

Abbreviated example code:

#define NUM_ROWS	(10)
int myInts[NUM_ROWS];
int ret = RDBI_SUCCESS;
rdbi_context_def *myRdbi = ...;
char * myNullIndicators = NULL;

ret = rdbi_alcnullind(NUM_ROWS, &myNullIndicators);
rdbi_set_nnull(myRdbi, myNullIndicators, 0, NUM_ROWS-1);
ret = rdbi_bind(myRdbi, mySqlid, "myColumnName", RDBI_INT,
sizeof(myInt[0]), (char *)myInts, myNullIndicators);
...

Note that NUM_ROWS is not used in the rdbi_bind call.  The number of
rows is not actually important until rdbi_execute (for inserts/updates)
or rdbi_fetch (for selects).

I recommend searching the "Gdbi" package (or just the entire
GenericRdbms solution) for actual working examples.  Gdbi is the main
consumer of Rdbi.

Best wishes,
Gavin


-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Monday, September 04, 2006 1:58 PM
To: dev at fdo.osgeo.org
Subject: [fdo-dev] Byte order of non-geometry bind/define buffers

Hi,

I can't find where FDO applies bytes order conversion between
client/server to non-geometry bind and define buffers.

I searched through Rdbi drivers/Gdbi and higher abstractions,
but I can't find it. Get* members of GdbiQueryResult class
use memcpy() function to retrieve data from column buffers.
That's all I see, am I correct?

For example, when I pass pointer to int buffer to bind,
how MySQL/Rdbi/FDO deals with endianness?

Thanks in advance for exaplanation.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at fdo.osgeo.org
For additional commands, e-mail: dev-help at fdo.osgeo.org