[
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.
