You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <ji...@apache.org> on 2008/05/13 18:47:55 UTC
[jira] Updated: (DERBY-3219) Group by query with many aggregate
columns and case statements fails with: ERROR XSDA7: Restore of a
serializable or SQLData object of class , attempted to read more data than
was originally stored
[ https://issues.apache.org/jira/browse/DERBY-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-3219:
----------------------------------
I have not been following this issue, so just commenting on the idea of changing the format understood by read/write external for SQLchar. I believe while readExternal is not used to read data from store pages into returned user columns, the corresponding interface readExternalFromArray() depends on understanding the same exact format as readExternal and both are tied to the format output by writeExternal.
Originally readExternal and writeExternal was the only way data was read/written to disk by the store. So when changing
them you need to consider the upgrade of existing data on disk. At some point, pre-derby new interfaces were added for store
to use which could be highly optimized for reading and writing the data to the in memory array that represents the page whenever
store is interacting with the page - this was a huge performance win at the time, I have not idea given the advances in JIT technology
whether that is still the case.
So there is no "rule" against changing the format, but if one does it they need to consider soft and hard upgrade dependencies for
all system and user character based data. Unfortunately the current format does not include any type of version id in the data
itself, so handling the formating has to be at a higher level. For instance we could handle it at the column format id level by having
and old char format id and new char format id.
> Group by query with many aggregate columns and case statements fails with: ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3219
> URL: https://issues.apache.org/jira/browse/DERBY-3219
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.1.4
> Reporter: Stan Bradbury
> Assignee: Bryan Pendleton
> Attachments: pivotView.zip
>
>
> using the attached database (v10.3) - " select * from pivotview " fails with the stack trace below. A view (pivotview_ok) created on a subset of the columns in pivotview executes fine. Adding one column back into pivotview_ok causes failures most of the time. See attached for view definitions.
> 2007-11-21 00:58:49.421 GMT Thread[main,5,main] (XID = 2734422), (SESSIONID = 0), (DATABASE = pivotview), (DRDAID = null), Failed Statement is: select * from pivotview
> ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was originally stored
> at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainerHandle.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.mergeARow(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.init(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeSort.openSortScan(Unknown Source)
> at org.apache.derby.impl.store.access.RAMTransaction.openSortScan(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.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)
> 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)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readBoolean(DataInputStream.java:248)
> at org.apache.derby.impl.sql.execute.MaxMinAggregator.readExternal(Unknown Source)
> at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
> at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
> ... 22 more
> ============= begin nested exception, level (1) ===========
> java.io.EOFException
> at java.io.DataInputStream.readBoolean(DataInputStream.java:248)
> at org.apache.derby.impl.sql.execute.MaxMinAggregator.readExternal(Unknown Source)
> at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(Unknown Source)
> at org.apache.derby.iapi.types.UserType.readExternal(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainer.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.raw.data.StreamFileContainerHandle.fetchNext(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.mergeARow(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeScan.init(Unknown Source)
> at org.apache.derby.impl.store.access.sort.MergeSort.openSortScan(Unknown Source)
> at org.apache.derby.impl.store.access.RAMTransaction.openSortScan(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.loadSorter(Unknown Source)
> at org.apache.derby.impl.sql.execute.GroupedAggregateResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.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)
> 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)
> ============= end nested exception, level (1) ===========
> Cleanup action completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.