[ http://issues.apache.org/jira/browse/DERBY-630?page=comments#action_12441875 ] Yip Ng commented on DERBY-630: ------------------------------
Hi Bryan. I am glad that you brought this up. In the current state of the trunk, the soft upgrade code that I put into the current patch will not get triggered since the release.properties file's beta property is set to true and the maint property has a value of 0 which indicates alpha. Thus, the system will not allow an upgrade to occur. i.e.: <snip> ij version 10.3 ij> connect 'jdbc:derby:db102' user 'user1'; ERROR XJ040: Failed to start database 'db102', see the next exception for details. ERROR XCW00: Unsupported upgrade from '10.2' to '10.3 beta'. </snip> I am not sure what the next release will be, so I didn't modify the release.properties file. However, I did run the soft upgrade test manually to verify my code changes are executed correctly. What I did was: 1) Set the beta property to false and maint property to non-zero value (1000001, for example) 2) In order for the soft upgrade to get triggered, the data dictionary(dd) version (currently 140 for 10.2.1.6) needs to be incremented to a higher version number than the on-disk version. 3) Create the database in 10.2.1.6, this will have dd version of 140. <snip> ij version 10.2 ij> connect 'jdbc:derby:db102;create=true' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij> describe 'sys.sysstatements'; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ STMTID |CHAR |NULL|NULL|36 |NULL |72 |NO STMTNAME |VARCHAR |NULL|NULL|128 |NULL |256 |NO SCHEMAID |CHAR |NULL|NULL|36 |NULL |72 |NO TYPE |CHAR |NULL|NULL|1 |NULL |2 |NO VALID |BOOLEAN |NULL|NULL|1 |NULL |NULL |NO TEXT |LONG VAR&|NULL|NULL|32700 |NULL |NULL |NO LASTCOMPILED |TIMESTAMP|0 |10 |26 |NULL |NULL |YES COMPILATIONSCHEMAID |CHAR |NULL|NULL|36 |NULL |72 |NO USINGTEXT |LONG VAR&|NULL|NULL|32700 |NULL |NULL |YES 9 rows selected ij> describe 'sys.sysviews'; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ TABLEID |CHAR |NULL|NULL|36 |NULL |72 |NO VIEWDEFINITION |LONG VAR&|NULL|NULL|32700 |NULL |NULL |NO CHECKOPTION |CHAR |NULL|NULL|1 |NULL |2 |NO COMPILATIONSCHEMAID |CHAR |NULL|NULL|36 |NULL |72 |NO 4 rows selected </snip> 4) Boot this 10.2 database using the trunk code with my patch(dd version for runtime is 141). <snip> ij version 10.3 ij> connect 'jdbc:derby:db102' user 'user1'; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij> describe 'sys.sysstatements'; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ STMTID |CHAR |NULL|NULL|36 |NULL |72 |NO STMTNAME |VARCHAR |NULL|NULL|128 |NULL |256 |NO SCHEMAID |CHAR |NULL|NULL|36 |NULL |72 |NO TYPE |CHAR |NULL|NULL|1 |NULL |2 |NO VALID |BOOLEAN |NULL|NULL|1 |NULL |NULL |NO TEXT |LONG VAR&|NULL|NULL|32700 |NULL |NULL |NO LASTCOMPILED |TIMESTAMP|0 |10 |26 |NULL |NULL |YES COMPILATIONSCHEMAID |CHAR |NULL|NULL|36 |NULL |72 |YES USINGTEXT |LONG VAR&|NULL|NULL|32700 |NULL |NULL |YES 9 rows selected ij> describe 'sys.sysviews'; COLUMN_NAME |TYPE_NAME|DEC&|NUM&|COLUM&|COLUMN_DEF|CHAR_OCTE&|IS_NULL& ------------------------------------------------------------------------------ TABLEID |CHAR |NULL|NULL|36 |NULL |72 |NO VIEWDEFINITION |LONG VAR&|NULL|NULL|32700 |NULL |NULL |NO CHECKOPTION |CHAR |NULL|NULL|1 |NULL |2 |NO COMPILATIONSCHEMAID |CHAR |NULL|NULL|36 |NULL |72 |YES 4 rows selected </snip> Notice the COMPILATIONSCHEMAID's IS_NULLABLE column for both system tables are now set to true after the soft upgrade. So it works as expected. For step 2 described above, the DD runtime version should have been incremented along with this fix and I noticed there is an 10.1 to 10.2 upgrade test available in the regression. Perhaps I can investigate this abit more and make this verification step automated with this test. I'll resubmit a follow-up patch. > create trigger fails with null pointer exception > ------------------------------------------------ > > Key: DERBY-630 > URL: http://issues.apache.org/jira/browse/DERBY-630 > Project: Derby > Issue Type: Bug > Components: SQL > Affects Versions: 10.1.1.0 > Environment: windows 2000, sun jdk 1.5.0 > Reporter: mardacay > Assigned To: Yip Ng > Attachments: derby630-trunk-diff01.txt, derby630-trunk-stat01.txt > > > When i create a brand new database, and execute the following statements all > in one transaction or each of them in their own transaction, then it fails at > trigger creation with null pointer exception. if i exclude the schema names > from statement, then it runs fine. (If S1 is ommited from every statement > then it runs fine). Once the version without the schema names run fine, i can > run the version that has schema names, fine also. > create schema S1; > create table > S1.PRODUCT( > PRODUCT_ID VARCHAR(255) unique not null, > VERSION BIGINT > ); > > create table > S1.CATEGORY( > CAT_ID VARCHAR(255), > NAME varchar(255) not null, > VERSION BIGINT > ); > create table > S1.PROD_IN_CAT( > CAT_ID VARCHAR(255) not null, > PRODUCT_ID VARCHAR(255) not null, > VERSION BIGINT > ); > > create trigger S1.product_v > after update of version on S1.product > referencing new as n > for each row > mode db2sql > update S1.prod_in_cat set version = n.version where > S1.prod_in_cat.product_id=n.product_id; > java.lang.NullPointerException > at > org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown > Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown > Source)Stopping progress indicator for: Executing SQL > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) -- 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
