I intend to commit this patch unless someone protests within a day or two. >>>>>>>>>>>> Andreas Korneliussen (JIRA) wrote (2006-06-12 12:58:30): > [ > 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: 10.2.0.0 > > 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: > 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
pgpq4tRdNcXZt.pgp
Description: PGP signature
