db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "McFarlane, Keith GSNL-GSXE" <keith.mcfarl...@shell.com>
Subject JDBC: Blob . setBytes: Unsupported Feature(s)!
Date Mon, 24 Apr 2006 14:13:34 GMT

 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

_____________________________________________________________________________________________________________










 


Mime
View raw message