[SOLVED] Re: [postgis-users] JDBC-Postgis bug

[David Garnier]

Hello,
I finally add a look at Postgis's source and I found a bug in
postgis_inout.c. On my box, when I ask for the XDR format (Big Endian),
the returned data in always in NDR (Little Endian). In Postgis 0.7.2, it
happened from time to time while it is permanent in Postgis 0.7.5.

For the record, I'm using a Athlon with SuSE 8.0 and I try to fetch data
from Java through binary cursors.

In postgis_inout.c, the switch between XDR and NDR is done by this
statement: 
 if  ( ( strcmp(VARDATA(type) ,"xdr") == 0 ) || (strcmp(VARDATA(type)
,"XDR") == 0) )

The problem is that when XDR is requested, VARDATA(type) contains the
XDR string and then some garbage (like: . The next statement gets it
right:

if  ( ( strncmp(VARDATA(type) ,"xdr", 3) == 0 ) ||
(strncmp(VARDATA(type) ,"XDR",3) == 0) )

Maybe there is something wrong elsewhere that actually corrupt VARDATA,
but the fix works for me.


Best Regards,
David Garnier


Le mer 18/06/2003 à 23:13, David Garnier a écrit :
> Hello,
> 
> I'm still working on my WKB4J project and I've been hitting this bug for
> some months. I perform a request to Postgis through JDBC, using a binary
> cursor : 
> 
>             Statement wkbSta = dbConn.createStatement();            
> 
>             wkbSta.execute("begin");
>             wkbSta.execute(
>                 "declare wkb_cursor binary cursor for " +
> completeSQLQuery);
>             ResultSet wkbRecords =
>                 wkbSta.executeQuery("fetch forward all in wkb_cursor");
> 
>             byte[][] fields = new byte[words.length][];
> 
>             while (wkbRecords.next()) {
>                 for (int i = 0; i < words.length; i++) {
>                     fields[i] = wkbRecords.getBytes(words[i]);
>                 }
>                 try {
> -->                  byte[] record = wkbRecords.getBytes("wkb");
>                 } catch (Exception e) {
>                     e.printStackTrace();
>                     log.error(e);
>                 }
>             }
> 
>             wkbSta.execute("close wkb_cursor");
>             wkbSta.execute("end");
>             wkbRecords.close();
>             wkbSta.close();
> 
> 
> Here is the problem: when I execute this code with the same Connection
> object, the endian of the result changes after a while. I haven't
> quantified the effect exactly but it seems to happen on the third or
> fourth query. For example, for the same record, with a new Connection I
> would always get the correct result : 
> [1, 6, 0, 0, 0, 1, 0, 0, 0, 1, 3, 0, 0, 0, 8, 0, 0, 0, 116, 3, 0, 0, 31,
> -53, 118, 82, -58, 92, 99, -64, 82, -18, -62, -81, 92, 51, 3, -64,
> 
> While with a "used" Connecction, I would get:
> [0, 0, 0, 0, 6, 0, 0, 0, 1, 0, 0, 0, 0, 3, 0, 0, 0, 8, 0, 0, 3, 116,
> -64, 99, 92, -58, 82, 118, -53, 31, -64, 3, 51, 92, -81, -62, -18, 82,
> 
> According to the OGC documentation, the first byte indicates the byte
> order (big endian or little endian) and the second array is really the
> little-endian version of the big-endian (this is actually a mix of
> bytes, ints and longs so it is not obvious). In my query, I always
> specify XDR (big endian). 
> 
> This problems is a hard one for me because it would really degrade the
> performance of the library if I had to reparse the whole array.
> 
> So, any idea about this problem?
> 
> Best Regards,
-- 
David Garnier <david.garnier at etudier-online.com>