JDBC: Blob . setBytes: Unsupported Feature(s)!

["McFarlane, Keith GSNL-GSXE" <ke...@shell.com>]

 Dear Derby-Users,


  CAN ANYONE ADVISE WHEN / WHETHER THE JDBC Blob-INTERFACE METHOD:

	int setBytes(long pos, byte[] bytes, int offset, int len) 
	 throws SQLException


  METHOD, AND ITS SISTER METHODS

	OutputStream setBinaryStream ( long pos)
	 throws SQLException;

	int setBytes(long pos, byte[] bytes)
	 throws SQLException;


 WILL BE IMPLEMENTED IN APACHE DERBY? Currently these methods do nothing more than throw an SQLException with the message: "Feature not implemented: no details". THESE METHODS ARE REQUIRED FOR THE STANDARD JAVA EDITION VERSIONS 4 and 5!!


 Best Wishes
 Keith McFarlane.


 Keith McFarlane, GSXE,
 e-Commerce & e-Service-Delivery Group,
 Shell Global Solutions International BV
 P.O. Box 38000, 1030 BN Amsterdam, 
 The Netherlands / NL.

Tel / Office: +31 (0) 20 630 2457 2497
Email: Keith.McFarlane@shell.com

______________________________________________________________________________________________________________


 PS: THE PROBLEM CONTEXT IS (ROUGHLY) AS FOLLOWS: I would really like these methods to "hide" a free-text indexing solution in an encrypted Derby database stored on a portal-client (external third-party) PC. The chosen search-indexing tools is (of course) Apache Lucene). I came across the following exception stack when attempting "random access" to a Derby BLOB (binary large object) using the standard JDBC method: setBytes ( );

 Exception in thread "main" java.io.IOException: flushBuffer () Exception: IndexOutput: Feature not implemented: no details.
        at DerbyIndexOutput.flushBuffer(DerbyIndexOutput.java:79)
        at org.apache.lucene.store.BufferedIndexOutput.flush(BufferedIndexOutpu.java:84)
        at org.apache.lucene.store.BufferedIndexOutput.close(BufferedIndexOutpu.java:98)
        at DerbyIndexOutput.close(DerbyIndexOutput.java:88)
        at org.apache.lucene.index.SegmentInfos.write(SegmentInfos.java:91)
        at org.apache.lucene.index.IndexWriter$1.doBody(IndexWriter.java:263)
        at org.apache.lucene.store.Lock$With.run(Lock.java:109)
        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:260)
        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:245)
        at DerbyTextIndexApp.<init>(DerbyTextIndexApp.java:36)
        at DerbyTextIndexApp.main(DerbyTextIndexApp.java:216)

 The code of the flushBuffer method is as follows 

   public void flushBuffer ( byte [ ] b, int len )
   throws IOException

   { final String sql = "SELECT CONTENT FROM OFFLINE_REPOSITORY"
      + " . TEXT_INDEXES WHERE URL = ? FOR UPDATE";
 
     PreparedStatement prepared; ResultSet results; Blob blob
      = null;
     
     final long position = 1 + super . getFilePointer ( ); 

     try // THE REQUIRED setBytes METHOD NOT IMPLEMEMTED BY DERBY, 
         // calling it simply throws an SQLException!

      { prepared = connection . prepareStatement ( sql );
        prepared . setString ( 1, url ); 
        results = prepared . executeQuery ( );

        while ( results . next ( ) ) blob
         = results . getBlob ( 1 );

        blob . setBytes ( position, b, 0, len );
        
        results . close ( ); prepared . close ( ); 
        connection . commit ( );
      }

     catch ( SQLException exception )

      { String message = "flushBuffer () Exception:"
         + " IndexOutput: " + exception . getMessage 
         ( ); throw new IOException ( message );
      }
   } 


 This code is part of a DerbyIndexOutput class that extends the Lucene (abstract) IndexOutput class, itself used by the Lucence Directory class for storing (persisting) a Lucene index. I already have a URLConnection that can access Derby Blobs as Files, and have tested a DerbyIndexInput implementation using the JDBC Blob . getBytes (...) method (properly i.e. functionally implemented in Apache Derby. The missing methods are needed for a complete JDBC-compliant database. This is an urgent project for us (though there are obvious work-arounds). A quick reply would, therefore, be much appreciated!


 Best Wishes,
 Keith McFarlane

_____________________________________________________________________________________________________________