Re: CLOB issue with Oracle

From: Cris Daniluk (cris.danilu..mail.com)
Date: Thu Dec 22 2005 - 09:16:56 EST

  • Next message: Cris Daniluk: "Re: heap memory not released"

    Actually, I believe that LONGVARCHAR is actually a map to the LONG
    type within Oracle, and its equally deprecated.

    I don't know why a LOB type change would have anything to do with it,
    seems more likely to be the class regeneration to me. Stranger things
    have happened though :)

    Cris

    On 12/22/05, Howard Treisman <htreisma..voka.com> wrote:
    >
    > Update...
    > We resolved this issue by using a BLOB rather than a CLOB.
    > Work like a charm now.
    > We also completely recreated all of the java objects in the Cayenne modeler,
    > which may (or may not) have had anything to do with it.
    > At some point I'll try to go back and work out whether
    > the original problem was related to the
    > datatype, or was perhaps due to some
    > inconsistency in the model.
    >
    > If anyone does have any insights, we'd be happy to hear them.
    >
    > By the way, a minor point. In the Oracle adaptor, java.sql LONGVARCHAR maps
    > to Oracle LONG, which has been deprecated as of Oracle 9.
    >
    > Howard
    >
    >
    > ________________________________
    > From: Howard Treisman [mailto:htreisma..voka.com]
    > Sent: Wednesday, 21 December 2005 7:34 PM
    > To: cayenne-use..bjectstyle.org
    > Subject: CLOB issue with Oracle
    >
    >
    >
    >
    > Hi
    >
    > We've been experiencing some really weird errors with CLOBs against Oracle
    > in 1.2M8.
    >
    > Depending on whether we use a Long Varchar, CLOB, and what data we put into
    > the column, we get:
    > CLOB: Oracle errors saying we've got a constraint violation on the primary
    > key (seems like it's trying to create the same row multiple times)
    > Long Varchar: Oracle errors saying the data we're inserting is too large
    > (even though it's only "Hello world")
    > Varchar(200): A Cayenne error telling us the data is too long (even though
    > the data is "Hello world")
    >
    > This last one is the weirdest, because it's just a plain varchar - the stack
    > trace is:
    > 2005-12-21 19:16:16,963 INFO [STDOUT]
    > org.objectstyle.cayenne.validation.ValidationException:
    > [v.1.2M8 November 24 2005] Validation has failed.
    > Validation failure for
    > com.avoka.eda.fileupload.entity.EdaSubmission.formXml:
    > "formXml" exceeds maximum allowed length (200 chars): 27393
    > Validation failure for
    > com.avoka.eda.fileupload.entity.EdaSubmission.formXml:
    > "formXml" exceeds maximum allowed length (200 chars): 27571
    > Validation failure for
    > com.avoka.eda.fileupload.entity.EdaSubmission.formXml:
    > "formXml" exceeds maximum allowed length (200 chars): 27393
    > Validation failure for
    > com.avoka.eda.fileupload.entity.EdaSubmission.formXml:
    > "formXml" exceeds maximum allowed length (200 chars): 27393
    > Validation failure for
    > com.avoka.eda.fileupload.entity.EdaSubmission.formXml:
    > "formXml" exceeds maximum allowed length (200 chars): 27393
    > 2005-12-21 19:16:16,963 INFO [STDOUT] at
    > org.objectstyle.cayenne.access.ObjectStore.validateUncommittedObjects(ObjectStore.java:998)
    >
    > The same code runs perfectly on MySQL.
    >
    > Does anyone have any suggestions?
    >
    > Do the Oracle CLOB Junit tests run successfully in M8?
    >
    > Any suggestions or help greatfully accepted. (With the knowledge we haven't
    > given you much to work with here.)
    >
    > Many thanks,
    > Howard



    This archive was generated by hypermail 2.0.0 : Thu Dec 22 2005 - 09:16:59 EST