[postgis-users] JDBC-Postgis bug

[David Garnier]

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>