Loading ...
Sorry, an error occurred while loading the content.

RE: [xml-dbms] Proprietary property formatting

Expand Messages
  • Erik van Oosten
    ... 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,
    Message 1 of 3 , Sep 27, 2001
    • 0 Attachment
      > 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.

      > 1) What is the difference between CLOB/BLOB and
      > LONGVARCHAR/LONGVARBINARY?

      LONGVARCHAR 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
      units.

      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.

      Cheers,
      Erik.
    • Ronald Bourret
      ... It is up to the driver. I was curious if one form was more common than the other. I ll change the interface to use byte[] on the grounds that it might be
      Message 2 of 3 , Sep 28, 2001
      • 0 Attachment
        Erik van Oosten wrote:
        >
        > > 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.

        It is up to the driver. I was curious if one form was more common than
        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
        InputSource.

        -- Ron
      • Ronald Bourret
        One other question about custom formatting classes. The current proposal states that these should have a zero-argument constructor and that any parameters
        Message 3 of 3 , Oct 2, 2001
        • 0 Attachment
          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.

          Pros:
          -----
          a) Allows more generic classes to be written. For example, an
          application could pass a general pattern to a formatting class.

          Cons:
          -----
          a) Makes application code more complex.
          b) Slower processing time due to looking up the formatting class in a
          hashtable.

          Opinions?

          -- Ron
        Your message has been successfully submitted and would be delivered to recipients shortly.