db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-2354) Unable to perform select query using DISTINCT on a read-only database
Date Mon, 11 Apr 2011 16:49:05 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-2354:
--------------------------------------

    Attachment: derby-2354-1a.diff

Attaching a patch that may fix the problem (derby-2354-1a.diff). It makes the repro pass in
my environment, but it's not tested in any other way yet.

It makes the following changes:

M       java/engine/org/apache/derby/impl/store/access/btree/index/B2IFactory.java
M       java/engine/org/apache/derby/impl/store/access/heap/HeapConglomerateFactory.java

Short-circuit the checkVersion() calls if it's a read-only database trying to create a temporary
conglomerate. This was needed in order to get rid of the "feature not supported" errors seen
in 10.3 and later.

M       java/engine/org/apache/derby/impl/store/raw/data/InputStreamContainer.java

When reusing a container cache entry that contains an InputStreamContainer (a read-only container),
replace it with a TempRAFContainer if the new conglomerate is a temporary conglomerate.

M       java/engine/org/apache/derby/impl/store/raw/data/TempRAFContainer.java

Use factory methods instead of creating RAFContainer objects directly when replacing a TempRAFContainer
with a non-temporary container object. This allows switching back from TempRAFContainer to
InputStreamContainer for read-only/zip databases. (The opposite of the situation handled by
the change in InputStreamContainer.)

M       java/engine/org/apache/derby/impl/store/raw/data/FileContainer.java

Remove implementations of setIdentity() and createIdentity() since they are now implemented
by all of FileContainer's sub-classes. (It would probably make more sense to move the implementations
in RAFContainer and InputStreamContainer back into FileContainer, since they're essentially
identical now.)

> Unable to perform select query using DISTINCT on a read-only database
> ---------------------------------------------------------------------
>
>                 Key: DERBY-2354
>                 URL: https://issues.apache.org/jira/browse/DERBY-2354
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.2.2.0
>         Environment: Reproduced in WinXP professional, Linux (Ubuntu 6.10) with Sun Java
5.0
>            Reporter: Thomas Kelder
>              Labels: derby_triage10_5_2
>         Attachments: DerbyTest.java, d2354-createdb.sql, d2354-repro.sql, derby-2354-1a.diff
>
>
> It is not possible to perform queries using DISTINCT on a read-only database packaged
in a zip file. This generates the following error:
> ERROR 40XD1: Container was opened in read-only mode.   
> 	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BaseContainer.use(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source)
> 	at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source)
> 	at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.addContainer(Unknown Source)
> 	at org.apache.derby.impl.store.raw.xact.Xact.addContainer(Unknown Source)
> 	at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
> 	at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown
Source)
> 	at org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown Source)
> 	at org.apache.derby.iapi.store.access.DiskHashtable.<init>(Unknown Source)
> 	at org.apache.derby.iapi.store.access.BackingStoreHashtable.spillToDisk(Unknown Source)
> 	at org.apache.derby.iapi.store.access.BackingStoreHashtable.add_row_to_hash_table(Unknown
Source)
> 	at org.apache.derby.iapi.store.access.BackingStoreHashtable.put(Unknown Source)
> 	at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown Source)
> 	at org.apache.derby.impl.store.access.btree.BTreeScan.fetchSet(Unknown Source)
> 	at org.apache.derby.impl.store.access.BackingStoreHashTableFromScan.<init>(Unknown
Source)
> 	at org.apache.derby.impl.store.access.RAMTransaction.createBackingStoreHashtableFromScan(Unknown
Source)
> 	at org.apache.derby.impl.sql.execute.HashScanResultSet.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.executeQuery(Unknown Source)
> 	at DerbyTest.main(DerbyTest.java:29)
> The problem can be reproduced using the attached java program and the following database
file:
> http://ftp2.bigcat.unimaas.nl/~thomas.kelder/derbytest/testdb.zip.
> Both the 'derby.storage.tempDirectory' and 'derby.stream.error.file' properties are set
to writable locations, as advised in the help file.
> Also see derby-user mailing list thread: http://article.gmane.org/gmane.comp.apache.db.derby.user/6123
> "This appears to be a bug, possibly a regression.  When I converted your
> DB to10.0 everything worked fine even when I did NOT set the properties
> for tempDirectory and error.file (hmmm..).  When I switched to using the
> 10.1  or 10.2 jars and accessed the very same database the 40XD1 ERROR
> happened." (Stanley Bradbury)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message