db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)
Date Mon, 12 Jun 2006 12:58:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415856 ] 

Andreas Korneliussen commented on DERBY-1384:

> This is the case I was thinking about. I have coded my application without specifying
lengths for BLOB/CLOB. I would normally expect this to work:
> INSERT INTO tblob select * from tblob; OR
> INSERT INTO tblob select * from myblobTab;
> My concern was on soft-update, it would be possible to insert larger than 1MB and later
on downgrade, same operations like above will not work as some instances of BLOB could now
be larger than 1MB. (and hence above operations could fail on 10.1)

I do not see how this would be a problem on downgrade. If the operations worked in soft-upgrade,
downgrade will not redefine the size of the blob-columns of existing tables.  This issue is
about changing the default max size of columns when doing "CREATE TABLE ..", so unless the
scenario contains a create table somewhere, it should not be an issue.

> May be this is extreme case and may not be worth protecting... but one could look at
10.1 BLOB (without size) datatype to be between 1-1MB and is being changed to 1-2GB.

An extreme case is that the user applications recreates some of its tables, and not other
tables during soft-upgrade. This means that some of the tables may allow 1MB blob columns
and other tables 2GB blob columns. This should then only be a problem if the application suddenly
starts using blobs with size > 1MB, and do similar queries as you gave. These will now
fail. If the applications had been running only on 10.1 it would have failed once it started
inserting blobs with size >1M into the tables.
I do not think this extreme case is a soft-upgrade problem, as the same problem could be constructed
in a hard-upgrade scenario. Therefore, I do not think it is worth adding any logic in soft-upgrade

> Increase default BLOB/CLOB length to maximum supported (2G?)
> ------------------------------------------------------------
>          Key: DERBY-1384
>          URL: http://issues.apache.org/jira/browse/DERBY-1384
>      Project: Derby
>         Type: Improvement

>   Components: SQL
>     Reporter: Bernt M. Johnsen
>     Assignee: Bernt M. Johnsen
>     Priority: Minor
>      Fix For:
>  Attachments: derby-1384-code.diff, derby-1384-code.stat, derby-1384-docs.diff, derby-1384-docs.stat
> Default BLOB/CLOB length should be the maximum length supported by Derby (2G?)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message