[jira] Closed: (DERBY-2981) Convert jdbcapi/prepStamtNull.java to JUnit
[ https://issues.apache.org/jira/browse/DERBY-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-2981. -- Resolution: Fixed Fix Version/s: 10.4.0.0 Seems this was committed with revision 567126 back in August 2007. I'm marking the issue as fixed and closed. Convert jdbcapi/prepStamtNull.java to JUnit --- Key: DERBY-2981 URL: https://issues.apache.org/jira/browse/DERBY-2981 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.4.0.0 Reporter: Ramin Moazeni Assignee: Ramin Moazeni Fix For: 10.4.0.0 Attachments: DERBY-2981.diff, DERBY-2981.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[ https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3221: -- Derby Info: [Regression] Dyre, I think you are right that this is a regression caused by DERBY-827. I'm not able to reproduce the error on revision 540920, but it is reproducible on revision 540921, which introduced the reuse of result sets. java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0 Key: DERBY-3221 URL: https://issues.apache.org/jira/browse/DERBY-3221 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4, 10.3.2.1 Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0) Reporter: Tim Halloran Attachments: conlomerate.tar.gz We are getting an SQLException when several prepared statement deletes are done upon an existing database. As far as we can tell this exception should never occur unless (evil) things like deleting the database or editing files occurs. This is using the embedded driver within a plug-in inside RAD 7.0 (and Eclipse 3.3). I'm not sure what else to submit that might be helpful. java.sql.SQLException: The conglomerate (-5) requested does not exist. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) 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.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown Source) at $Proxy1.execute(Unknown Source) at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source) at com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown Source) at com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown Source) at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown Source) at org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown Source) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 14 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3294) Convert demo/checkToursDB.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556525#action_12556525 ] John H. Embretsen commented on DERBY-3294: -- Manjula Kutty wrote: -The doSelect() asserts with the original number of rows. But after deleting the rows, those asserts will fail. So I thought not doing since the assertions will make sure the rows are deleted. OK. I think what you are saying is that the number of rows deleted is asserted in the doDelete() method, so there is no need to check this again by doing another select count(*) after the deletes. - testToursDB() method's Javadoc specifies a wrong exception in the @throws tag. There is also a typo (tourdb -- ToursDB) in the Javadoc. Fixed The typo is fixed, but it still specifies the wrong exception after the @throws tag. (If you are going to provide a new patch, it would be good to add a @param tag for the CheckToursDBTest constructor as well.) I have no further comments at this time, so I guess I'll leave the rest to a committer... Convert demo/checkToursDB.java to junit --- Key: DERBY-3294 URL: https://issues.apache.org/jira/browse/DERBY-3294 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.4.0.0 Reporter: Manjula Kutty Assignee: Manjula Kutty Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3294_diff_12_28.txt, DERBY-3294_stat_12_28.txt, DERBY_3294_diff_01_02.txt, DERBY_3294_diff_1_4.txt, DERBY_3294_stat_01_02.txt, DERBY_3294_stat_1_4.txt Place holder for the junit conversion of demo/checkToursDB.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2359) Code cleanups for the org.apache.derby.impl.store.access.* packages
[ https://issues.apache.org/jira/browse/DERBY-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-2359. Resolution: Fixed Derby Info: (was: [Patch Available]) Committed 'derby-2359-4a-OpenConglomerateScratchSpace.diff' to trunk with revision 609543. Committed 'derby-2359-5a-Conglomerate_API_change.diff' to trunk with revision 609558. Marking issue as fixed, since I do not plan to make more changes. Will close the issue in a few days. Code cleanups for the org.apache.derby.impl.store.access.* packages --- Key: DERBY-2359 URL: https://issues.apache.org/jira/browse/DERBY-2359 Project: Derby Issue Type: Improvement Components: Store Affects Versions: 10.3.1.4 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: btreeforwardscan_cleanup.diff, derby-2359-1a-unused_imports.diff, derby-2359-1a-unused_imports.stat, derby-2359-1b-unused_imports.diff, derby-2359-1b-unused_imports.stat, derby-2359-2a_method-renames.diff, derby-2359-2a_method-renames.stat, derby-2359-3a-visibility_changes.diff, derby-2359-3a-visibility_changes.stat, derby-2359-4a-OpenConglomerateScratchSpace.diff, derby-2359-5a-Conglomerate_API_change.diff When trying to learn more about the access layer, it was discovered that some code improvements could easily be made to increase the readability of the code. Patches attached to this issue will be cleanup patches only, and no functionality should be changed. Changes the will/may be made: * remove unused imports * remove unused methods * fix JavaDoc errors * tighter encapsulation and removal of unused variables where appropriate -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2871) XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO.
[ https://issues.apache.org/jira/browse/DERBY-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julius Stroffek updated DERBY-2871: --- Attachment: d2871.stat d2871.diff This is the patch fixing all the possible issues with the test I found. It merges also a change made for DERBY-2953. I ran the tests without failures. I am planning to run the tests also on the box where the test was originally failing. More detailed description of changes will follow afterwards. XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. -- Key: DERBY-2871 URL: https://issues.apache.org/jira/browse/DERBY-2871 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.3.1.4 Environment: OS: HP-UX v1.11 i JDK: HP 1.5.0.03 Reporter: Henri van de Scheur Assignee: Julius Stroffek Priority: Minor Attachments: d2871-test.diff, d2871-test.stat, d2871.diff, d2871.diff, d2871.stat, d2871.stat Method: org.apache.derbyTesting.functionTests.tests.jdbcapi.XATransactionTest Signature: %XAER_PROTO : Error executing a XAResource.commit(), server returned XAER_PROTO% Also see: http://dbtg.thresher.com/derby/test/10.3.1.0_RC/jvm1.5/testing/testlog/hpux/548006-suitesAll_diff.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[
https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556565#action_12556565
]
Dyre Tjeldvoll commented on DERBY-3221:
---
Thanks for your feedback, Bryan and Knut. So it is indeed a consequence of
DERBY-827 :(
Hmm, the strange part is that according to the call stack posted by Knut the
error happens at SubShape.insert(SubShape.java:37):
// if nothing is new, then nothing to do
if (ps.executeUpdate() 0) {
// do pre stuff
for (String stmt : sql.getProperty(pre
).split(;)) {
ps = conn.prepareStatement(stmt)
;
ps.executeUpdate(); // ---
line 37
}
So this particular statement is AFAICT never re-executed. So, in theory,
DERBY-827 should not make a dfference here, and if I read James' comment
correctly, it is the prepared statement being re-executed at line 57 that seems
to be the culprit. Meaning that preparing it prior to each execute removes the
symptom...
So we have to assume then, that some cruft left in the internal result set tree
of this prepared statement SOMEHOW causes the newly prepared statement at line
37 to fail. Right now, I cannot imagine how that could happen...
java.sql.SQLException: The conglomerate (-5) requested does not exist. from
Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
Key: DERBY-3221
URL: https://issues.apache.org/jira/browse/DERBY-3221
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0)
Reporter: Tim Halloran
Attachments: conlomerate.tar.gz
We are getting an SQLException when several prepared statement deletes are
done upon an existing database. As far as we can tell this exception should
never occur unless (evil) things like deleting the database or editing files
occurs. This is using the embedded driver within a plug-in inside RAD 7.0
(and Eclipse 3.3).
I'm not sure what else to submit that might be helpful.
java.sql.SQLException: The conglomerate (-5) requested does not exist.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
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.executeStatement(Unknown Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown
Source)
at $Proxy1.execute(Unknown Source)
at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source)
at
com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown
Source)
at
com.surelogic.sierra.jdbc.project.ClientProjectManager.synchronizeProject(Unknown
Source)
at
com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.synchronize(Unknown
Source)
at com.surelogic.sierra.client.eclipse.jobs.SynchronizeJob.run(Unknown
Source)
at org.eclipse.core.internal.jobs.Worker.run(Unknown Source)
Caused by: ERROR XSAI2: The conglomerate (-5) requested does not exist.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown
Source)
at org.apache.derby.impl.store.access.RAMTransaction.openScan(Unknown Source)
at
org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.TemporaryRowHolderResultSet.getNextRow(Unknown
Source)
at org.apache.derby.impl.sql.execute.IndexChanger.finish(Unknown Source)
at org.apache.derby.impl.sql.execute.IndexSetChanger.finish(Unknown Source)
at org.apache.derby.impl.sql.execute.RowChangerImpl.finish(Unknown
[jira] Updated: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-3302: -- Attachment: npe.sql Attaching a script which reproduces the failure. Follow these steps: 1. Start ij 2. Execute this command in ij: run 'npe.sql'; 3. Terminate ij with Ctrl-C (don't terminate it with Ctrl-D or EXIT, as those commands will perform a clean shutdown) 4. Restart ij 5. Open a connection to the database with this command: connect 'jdbc:derby:colldb'; Then you'll get a NullPointerException with the following stack trace: java.lang.NullPointerException at org.apache.derby.iapi.types.SQLChar.getCollationKey(SQLChar.java:2516) at org.apache.derby.iapi.types.WorkHorseForCollatorDatatypes.stringCompare(WorkHorseForCollatorDatatypes.java:88) at org.apache.derby.iapi.types.CollatorSQLVarchar.stringCompare(CollatorSQLVarchar.java:159) at org.apache.derby.iapi.types.SQLChar.compare(SQLChar.java:902) at org.apache.derby.impl.store.access.btree.ControlRow.compareIndexRowToKey(ControlRow.java:1354) at org.apache.derby.impl.store.access.btree.index.B2IUndo.findUndo(B2IUndo.java:221) at org.apache.derby.impl.store.raw.data.LogicalPageOperation.findLogicalPage(LogicalPageOperation.java:358) at org.apache.derby.impl.store.raw.data.LogicalPageOperation.generateUndo(LogicalPageOperation.java:164) at org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:991) at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:919) at org.apache.derby.impl.store.raw.xact.XactFactory.rollbackAllTransactions(XactFactory.java:529) at org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:1201) at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1992) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:546) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419) at org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1001) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1992) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:546) at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:419) at org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:753) at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:201) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1992) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1829) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1695) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1575) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:994) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:542) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1957) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:255) at org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73) at org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:211) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:154) at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:1238) at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:1088) at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:916) at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:328) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248) at org.apache.derby.impl.tools.ij.Main.go(Main.java:215) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181) at
[jira] Created: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
NullPointerException during recovery of database with territory-based collation --- Key: DERBY-3302 URL: https://issues.apache.org/jira/browse/DERBY-3302 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.2.1, 10.3.1.4, 10.4.0.0 Reporter: Knut Anders Hatlen When logical undo is performed on a database with territory-based collation, you may get a NullPointerException in SQLChar.getCollationKey() because SQLChar.getLocaleFinder() returns null. This bug was reported on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3221) java.sql.SQLException: The conglomerate (-5) requested does not exist. from Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
[
https://issues.apache.org/jira/browse/DERBY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dyre Tjeldvoll updated DERBY-3221:
--
Attachment: derby-3221.prelim.diff
SubShape.properties
The ASSERT reported in a debug build is really a red herring and
not related to the original problem. I think the ASSERT simply is
too strict as it does not allow what would be legal
conversion. Simply modifying the queries so that they explicitly
CAST all INTEGER values to BIGINT seems to remove that
problem (see attached modified_SubShape.properties), and exposes the
original problem with the missing temporary conglomerate. And
that problem is only reported by the prepared statement that is
actually re-executed, so that fits nicely with the DERBY-827
hypothesis.
The new call-stack from the line 57 (insert.test) statement shows
that the missing conglomerate error comes from (re-)using
InsertResultSet.rowHolder. At first I thought the problem was
that close() isn't called on this object in
InsertResultSet.close(), but then I noticed that
normalInsertCore() calls close() on it:
if (rowHolder != null)
{
rowHolder.close();
// rowHolder kept across opens
}
The comment doesn't really make sense since rowHolder, in fact,
is closed. Anyway, the real problem is that code in the beginning
of normalInsertCore() assumes that the comment is true, and only
initializes rowHolder on the first execute:
if (firstExecute constants.deferred)
{
Properties properties = new Properties();
// Get the properties on the old heap
rowChanger.getHeapConglomerateController().getInternalTablePropertySet(properties);
/*
** If deferred we save a copy of the entire row.
*/
rowHolder = new TemporaryRowHolderImpl(activation,
properties);
rowChanger.setRowHolder(rowHolder);
}
Simply commenting out firstExecute in the if-test (see attached
derby-3221.prelim.diff) makes the repro run without problems. I
have not run any other tests with this change, nor do I know if
this is the right approach. But at least it points to what causes
the problem, and explains why it was introduced by DERBY-827.
java.sql.SQLException: The conglomerate (-5) requested does not exist. from
Derby 10.3.1.4 embedded within Eclipse 3.3 and RAD 7.0
Key: DERBY-3221
URL: https://issues.apache.org/jira/browse/DERBY-3221
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: Windows Vista Ubuntu Linux on IBM's VM (RAD 7.0)
Reporter: Tim Halloran
Attachments: conlomerate.tar.gz, derby-3221.prelim.diff,
SubShape.properties
We are getting an SQLException when several prepared statement deletes are
done upon an existing database. As far as we can tell this exception should
never occur unless (evil) things like deleting the database or editing files
occurs. This is using the embedded driver within a plug-in inside RAD 7.0
(and Eclipse 3.3).
I'm not sure what else to submit that might be helpful.
java.sql.SQLException: The conglomerate (-5) requested does not exist.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
Source)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
Source)
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.executeStatement(Unknown Source)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.surelogic.sierra.jdbc.LazyPreparedStatementConnection$LazyPreparedStatement.invoke(Unknown
Source)
at $Proxy1.execute(Unknown Source)
at com.surelogic.sierra.jdbc.finding.FindingManager.delete(Unknown Source)
at
com.surelogic.sierra.jdbc.finding.ClientFindingManager.updateLocalFindings(Unknown
Source)
at
Re: Table Function Question
Frank Griffin wrote:
I've been looking into Table Functions as a way to access external data,
and I'm running into some design questions.
Briefly, I need to provide Java code which provides access to arbitrary
tables in a foreign database.
The problem I'm seeing from the docs is that it looks like Table
Functions have to be specific to the ResultSet being produced, i.e. you
have to write a specific Table Function class for each ResultSet. This
makes it difficult to write a single class which can handle multiple
virtual tables.
My intention was to provide configuration file(s) keyed on user-supplied
names so that a single Table Function class, given the name, could
initiate the foreign query associated with that name. The same files
would be used by my code which wraps Derby to inject CREATE FUNCTION
statements into Derby before allowing user access, so that the users who
coded the configuration files can refer to foreign tables by the same
names used in the configuration files.
Is there a way to do this that I'm not seeing ?
If not, would it be possible to add an optional keyword to CREATE
FUNCTION which could be passed to the Table Function to allow it to
customize its processing ? For compatibility, this could require that
the Table Function implement a new interface which provides a method to
be called to set the keyword value (much as is done for the Optimizer
logic).
Hi Frank,
I don't think you need a separate class for each foreign table. I don't
think you even need a separate method for each foreign table. At the end
of this message, I'm including some sample code which may help move this
discussion forward. The code has the following features:
1) There is one user-written class with one user-written method.
2) Each foreign query is backed by two pieces of Derby DDL:
a) A table function which declares the shape of the foreign ResultSet
b) A view which supplies the connection url and query string
This may help you. If not but if you're happy with creating a single
method per foreign query, then you may be able to use something like the
QueryRow annotation which is supplied as part of the vti demo. You can
see how to use this annotation by looking at the QueryRow vti declared
in org.apache.derbyDemo.vtis.example.VTIs The nice bit about QueryRow is
that it comes with machinery which performs the chore in step (2a).
Even if QueryRow isn't the right approach for you, you may find that you
want to clone this machinery.
Please let me know if these solutions don't address your issue. That
will help me understand your problem better.
Thanks,
-Rick
-
Here is the sample code. First, there is a simple class and method which
return query results from the foreign data source:
import java.sql.*;
public class ForeignQueryVTI
{
public static ResultSet foreignQuery( String connectionURL,
String query )
throws SQLException
{
Connection conn = DriverManager.getConnection(
connectionURL );
PreparedStatement ps = conn.prepareStatement( query );
return ps.executeQuery();
}
}
Then there is a Derby script which creates views against the foreign
data. For simplicity's sake, the foreign database in this example is
just Derby--but by changing the connectionURL and queryText arguments,
this will work against MySQL or Postgres or DB2 or Oracle...:
connect 'jdbc:derby:testDatabase;create=true';
drop view foreignTable1;
drop view foreignTable2;
drop function f1;
drop function f2;
create function f1( connectionURL varchar( 32672 ), queryText varchar(
32672 ) )
returns TABLE
(
tableID char( 36 ),
tableName varchar( 128 )
)
language java
parameter style DERBY_JDBC_RESULT_SET
reads sql data
external name 'ForeignQueryVTI.foreignQuery'
;
create view foreignTable1 as
select *
from table( f1( 'jdbc:default:connection', 'select tableID, tableName
from sys.systables' ) ) s
;
create function f2( connectionURL varchar( 32672 ), queryText varchar(
32672 ) )
returns TABLE
(
columnName varchar( 128),
columnNumber int
)
language java
parameter style DERBY_JDBC_RESULT_SET
reads sql data
external name 'ForeignQueryVTI.foreignQuery'
;
create view foreignTable2 as
select *
from table( f2( 'jdbc:default:connection', 'select columnName,
columnNumber from sys.syscolumns' ) ) s
;
select * from foreignTable1;
select * from foreignTable2;
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (11 issues) Subscriber: derby-dev Key Summary DERBY-3294 Convert demo/checkToursDB.java to junit https://issues.apache.org/jira/browse/DERBY-3294 DERBY-3298 Getting Started manual needs clearer introduction to connection URL https://issues.apache.org/jira/browse/DERBY-3298 DERBY-3254 Implement the replication failover functionality https://issues.apache.org/jira/browse/DERBY-3254 DERBY-3088 convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process https://issues.apache.org/jira/browse/DERBY-3088 DERBY-3189 Replication: Add connection url command options for starting and stopping master https://issues.apache.org/jira/browse/DERBY-3189 DERBY-3205 Replication: Add connection url command options for starting and stopping slave https://issues.apache.org/jira/browse/DERBY-3205 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-3023 Different result rows depending on the sequence of INNER JOIN and OUTER JOIN https://issues.apache.org/jira/browse/DERBY-3023 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3083 Network server demands a file called derbynet.jar in classpath https://issues.apache.org/jira/browse/DERBY-3083 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
Regression Test Report - Daily 609344 - Sun DBTG
[Auto-generated mail] *Daily* 609344/2008-01-06 18:00:15 CET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0272272 071.81% derbyall 01014610146 0 1298.44% suitesAll linN+1 0272272 098.20% derbyall 01014610146 0 108.49% suitesAll sles 0272272 071.03% derbyall 01014610146 0 893.50% suitesAll sol 0272272 075.43% derbyall 01014610146 0 1279.65% suitesAll solN+1 0272272 095.99% derbyall 01014610146 0 169.37% suitesAll sparc 0272272 066.85% derbyall 01014610146 0 356.42% suitesAll vista 0272272 0 131.06% derbyall F:3,E:29379367640 057.80% suitesAll w2003 0272272 095.54% derbyall 091249124 0 128.03% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-609344.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/609344_bySig.html *Jvm: 1.5* lin 0273273 070.87% derbyall 084308430 0 877.18% suitesAll linN+1 0273273 0 .% derbyall 084308430 0 .% suitesAll sles 0273273 069.96% derbyall 084308430 0 573.95% suitesAll sol 0273273 079.56% derbyall 084308430 0 853.61% suitesAll solN+1 0273273 087.73% derbyall 084308430 0 786.88% suitesAll sparc 0273273 066.32% derbyall 084308430 0 689.14% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 0273273 073.74% derbyall 074087408 0 256.03% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-609344.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/609344_bySig.html *Jvm: 1.4* lin 0270270 272.31% derbyall 083788378 0 795.40% suitesAll linN+1 0270270 2 .% derbyall 083788378 0 .% suitesAll sles 0270270 272.47% derbyall 083788378 0 527.11% suitesAll sol 0270270 277.70% derbyall 083788378 0 683.43% suitesAll solN+1 0270270 288.47% derbyall 083788378 0 744.37% suitesAll sparc 0270270 266.50% derbyall 083788378 0 694.95% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 0270270 2 .% derbyall 073577357 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-609344.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/609344_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/609344.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Updated: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated DERBY-3301: - Attachment: derby-3301.sql The attached patch demonstrates the problem. The expected result of the last query in the file is the 7 rows corresponding to the rows in the join table. To duplicate the problem, run ij derby-3301.sql Any suggestions are welcome. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Attachments: derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE |WEEKLYHOURS |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR |SALARY |WAGE |DISCRIMINATOR
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556654#action_12556654 ] Mamta A. Satoor commented on DERBY-3302: I tried following the instructions multiple times but can't get the npe to reproduce. This is what I tried $ java -Dij.exceptionTrace=true org.apache.derby.tools.ij ij version 10.4 ij run 'npe.sql'; ij connect 'jdbc:derby:colldb;create=true;territory=no_NO;collation=TERRITORY_BASED' as c1; ij create table t (x varchar(100) primary key); 0 rows inserted/updated/deleted ij autocommit off; ij insert into t values ''; 1 row inserted/updated/deleted ij connect 'jdbc:derby:colldb' as c2; ij(C2) insert into t values 'abab'; 1 row inserted/updated/deleted ij(C2) $ java -Dij.exceptionTrace=true org.apache.derby.tools.ij ij version 10.4 ij connect 'jdbc:derby:colldb'; ij exit; Notice that I Ctrl-C from the first session of ij. I am running this against the trunk. NullPointerException during recovery of database with territory-based collation --- Key: DERBY-3302 URL: https://issues.apache.org/jira/browse/DERBY-3302 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Attachments: npe.sql When logical undo is performed on a database with territory-based collation, you may get a NullPointerException in SQLChar.getCollationKey() because SQLChar.getLocaleFinder() returns null. This bug was reported on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3294) Convert demo/checkToursDB.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjula Kutty updated DERBY-3294: - Attachment: DERBY_3294_diff_1_7.txt DERBY_3294_stat_1_7.txt Thanks John for the review. Here is the modified patch. Please review and commit. Convert demo/checkToursDB.java to junit --- Key: DERBY-3294 URL: https://issues.apache.org/jira/browse/DERBY-3294 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.4.0.0 Reporter: Manjula Kutty Assignee: Manjula Kutty Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3294_diff_12_28.txt, DERBY-3294_stat_12_28.txt, DERBY_3294_diff_01_02.txt, DERBY_3294_diff_1_4.txt, DERBY_3294_diff_1_7.txt, DERBY_3294_stat_01_02.txt, DERBY_3294_stat_1_4.txt, DERBY_3294_stat_1_7.txt Place holder for the junit conversion of demo/checkToursDB.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3294) Convert demo/checkToursDB.java to junit
[ https://issues.apache.org/jira/browse/DERBY-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556678#action_12556678 ] Myrna van Lunteren commented on DERBY-3294: --- I'm looking at committing this - and on the whole it looks good. However, I wonder why the method insertMaps was introduced. Was it not possible to use the insertMaps.main() method like the original test does? I think it should... The point of this test is to ensure that the toursDB created during compile is correct/working. Using the toursdb created would be one way to do this. The original test took another approach, and worked with the files in the demo directory (the .sql files get copied to the built functionTests dir from the java/demo source), mimicking the toursdb creation during the build using the identical files as the build. Using insertMaps.main() as the original test does, is identical to what happens to populate the MAPS table in the toursDB database during the build process. (The java/demo/toursdb.build.xml does an ant java call to insertMaps, which executes the main method). However, in the conversion now, you've duplicated the code, rather than actually using the available class, and thus, you're not actually testing the code... Convert demo/checkToursDB.java to junit --- Key: DERBY-3294 URL: https://issues.apache.org/jira/browse/DERBY-3294 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.4.0.0 Reporter: Manjula Kutty Assignee: Manjula Kutty Priority: Minor Fix For: 10.4.0.0 Attachments: DERBY-3294_diff_12_28.txt, DERBY-3294_stat_12_28.txt, DERBY_3294_diff_01_02.txt, DERBY_3294_diff_1_4.txt, DERBY_3294_diff_1_7.txt, DERBY_3294_stat_01_02.txt, DERBY_3294_stat_1_4.txt, DERBY_3294_stat_1_7.txt Place holder for the junit conversion of demo/checkToursDB.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556679#action_12556679 ] Kristian Waagan commented on DERBY-3302: Hello Mamta, I tried the repro as well, and I see varying results. Sometimes it works, sometimes it doesn't when I press CTRL-C using Cygwin on Windows XP. I don't know which mechanism is kicking in with CTRL-C, but the repro works every time if I kill ij with the task manager. You can have a look at the timestamps of the log files to check if Derby was able to write something before exiting. hth, NullPointerException during recovery of database with territory-based collation --- Key: DERBY-3302 URL: https://issues.apache.org/jira/browse/DERBY-3302 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Attachments: npe.sql When logical undo is performed on a database with territory-based collation, you may get a NullPointerException in SQLChar.getCollationKey() because SQLChar.getLocaleFinder() returns null. This bug was reported on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556698#action_12556698 ] Mamta A. Satoor commented on DERBY-3302: Thanks, Kristian. crashing ij through task manager did the trick. I get the NPE now. NullPointerException during recovery of database with territory-based collation --- Key: DERBY-3302 URL: https://issues.apache.org/jira/browse/DERBY-3302 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Attachments: npe.sql When logical undo is performed on a database with territory-based collation, you may get a NullPointerException in SQLChar.getCollationKey() because SQLChar.getLocaleFinder() returns null. This bug was reported on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
DERBY-2636/DERBY-3068
Hi, I see fairly regular failures caused by a failure in cleaning up extinout/t1.dat in the nightly tests run at IBM, see for example: http://people.apache.org/~fuzzylogic/derby_test_results/main/derbymain/testSummary-609084.html I am wondering if anyone has any suggestions on how to debug or even solve these...? Thx, Myrna
[jira] Updated: (DERBY-3149) Add ant targets for building and running the package private tests against the classes directories
[
https://issues.apache.org/jira/browse/DERBY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3149:
--
Attachment: pptesting_use_jdk16_executable_diff.txt
I would like to make a small change to the build.xml file to use the jdk16
executable to build the pptesting target. It currently uses the default javac
to compile against ${java16compile.classpath}. This can cause problems when jdk
1.5 is the default javac and ${java16compile.classpath} is set to IBM 1.6
See attached patch pptesting_use_jdk16_executable_diff.txt
Add ant targets for building and running the package private tests against
the classes directories
--
Key: DERBY-3149
URL: https://issues.apache.org/jira/browse/DERBY-3149
Project: Derby
Issue Type: Sub-task
Components: Build tools, Test
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
Fix For: 10.4.0.0
Attachments: derby-3149-1a.diff, derby-3149-1a.stat,
derby-3149-1b.diff, derby-3149-2a-conditional_compilation_fix.diff,
derby-3149-2b-conditional_compilation_fix.diff,
pptesting_use_jdk16_executable_diff.txt
Create ant targets in build.xml to compile and run the package private tests.
The first step will be to run the tests against the classes directories.
Implementing a solution that runs against jars is not technically difficult,
it just brings a host of decisions to be taken... Maybe even more important,
does running against the jars add any value?
The compile will be included in the 'all' target to test the implementation.
Feel free to post your concerns if you think building the package private
tests should be a manual action only.
The tests will also be run as part of junit-all / junitreport.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2254) Assert during log file switch: log file position exceeded max log file size
[ https://issues.apache.org/jira/browse/DERBY-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-2254: -- Deleting the log file is the easiest way to guarantee corruption in the derby database. It is impossible to know what kind of corruption might have happened but all the following are possible, because derby rely's on the info in the log file to maintain consistent data. Because of in memory database caching the database files on disk may be severely out of date/inconsistent without proper recovery processing using the log files. All the following corruptions are possible when one deletes one or more log files: transaction inconsistent data between tables - many of these inconsistencies can't be determined by derby inconsistent data between base tables and indexes - running the consistency checker does a good job of checking for this inconsistent data in long rows - a long row may stretch across many pages and the links depend on tranactional consistency if this is broken a number of runtime errors may occur inconsistent data in long columns - similar to long row a single column may be linked across many pages and this consistency is maintained by the transaction log. If it is ever necessary to remove the log because of some derby bug the only safe thing to do is to go back to your more recent backup. If you don't have one, what I usually tell users is to assume the db they are accessing is corrupt but accessible. The only safe thing at that point is to data mine the existing db to copy whatever data looks good out to a file and then load it into a newly created db. Otherwise one will never know if future errors you encounter in the db are because of this failed recovery. Assert during log file switch: log file position exceeded max log file size --- Key: DERBY-2254 URL: https://issues.apache.org/jira/browse/DERBY-2254 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4 Environment: Solaris 10, Java SE 6 build 104 Reporter: Olav Sandstaa When running simple tpc-b like transactions against a embedded Derby based on a SANE build of trunk the following assertion occurs for the background thread and all user threads: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size This seems to occur during a switch to a new log file. derby.log contains the following call stack for the background thread: Exception trace: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(LogToFile.java:1357) at org.apache.derby.impl.store.raw.RawStore.checkpoint(RawStore.java:439) at org.apache.derby.impl.store.raw.log.LogToFile.performWork(LogToFile.java:3416) at org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(BasicDaemon.java:331) at org.apache.derby.impl.services.daemon.BasicDaemon.work(BasicDaemon.java:668) at org.apache.derby.impl.services.daemon.BasicDaemon.run(BasicDaemon.java:394) at java.lang.Thread.run(Thread.java:619) 2007-01-17 23:09:48.638 GMT Thread[derby.rawStoreDaemon,5,derby.daemons] Cleanup action starting org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED log file position exceeded max log file size at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.store.raw.log.LogCounter.makeLogInstantAsLong(LogCounter.java:120) at org.apache.derby.impl.store.raw.log.LogToFile.switchLogFile(LogToFile.java:1900) at org.apache.derby.impl.store.raw.log.LogToFile.appendLogRecord(LogToFile.java:3530) at org.apache.derby.impl.store.raw.log.FileLogger.logAndDo(FileLogger.java:345) at org.apache.derby.impl.store.raw.xact.Xact.logAndDo(Xact.java:1185) at org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(LogToFile.java:1540) at
[jira] Commented: (DERBY-3149) Add ant targets for building and running the package private tests against the classes directories
[ https://issues.apache.org/jira/browse/DERBY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556746#action_12556746 ] Kristian Waagan commented on DERBY-3149: Kathey, I do not mind the change you have proposed, I just want to make clear that what the target really needs is to compile against the Java SE 5.0 libraries. There is no need for JDK 1.6, but as far as I know there is no java15compile.classpath, and compile.classpath is set to J2SE 1.4.2. +1 to commit, unless someone knows how to get Java SE 5.0 libraries. If committed, I assume the target will revert back to Java SE 5.0 when the infrastructure is in place. Add ant targets for building and running the package private tests against the classes directories -- Key: DERBY-3149 URL: https://issues.apache.org/jira/browse/DERBY-3149 Project: Derby Issue Type: Sub-task Components: Build tools, Test Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3149-1a.diff, derby-3149-1a.stat, derby-3149-1b.diff, derby-3149-2a-conditional_compilation_fix.diff, derby-3149-2b-conditional_compilation_fix.diff, pptesting_use_jdk16_executable_diff.txt Create ant targets in build.xml to compile and run the package private tests. The first step will be to run the tests against the classes directories. Implementing a solution that runs against jars is not technically difficult, it just brings a host of decisions to be taken... Maybe even more important, does running against the jars add any value? The compile will be included in the 'all' target to test the implementation. Feel free to post your concerns if you think building the package private tests should be a manual action only. The tests will also be run as part of junit-all / junitreport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1368) EOFException when reading from blob's binary stream
[
https://issues.apache.org/jira/browse/DERBY-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-1368:
--
Attachment: derby-1368_diff2.txt
Kristian asked ..
a) Is the test all about getting the stream and the length twice? If so, maybe
the JavaDoc could say this.
I went back to 10.1 and tested the repro, it does in fact require you get the
stream and length twice. Added this to the javadoc, but I am not actually sure
if this is a legal operation.
b) Would it add any value to the test if we drained the stream before
getting the stream the second time?
I don't know if it adds value but I added the draining of the stream.
c) Would it make sense to also run this with the JDBC-method taking a length
argument?
added this.
See new patch derby-1368_diff2.txt
EOFException when reading from blob's binary stream
---
Key: DERBY-1368
URL: https://issues.apache.org/jira/browse/DERBY-1368
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.1.2.1
Reporter: Tobias Bocanegra
Assignee: Kathey Marsden
Attachments: derby-1368_diff.txt, derby-1368_diff2.txt, Derby1368.java
reading the 'length()' of a blob reads a previously aquired binary stream.
test case:
public static void main(String[] argv) throws Exception {
String driver = org.apache.derby.jdbc.EmbeddedDriver;
String url = jdbc:derby:derby/test;create=true;
Class.forName(driver);
Connection con = DriverManager.getConnection(url, sa, );
con.setAutoCommit(true);
// create table
System.out.println(1) creating table...);
Statement stmt = con.createStatement();
stmt.execute(create table T1 (ID char(32) PRIMARY KEY, DATA blob(2G)
not null));
stmt.close();
// add row
System.out.println(2) adding row...);
byte[] data = new byte[1024*1024*1];
data[0] = 1;
data[1] = 2;
PreparedStatement s = con.prepareStatement(insert into T1 (ID, DATA)
values (?, ?));
s.setString(1, id);
s.setBytes(2, data);
s.execute();
s.close();
// read row
System.out.println(3) reading row...);
s = con.prepareStatement(select DATA from T1 where ID = ?);
s.setString(1, id);
s.execute();
ResultSet rs = s.getResultSet();
rs.next();
Blob b = rs.getBlob(1);
// test output
System.out.println(4) Length: + b.length());
InputStream in = b.getBinaryStream();
System.out.println( First Byte: + in.read());
in.close();
in = b.getBinaryStream();
System.out.println(5) Length: + b.length());
System.out.println( First Byte: + in.read());
in.close();
rs.close();
s.close();
con.close();
}
gives:
1) creating table...
2) adding row...
3) reading row...
4) Length: 1048576
First Byte: 1
5) Length: 1048576
First Byte: -1
imo, 5) is wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3288) wrong query result in presence of a unique index
[ https://issues.apache.org/jira/browse/DERBY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton reassigned DERBY-3288: -- Assignee: A B Hi Army, thanks for looking at this issue (I marked it as assigned to you). Your assessment makes complete sense to me; thanks for writing the issues up so clearly and completely! Two questions occurred to me as I read your writeup: 1) Why is it that TAB_D is dependent on HOJ but TAB_V is not? Both of the exists subqueries look very similar to me; they each seem to be correlated to TAB_B in the HOJ, and isn't that where the dependency arises? It isn't really directly relevant to the bug, I was just hoping you could educate me on why the one subquery was dependent on the B-C-A join but the other wasn't. 2) The way I read your patch, you basically caused steps (3) and (4) to be done as part of step (1b), which makes complete sense to me. But it surprised me a bit that you didn't seem to *move* that code; rather you inserted *new* code into step (1b). That is, it now seems like there are multiple places in OptimizerImpl.getNextPermutation() which all seem to be doing the same thing: - your new code to be inserted at line 589 or so - The hunk of code at line 809 or so, starting with the comment We are going to try an optimizable at the current join order position - The hunk of code at line 1093 or so, starting with the comment Clear the assigned table map I'm afraid I don't really have a very clear comment to make here; I'm just observing that getNextPermutation() appears to compute the pullMe optimizable twice, and in one case it clears the assignedTableMap bits but in the other it doesn't, and your patch adds a 3rd place where we compute the pullMe optimizable (and clear the assignedTableMap bits). Perhaps this question puts my finger most closely on my confusion: Why don't we need to clear the assigned table map bits at line 809? wrong query result in presence of a unique index Key: DERBY-3288 URL: https://issues.apache.org/jira/browse/DERBY-3288 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Gerald Khin Assignee: A B Attachments: d3288_incomplete_v1.patch, DERBY-3288.htm The DDL to reproduce the bug is: CREATE TABLE tab_a (PId BIGINT NOT NULL); CREATE TABLE tab_c (Id BIGINT NOT NULL PRIMARY KEY, PAId BIGINT NOT NULL, PBId BIGINT NOT NULL); INSERT INTO tab_c VALUES (91, 81, 82); INSERT INTO tab_c VALUES (92, 81, 84); INSERT INTO tab_c VALUES (93, 81, 88); INSERT INTO tab_c VALUES (96, 81, 83); CREATE TABLE tab_v (OId BIGINT NOT NULL , UGId BIGINT NOT NULL, val CHAR(1) NOT NULL); CREATE UNIQUE INDEX tab_v_i1 ON tab_v (OId, UGId, val); CREATE INDEX tab_v_i2 ON tab_v (UGId, val, OId); INSERT INTO tab_v VALUES (81, 31, 'A'); INSERT INTO tab_v VALUES (82, 31, 'A'); INSERT INTO tab_v VALUES (83, 31, 'A'); INSERT INTO tab_v VALUES (84, 31, 'A'); INSERT INTO tab_v VALUES (85, 31, 'A'); INSERT INTO tab_v VALUES (86, 31, 'A'); INSERT INTO tab_v VALUES (87, 31, 'A'); INSERT INTO tab_v VALUES (81, 32, 'A'); INSERT INTO tab_v VALUES (82, 32, 'A'); INSERT INTO tab_v VALUES (83, 32, 'A'); INSERT INTO tab_v VALUES (84, 32, 'A'); INSERT INTO tab_v VALUES (85, 32, 'A'); INSERT INTO tab_v VALUES (86, 32, 'A'); INSERT INTO tab_v VALUES (87, 32, 'A'); CREATE TABLE tab_b (Id BIGINT NOT NULL PRIMARY KEY, OId BIGINT NOT NULL); INSERT INTO tab_b VALUES (141, 81); INSERT INTO tab_b VALUES (142, 82); INSERT INTO tab_b VALUES (143, 84); INSERT INTO tab_b VALUES (144, 88); INSERT INTO tab_b VALUES (151, 81); INSERT INTO tab_b VALUES (152, 83); CREATE TABLE tab_d (Id BIGINT NOT NULL PRIMARY KEY, PAId BIGINT NOT NULL, PBId BIGINT NOT NULL); INSERT INTO tab_d VALUES (181, 141, 142); INSERT INTO tab_d VALUES (182, 141, 143); INSERT INTO tab_d VALUES (186, 151, 152); The query returning the wrong result is: SELECT tab_b.Id FROM tab_b JOIN tab_c ON (tab_b.OId = tab_c.PAId OR tab_b.OId = tab_c.PBId) LEFT OUTER JOIN tab_a ON tab_b.OId = PId WHERE EXISTS (SELECT 'X' FROM tab_d WHERE (PAId = 141 AND PBId = tab_b.Id) OR (PBId = 141 AND PAId = tab_b.Id)) AND EXISTS (SELECT 'X' FROM tab_v WHERE OId = tab_b.OId AND UGId = 31 AND val = 'A') The result should consist of two rows (142),(143), but it returns only one row (142). The correct result would be returned if the index tab_v_i1 had been created as non-unique. The correct result would also be returned if the condition ...AND val='A' had been replaced by ...AND val='A' || ''. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3288) wrong query result in presence of a unique index
[
https://issues.apache.org/jira/browse/DERBY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12556789#action_12556789
]
A B commented on DERBY-3288:
Thanks for the great questions, Bryan.
1) Why is it that TAB_D is dependent on HOJ but TAB_V is not?
I admit I don't know. The process of flattening EXISTS subqueries into
specialized FromBaseTables that are called existsBaseTables is one I have not
investigated. I know it happens, and I know that an exist base table is one
of the primary reasons that dependencies exist, at least according to the
comment in FromBaseTable.legalJoinOrder():
public boolean legalJoinOrder(JBitSet assignedTableMap)
{
// Only an issue for EXISTS FBTs
if (existsBaseTable)
{
/* Have all of our dependencies been satisfied? */
return assignedTableMap.contains(dependencyMap);
}
return true;
}
As you say, it seems like the two EXISTS subqueries are pretty similar, but I
do not know what is it that causes a dependency on TAB_D only. I haven't spent
time in that particular piece of the code...
2) [...] It surprised me a bit that you didn't seem to *move* that
code; rather you inserted *new* code into step (1b).
I agree with you on this. I was originally thinking to reorg the code a bit,
but then I just wanted to see if I was on track by making the quick fix and
checking the results. It solved the reported problem so I posted it; but yes,
the patch is incomplete and a more formal reorganization of the relevant
methods would be a good idea. I don't know how much time I'll have to look at
this over the next many days, so I just did a quick drop posting of what I
found--which is one of the reasons I hadn't officially assigned myself to the
issue :) But you bring up a good point.
Why don't we need to clear the assigned table map bits at line 809?
I don't think this is necessary because the other pullMe code (line 1093) will
eventually (in a round-a-bout way) clean up after the missing clear assigned
table map from 809--at least in most cases. But adding the appropriate code
to line 809 may fix this bug and render the other use unnecessary, as well. If
that's true then that would probably be the best final approach.
And of course, there's still the SpaceTable.sql issue to investigate...
wrong query result in presence of a unique index
Key: DERBY-3288
URL: https://issues.apache.org/jira/browse/DERBY-3288
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Gerald Khin
Assignee: A B
Attachments: d3288_incomplete_v1.patch, DERBY-3288.htm
The DDL to reproduce the bug is:
CREATE TABLE tab_a (PId BIGINT NOT NULL);
CREATE TABLE tab_c (Id BIGINT NOT NULL PRIMARY KEY, PAId BIGINT NOT NULL,
PBId BIGINT NOT NULL);
INSERT INTO tab_c VALUES (91, 81, 82);
INSERT INTO tab_c VALUES (92, 81, 84);
INSERT INTO tab_c VALUES (93, 81, 88);
INSERT INTO tab_c VALUES (96, 81, 83);
CREATE TABLE tab_v (OId BIGINT NOT NULL , UGId BIGINT NOT NULL, val CHAR(1)
NOT NULL);
CREATE UNIQUE INDEX tab_v_i1 ON tab_v (OId, UGId, val);
CREATE INDEX tab_v_i2 ON tab_v (UGId, val, OId);
INSERT INTO tab_v VALUES (81, 31, 'A');
INSERT INTO tab_v VALUES (82, 31, 'A');
INSERT INTO tab_v VALUES (83, 31, 'A');
INSERT INTO tab_v VALUES (84, 31, 'A');
INSERT INTO tab_v VALUES (85, 31, 'A');
INSERT INTO tab_v VALUES (86, 31, 'A');
INSERT INTO tab_v VALUES (87, 31, 'A');
INSERT INTO tab_v VALUES (81, 32, 'A');
INSERT INTO tab_v VALUES (82, 32, 'A');
INSERT INTO tab_v VALUES (83, 32, 'A');
INSERT INTO tab_v VALUES (84, 32, 'A');
INSERT INTO tab_v VALUES (85, 32, 'A');
INSERT INTO tab_v VALUES (86, 32, 'A');
INSERT INTO tab_v VALUES (87, 32, 'A');
CREATE TABLE tab_b (Id BIGINT NOT NULL PRIMARY KEY, OId BIGINT NOT NULL);
INSERT INTO tab_b VALUES (141, 81);
INSERT INTO tab_b VALUES (142, 82);
INSERT INTO tab_b VALUES (143, 84);
INSERT INTO tab_b VALUES (144, 88);
INSERT INTO tab_b VALUES (151, 81);
INSERT INTO tab_b VALUES (152, 83);
CREATE TABLE tab_d (Id BIGINT NOT NULL PRIMARY KEY, PAId BIGINT NOT NULL,
PBId BIGINT NOT NULL);
INSERT INTO tab_d VALUES (181, 141, 142);
INSERT INTO tab_d VALUES (182, 141, 143);
INSERT INTO tab_d VALUES (186, 151, 152);
The query returning the wrong result is:
SELECT tab_b.Id
FROM tab_b JOIN tab_c ON (tab_b.OId = tab_c.PAId OR tab_b.OId = tab_c.PBId)
LEFT OUTER JOIN tab_a ON tab_b.OId = PId
WHERE EXISTS (SELECT 'X' FROM tab_d WHERE (PAId = 141 AND PBId = tab_b.Id) OR
(PBId = 141 AND PAId = tab_b.Id))
AND EXISTS (SELECT 'X' FROM tab_v WHERE OId = tab_b.OId AND UGId = 31 AND
val = 'A')
The result should consist of two rows
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3184: - Attachment: derby-3184-2a.diff derby-3184-2a.stat The attached patch, v2a, adds a new implementation of Database to Derby. The new implementation is called SlaveDatabase and is booted if startSlave=true is specified in the connection url. The following files are modified: A java/engine/org/apache/derby/impl/db/SlaveDatabase.java M java/engine/org/apache/derby/modules.properties The new Database implementation SlaveDatabase to Derby. M java/engine/org/apache/derby/impl/db/BasicDatabase.java Removed the old if (inReplicationSlaveMode) throw exception code. This is now handled in SlaveDatabase. M java/engine/org/apache/derby/impl/store/raw/log/LogToFile.java Adds slave replication pre mode M java/engine/org/apache/derby/iapi/services/replication/slave/SlaveFactory.java Minor changes Testing: * all tests passed * I have also run all the junit tests on a setup where SlaveDatabase was hardcoded to be used instead of BasicDatabase. This works [1], indicating that the new implementation works *after* the database has left slave mode (i.e., after the failover command has been run) [1] Some encryption tests fail because they expect an exception to be thrown (from the rawstore module). Since the store modules of SlaveDatabase are booted in a separate thread, these exceptions are only reported in derby.log, not reported to the caller of connect '...'. However, when SlaveDatabase in not hardcoded to be used, this can only happen when dataEncryption=true and startSlave=true are specified at the same time. This combination will not be allowed. Replication: Connection attempts to a database in slave mode must fail -- Key: DERBY-3184 URL: https://issues.apache.org/jira/browse/DERBY-3184 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat When a database 'X' is booted in slave mode, the call to Monitor.startPersistentService(X,...) will not complete because the call gets stuck in LogToFile#recover. This is intentional. For as long as startPersistentService is blocked, however, other threads that try to connect to 'X' (effectively calling Monitor.findService(X, ...)) will also hang. This is unacceptable, and needs to raise an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3184: - Derby Info: [Patch Available] Replication: Connection attempts to a database in slave mode must fail -- Key: DERBY-3184 URL: https://issues.apache.org/jira/browse/DERBY-3184 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat When a database 'X' is booted in slave mode, the call to Monitor.startPersistentService(X,...) will not complete because the call gets stuck in LogToFile#recover. This is intentional. For as long as startPersistentService is blocked, however, other threads that try to connect to 'X' (effectively calling Monitor.findService(X, ...)) will also hang. This is unacceptable, and needs to raise an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
