|Subject||Re: getObject and blob|
> Maybe the solution would be the subtype. As I read here:I'm not sure about subtype 2, I never met it before. According to
> http://www.mers.com/INPRISE/FAQ/2842.HTML Maybe BLOBs with subtype 2
> should be treated as BLOB and subtype 0 and subtype1 should be
> treated as BINARY. This means when a Blob is subtype 2 it should
> not accept getBytes, setBytes, getString, setString and it should
> return a Blob with
Firebird docs, subtype < 0 is a user-defined type of blob, >= 0 -
reserved by a system (0 - binary data, 1 - text data).
> This is bit offtopic, but: when Sun introduced Blobs and Clobs inThe main reason, why I would like to have Blob (sometimes) is that
> JDBC 2.1 they provided no way to update or a set a blob. There was
> only getBinaryStream. The only way to change data in a Blob was
> vendor-specific, you can not create a "Blob" object. Although JDBC
> 3.0 introduced new features for updating Blobs, I believe it
> suffers from the same problem. Although the new API (with
> setBinaryStream and setBytes)is much more useable when using
> updatable resultsets.
when the content is really big, and I am not interested in the whole
chunk, but only in a small part, I still have the possibility (in
theory, not implemented yet) to fetch only necessary part of it.
Firebird API provides such functionality by allowing to fetch only
specific BLOB segment.
When using getBytes() or getBinaryStream(), you do not have such
> In my eyes this is the historic reason for which other JDBC driversYes, if you are working with the content as an atomic chunk of data.
> does handle even the BLOB fields in the database as binary fields,
> because this it is much convinient to create a byte or String
> object rather than to create a FBBlobField, a PGSqlBlob or a Blob
> (in MySQL driver).
No, if you go forth and backward looking for something. Then Blob is
> One more little thought about the blob concept in JDBC:Well... this is the case of Firebird as well. BLOB content is stored
> JDBC API says about Blob:
> Actually I can't tell that I really understand why Sun created the
> Blob interface, but I suppose it is a helper for those databases
> that can operate on a BLOB field on the server with a LOCATOR
> object (like DB/2)
separately in the database, while the id of the BLOB is stored within
the row. You have to use different API to access the BLOB fields than
other fields. Same applies to ARRAY type.
But I agree that BINARY (or LONGVARBINARY) must be supported. My
suggestion is the following:
- if the subtype is 0 or 1 - this is LONGVARBINARY type;
- if the subtype is < 0 - this is a BLOB type.