db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3175) NullPointerException on INSERT after ALTER TABLE ... DROP COLUMN
Date Fri, 09 Nov 2007 20:42:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541435

Bryan Pendleton commented on DERBY-3175:

Here are 3 possible ways to ensure that the autoincrementValue is preserved during the drop

1) Add autoincrementValue to ColumnDescriptor. Change SYSCOLUMNS.buildDescriptor to
retrieve the autoincrementValue from the SYSCOLUMNS row. Change SYSCOLUMNS.makeRow
to set the autoincrementValue in SYSCOLUMNS from the ColumnDescriptor's value. Change
any other places that create a ColumnDescriptor to initialize the autoincrementValue to match

2) Change SYSCOLUMNS.makeRow to take a new 3rd argument: autoincrementValue. Change
AlterTableCOnstantAction's drop column logic so that it fetches the old value of the
autoincrementValue from the SYSCOLUMNS row before it deletes it, then passes that old value
to the makeRow call when adding back the column descriptor. I don't really like this solution,
but I thought of it so I'm recording it here.

3) Change AlterTableConstantAction's  drop column logic so that it doesn't drop-and-re-add
all the subsequent column descriptors in order to change their positions, but instead issues
an UPDATE operation on those column descriptors to decrement their column number field.

Technique #1 seems pretty straightforward, it's just a bunch of code grunging. It does make
ColumnDescriptor object instance slightly larger in memory.

Technique #3 seems appealing, because if all we want to change about a particular
SYSCOLUMNS row is the column number, why should we have to delete and re-add the
SYSCOLUMNS row in order to make that change? It doesn't appear that the column number
field in SYSCOLUMNS is indexed, so I don't think there should be any index complexity.

If I can find some example code for one of the other system catalogs which issues an UPDATE
rather than a DROP and an INSERT, I'll try to implement technique #3 modelled on that.

> NullPointerException on INSERT after ALTER TABLE ... DROP COLUMN
> ----------------------------------------------------------------
>                 Key: DERBY-3175
>                 URL: https://issues.apache.org/jira/browse/DERBY-3175
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:,
>            Reporter: Knut Anders Hatlen
>            Assignee: Bryan Pendleton
>         Attachments: bug.sql, d3175_codeChangeOnly.diff, fixWith3177Case.diff, fixWithTest.diff
> ij version 10.3
> ij> connect 'jdbc:derby:bugdb;create=true';
> ij> create table t (
>        x varchar(12),
>        y varchar(12),
>        id int primary key generated by default as identity
> );
> 0 rows inserted/updated/deleted
> ij> alter table t drop column y;
> 0 rows inserted/updated/deleted
> ij> insert into t(x) values 'a';
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
>         at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
>         at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
>         at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
>         at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
>         at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
>         at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
>         at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
>         at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
>         at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
>         at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
>         at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
>         at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
>         at org.apache.derby.tools.ij.main(Unknown Source)
>         at org.apache.derby.iapi.tools.run.main(Unknown Source)
> Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
>         ... 18 more
> Caused by: java.lang.NullPointerException
>         at org.apache.derby.impl.sql.compile.ResultColumn.columnTypeAndLengthMatch(Unknown
>         at org.apache.derby.impl.sql.compile.ResultColumnList.columnTypesAndLengthsMatch(Unknown
>         at org.apache.derby.impl.sql.compile.InsertNode.bindStatement(Unknown Source)
>         at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
>         at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
>         at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
>         ... 11 more

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message