Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 1 Apr 2016 03:18:25 +0000 (UTC)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12954458.1459293579000.107987.1459480705523@Atlassian.JIRA>
In-Reply-To: <JIRA.12954458.1459293579000@Atlassian.JIRA>
References: <JIRA.12954458.1459293579000@Atlassian.JIRA>
 <JIRA.12954458.1459293579938@arcas>
Subject: [jira] [Commented] (DERBY-6880) Update failing with
 java.sql.SQLDataException
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221076#comment-15221076 ] 

Bryan Pendleton commented on DERBY-6880:
----------------------------------------

In the code:

{code}
                for(col=1;col<=maxColumns;col++)
                {
                    ColumnDescriptor cd = td.getColumnDescriptor(col);
                    if(cd.isAutoincrement())
                    {
                        break;
                    }
                }

                if(col <= maxColumns)
                {
                    DataValueDescriptor dvd = row.cloneColumn(col);
                    identityVal = dvd.getLong();
                }
{code}

is where we go astray. The for loop locates the correct column descriptor,
it is for the "id" column of table "pipeline_command".

But the table descriptor in "td" is not accurate for use with the data in "row".

In this particular case, "td" describes the underlying "pipeline_command" table,
and it appears to have all the relevant columns just as you would expect, and
so column 1 is indeed the autogenerated "ID" column.

However, column 1 of "row" is nothing the same at all. "row" is a ValueRow,
and has only 3 columns, in my case the three columns are:
  - the old value of the "status" column
  - the new value of the "status" column
  - some sort of value that is displayed as "(1,8)", which I haven't decoded yet.

I think that "row", at the time when we are running, is some sort of intermediate
object, and the code in UpdateResultSet is getting all confused because it
is trying to use the underlying table descriptor to interpret the values in "row",
but "row" is not a row from the base "pipeline_command" table anymore, it is
some intermediate "old-value,new-value" row that has been constructed by the query.

Anyway, that's as far as I got today fooling around with the reproduction script.


> Update failing with java.sql.SQLDataException 
> ----------------------------------------------
>
>                 Key: DERBY-6880
>                 URL: https://issues.apache.org/jira/browse/DERBY-6880
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.12.1.1
>            Reporter: Simon Zee
>         Attachments: repro.diff
>
>
> When updating a single column in a table using executeUpdate() via Vert.x I am receiving the following exception:
> java.sql.SQLDataException: Invalid character string format for type long.
> 	at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:84)
> 	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:233)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2405)
> 	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:88)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1432)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(EmbedPreparedStatement.java:320)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309)
> 	at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:410)
> 	at io.vertx.ext.jdbc.impl.actions.JDBCUpdate.execute(JDBCUpdate.java:50)
> 	at io.vertx.ext.jdbc.impl.actions.JDBCUpdate.execute(JDBCUpdate.java:34)
> 	at io.vertx.ext.jdbc.impl.actions.AbstractJDBCAction.handle(AbstractJDBCAction.java:48)
> 	at io.vertx.ext.jdbc.impl.actions.AbstractJDBCAction.handle(AbstractJDBCAction.java:33)
> 	at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$15(ContextImpl.java:296)
> 	at io.vertx.core.impl.OrderedExecutorFactory$OrderedExecutor.lambda$new$261(OrderedExecutorFactory.java:91)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: ERROR 22018: Invalid character string format for type long.
> 	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
> 	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:285)
> 	at org.apache.derby.iapi.types.SQLChar.getLong(SQLChar.java:447)
> 	at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:534)
> 	at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:272)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:473)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:352)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1340)
> 	... 13 more
> Further details and discussion can be found here:
> https://mail-archives.apache.org/mod_mbox/db-derby-user/201603.mbox/%3CCAHbUnCXkHMKE1u9R3D-z9Njp8goAV7%2B0vPOmgafH8DCqG8mSpQ%40mail.gmail.com%3E
> Notably, I have tried executing the same update via other means (for example, manually via SquirrelSQL, and via the ORMLite framework) and the update succeeds. This may be due to the exact JDBC APIs they are using (for example, SquirrelSQL is not using a prepared statement, and ORMLite updates all the columns when it updates a table rather than just some of them).
> I have created a complete but minimal example that illustrates the problem in the following GitHub project:
> https://github.com/ssadedin/DerbyDebug
> My derby / system information is as follows:
> $ java -cp 'lib/*' org.apache.derby.tools.sysinfo
> ------------------ Java Information ------------------
> Java Version:    1.8.0_72
> Java Vendor:     Oracle Corporation
> Java home:       /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre
> Java classpath:  lib/derby.jar:lib/derbyclient.jar
> OS name:         Mac OS X
> OS architecture: x86_64
> OS version:      10.11.1
> Java user name:  simon
> Java user home:  /Users/simon
> Java user dir:   /Users/simon/Documents/workspace/BrokenDerby
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_72-b15
> --------- Derby Information --------
> [/Users/simon/Documents/workspace/BrokenDerby/lib/derby.jar] 10.12.1.1 - (Unversioned directory)
> [/Users/simon/Documents/workspace/BrokenDerby/lib/derbyclient.jar] 10.12.1.1 - (Unversioned directory)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> ------------------------------------------------------
> ------------------------------------------------------


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)