db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)
Date Thu, 15 Jun 2006 10:44:54 GMT
I intend to commit this patch unless someone protests within a day or

>>>>>>>>>>>> Andreas Korneliussen (JIRA) wrote (2006-06-12
>     [ 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 mode.
> > 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,
> >
> > 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:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira

Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

View raw message