[
https://issues.apache.org/jira/browse/DERBY-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261946#comment-13261946
]
Mike Matrigali commented on DERBY-5679:
---------------------------------------
I think the approach of getting update to log nulls in this case is a good one.
Store is going to be broken if non-existent columns are
anywhere other than at the end of the row. Changing non-existent columns to
null valued columns at update time seems like a good
approach.
Is the code you are changing happening because the user update is updating
column N with a value, column N-1 and N were
added because of add column and neither has ever had a real value. And this
trip through log column is dealing with column N-1.
I think it might be cleaner if you just add another if/then/else just for
COLUMN_NULL at line 6306, rather than code the case of a real
column and a nonexistent column in same case. I think sColumn is null for your
case in this and found it confusing, seems like
the code works by accident not referencing the null pointer, so someone later
could easily use it thinking it was valid.
The code for COLUMN_NULL is much simpler as it just knows it is creating a NULL
value out of the ether.
nits:
o could you make the code be 80 column
o I think a different name might be better, maybe COLUMN_CREATENULL. I kept
seeing the COLUMN_NULL name and thinking it
was an existing null column, which is a different code path.
o could you add comments to logColumn to say what the new option is doing.
o a good case to add but does not need to hold up your checkin would be both
regular row and long row case. Something like
add 100 columns, update 50th column, check you can retrieve all 100, abort
check you can retrieve all as expected. Another row
do 50th update and then 99th update.... The long row case comes when you
make all this work happen on second page vs
first, so for 2k pages something like following:
create table with real columns to fill most of a page. with just ddl you
can add columns of char(250) that will guarantee 250 bytes
for any insert, or you can use clob/blob and make sure you add almost
pagesize bytes. Then use alter to add columns. interesting
cases would be some nonexistent columns on first page and then an update of
one that will end up on second page or more.
> Rolling back a transaction leads to an inconsistent state
> ---------------------------------------------------------
>
> Key: DERBY-5679
> URL: https://issues.apache.org/jira/browse/DERBY-5679
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.2.1, 10.8.2.2
> Environment: >sysinfo
> ------------------ Java Information ------------------
> Java Version: 1.6.0_26
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files (x86)\Java\jre6
> Java classpath: .;C:\Program Files
> (x86)\Java\jre7\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbytools.jar
> OS name: Windows 7
> OS architecture: x86
> OS version: 6.1
> Java user name: bmason
> Java user home: C:\Users\BMASON
> Java user dir: C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> java.runtime.version: 1.6.0_26-b03
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derby.jar] 10.8.2.2 -
> (1181258)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbytools.jar]
> 10.8.2.2 - (1181258)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbynet.jar]
> 10.8.2.2 - (1181258)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbyclient.jar]
> 10.8.2.2 - (1181258)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale : [English/New Zealand [en_NZ]]
> Found support for locale: [cs]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [de_DE]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [es]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [fr]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [hu]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [it]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ja_JP]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ko_KR]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [pl]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [pt_BR]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [ru]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [zh_CN]
> version: 10.8.2.2 - (1181258)
> Found support for locale: [zh_TW]
> version: 10.8.2.2 - (1181258)
> ------------------------------------------------------
> Reporter: Brett Mason
> Priority: Critical
> Attachments: RollbackFails - expected output.txt, RollbackFails.sql,
> derby-5679-01-aa-alterTableTouchAllRows.diff,
> derby-5679-01-ab-storedPageChange.diff
>
>
> Rolling back a transaction can leave a table in an inconsistent state if the
> table has been previously altered through the addition of new columns. It
> appears that if newly added columns have not been changed from their default
> value, then when a transaction which sets new values for these columns is
> rolled back the new columns are not restored to their previous values.
> Attached is an ij script with fairly minimal steps to reproduce the problem
> on Derby 10.6.2.0 and 10.8.2.2 (Win7 x64, Sun 32-bit JRE 1.6.0.26). Expected
> and observed output also attached.
> Would appreciate any suggestions as to a workaround for this issue. Running
> SYSCS_UTIL.SYSCS_COMPRESS_TABLE on the table after adding the columns seems
> to avoid the problem but may be just masking the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
