RE: [xml-dbms] Proprietary property formatting
> I think you're right, but am not sure. What I'm worried about is whetherIsn't that up to the JDBC driver? Whether it actually works depends on the
> drivers/databases are willing to support the arbitrarily large buffers
> required by byte.
database, the database-protocol and the amount of RAM in your machine.
Anyway, going for streams will be a big plus for large data objects, but a
nuisance for small objects. Probably that is why the JDBC ResultSet
interface has both forms.
> 1) What is the difference between CLOB/BLOB andLONGVARCHAR can be mapped to String, LONGVARBINARY to byte. But again,
both can be read/set with a stream implementation
(get/updateCharacterStream() and get/updateBinaryStream()).
String/characterStreams use 16-bit units, byte and binaryStream use 8-bit
CLOBs and BLOBs can be handled without actually transferring the contents to
the client. I did not yet see how to write to a CLOB/BLOB. I suspect you can
simply use either updateCharacterStream() and updateBinaryStream() or
updateString() and updateBytes(), all in the ResultSet interface.
From a Java point of view there is no difference between CHAR, VARCHAR and
LONGVARCHAR, nor between
the types BINARY, VARBINARY and LONGVARBINARY.
My company has no plans to use ARRAY, STRUCT, REF nor JAVA_OBJECT. We might
someday use CLOB or BLOB but probably not in combination with XML.
- Erik van Oosten wrote:
>It is up to the driver. I was curious if one form was more common than
> > I think you're right, but am not sure. What I'm worried about is whether
> > drivers/databases are willing to support the arbitrarily large buffers
> > required by byte.
> Isn't that up to the JDBC driver? Whether it actually works depends on the
> database, the database-protocol and the amount of RAM in your machine.
> Anyway, going for streams will be a big plus for large data objects, but a
> nuisance for small objects. Probably that is why the JDBC ResultSet
> interface has both forms.
the other. I'll change the interface to use byte on the grounds that
it might be more efficient. If the underlying driver uses an
InputSource, the formatting class can convert between byte and
- One other question about custom formatting classes.
The current proposal states that these should have a zero-argument
constructor and that any parameters should be static variables in the
class. An alternative is to let applications instantiate the formatting
objects and pass them to XML-DBMS.
a) Allows more generic classes to be written. For example, an
application could pass a general pattern to a formatting class.
a) Makes application code more complex.
b) Slower processing time due to looking up the formatting class in a