[jira] Updated: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1330?page=all ] Mamta A. Satoor updated DERBY-1330: --- Attachment: Derby1330uuidIndexForPermsSystemTablesV4diff.txt Derby1330uuidIndexForPermsSystemTablesV4stat.txt The patch Derby1330PrivilegeCollectionV3diff.txt attached to this JIRA entry was recently committed into main trunk. I am working on revoke privilege which is based on that committed patch. While working on revoke privilege, I realized that I have incorrect logic for getting a permission descriptor from system tables based on the unique uuid. SYSTABLEPERMS, SYSCOLPERMS and SYSROUTINEPERMS each have a uuid column called TABLEPERMSID, COLPERMSID and ROUTINEPERMSID respectively. When a view\constraint\trigger is found to be dependent on a permission, we have the dependency manager track view\constraint\trigger's dependency on that permission's unique uuid. Later on, that unique uuid can be used to get the unique row from the system tables. The patch Derby1330PrivilegeCollectionV3diff.txt accidentally looked for combination of unique uuid and permission type to find the exact unique row from the system tables. The uuid column is sufficient to find the unique row form these 3 system tables and there is no need to keep track of permission type. I have attached a patch (Derby1330uuidIndexForPermsSystemTablesV4diff.txt) to fix that behavior. The patch gets rid of requirement of permission type along with the uuid to find a unique row. Fixing this has in fact cleaned up the supporting code quite a bit. For instance, there is no need for special class DDColumnPermissionDependableFinder or no need for a constructor in ColPermsDescriptor which takes permission types in the form of an int. DDdependableFinder is much cleaner too with this patch. In addition, I have also created a unique index on the uuid for these 3 system tables in order to quickly locate a row in those system tables. svn stat -q output is attached as Derby1330uuidIndexForPermsSystemTablesV4stat.txt Can someone please review this patch for me and submit it to the trunk if everything looks good? The grantRevokeDDL.sql test is ran fine and I have fired derbyall. Provide runtime privilege checking for grant/revoke functionality - Key: DERBY-1330 URL: http://issues.apache.org/jira/browse/DERBY-1330 Project: Derby Type: Sub-task Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt Additional work needs to be done for grant/revoke to make sure that only users with required privileges can access various database objects. In order to do that, first we need to collect the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM. Once we have this information then when a user tries to access an object, the required SYS.SYSREQUIREDPERM privileges for the object will be checked against the user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. The database object access will succeed only if the user has the necessary privileges. SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point and hence no runtime privilege checking is getting done at this point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
Mike Matrigali [EMAIL PROTECTED] writes: Mamta A. Satoor (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420145 ] Mamta A. Satoor commented on DERBY-1330: Mike responded following on the mailing list quote I do not believe you can count on the order of a HashMap, different JVM's may use different hash algo's which may result in different orders when you ask for the full list. I have seen this behavior in queries which use hash nodes in derby (I believe we first noticed a difference between j9 and other jvm's). In that case we added order by's as necessary to the tests, as either order of results was correct from SQL point of view. In your case is the order a code problem, or just a testing issue? /quote First of all, thanks Mike for your response. As to your question, the order is not a testing issue because test is simply trying a scenario where a user is trying to create a object based on more than one object on which the user doesn't have access to. And depending on how items got into HashMap, the test fails with privilege error on one object vs the other. So, in this case, the order is a code problem. If the order of the error is not documented, then I am not sure it is a code error. Sort of similar to the fact that on different jvm's derby will return rows in different orders for the same db, same query (unless a specific order by is used). I would define it as a test problem, as the test assumes a specific error where either of 2 errors is valid. I agree. Since the SQL state is equal in the two cases, I think a sed script that strips everything but the message would be OK. Something like this in grantRevokeDDL_sed.properties: substitute=^ERROR ([^:]*):.*$;ERROR: Failed with SQLSTATE $1 The code could use some sorting mechanism to guarantee an ordering, but it would have to be careful about the key (object id's could also vary from machine to machine, or time to time). Doing so would likely mean more memory and more code, doesn't seem worth it to me for this case - anyone think so? Perhaps a LinkedHashMap would do the trick, but I agree, I don't think it's worth it. -- Knut Anders
[jira] Updated: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql
[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ] Mike Matrigali updated DERBY-1248: -- After looking at the test5.zip, I believe I understand what is going on. The original database has a single log file file: log1.dat. It's last record is (1,285606), while in the backup the last log record is (1,279540). So the missing log records are all in the last block of the log file. I think the problem is that the online backup reads page through the cache, rather than from disk so it is picking up dirty pages where the associated log records have not yet been flushed to disk. The backup of the log file on the other hand goes directly from disk and thus sometimes in this concurrent test misses some of the log records in the unflushed part of the log file. In this test most of the concurrent work is actually post commit committed delete cleanup which happens to use no-sync commit, thus the only flushes coming are either from filling a block or from the backup itself. I believe the fix is easy, just have the backup flush the log file after it has backed up all the data, and before backing up the remaining log files at the end. I spent some time trying to get a more reproducible case but haven't gotten anywhere there. It makes sense that it is more likely on multiprocessors where the backup and other threads can be running at same time. Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql - Key: DERBY-1248 URL: http://issues.apache.org/jira/browse/DERBY-1248 Project: Derby Type: Bug Components: Store, Regression Test Failure Versions: 10.2.0.0 Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision 396285). Sane build. Reporter: Knut Anders Hatlen Attachments: derby_335.log, linuxfailure.zip, solaris-singlecpu.zip, solarisfailure.zip, storemore.zip, test2_379.jar, test335.jar, test5.zip I saw this error when I ran derbyall. * Diff file derbyall/storeall/storemore/onlineBackupTest4.diff *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:50 *** 68 del ij(CONNECTION1) select * from ctest; 69 del ID |NAME 70 del 71 del 1 |derby backup/compress test 72 del 2 |derby backup/compress test 73 del 300|derby backup/compress test 74 del 509|derby backup/compress test 75 del 510|derby backup/compress test 76 del 511|derby backup/compress test 77 del 512|derby backup/compress test 78 del ij(CONNECTION1) insert into ctest values(2000, 'restore was successfil') ; 79 del 1 row inserted/updated/deleted 80 del ij(CONNECTION1) 80 add org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2 ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2: org.apache.derby.shared.common.sanity.AssertFailure'. ij select * from ctest; IJ ERROR: Unable to establish connection ij insert into ctest values(2000, 'restore was successfil') ; IJ ERROR: Unable to establish connection ij Test Failed. *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:56 *** The test usually succeeds, but I managed to reproduce the failure by running this loop in the shell: touch onlineBackupTest4.pass while [ -f onlineBackupTest4.pass ]; do rm onlineBackupTest4.pass java org.apache.derbyTesting.functionTests.harness.RunTest store/onlineBackupTest4.sql done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Assigned: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql
[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ] Mike Matrigali reassigned DERBY-1248: - Assign To: Mike Matrigali Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql - Key: DERBY-1248 URL: http://issues.apache.org/jira/browse/DERBY-1248 Project: Derby Type: Bug Components: Store, Regression Test Failure Versions: 10.2.0.0 Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision 396285). Sane build. Reporter: Knut Anders Hatlen Assignee: Mike Matrigali Attachments: derby_335.log, linuxfailure.zip, solaris-singlecpu.zip, solarisfailure.zip, storemore.zip, test2_379.jar, test335.jar, test5.zip I saw this error when I ran derbyall. * Diff file derbyall/storeall/storemore/onlineBackupTest4.diff *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:50 *** 68 del ij(CONNECTION1) select * from ctest; 69 del ID |NAME 70 del 71 del 1 |derby backup/compress test 72 del 2 |derby backup/compress test 73 del 300|derby backup/compress test 74 del 509|derby backup/compress test 75 del 510|derby backup/compress test 76 del 511|derby backup/compress test 77 del 512|derby backup/compress test 78 del ij(CONNECTION1) insert into ctest values(2000, 'restore was successfil') ; 79 del 1 row inserted/updated/deleted 80 del ij(CONNECTION1) 80 add org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2 ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2: org.apache.derby.shared.common.sanity.AssertFailure'. ij select * from ctest; IJ ERROR: Unable to establish connection ij insert into ctest values(2000, 'restore was successfil') ; IJ ERROR: Unable to establish connection ij Test Failed. *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:56 *** The test usually succeeds, but I managed to reproduce the failure by running this loop in the shell: touch onlineBackupTest4.pass while [ -f onlineBackupTest4.pass ]; do rm onlineBackupTest4.pass java org.apache.derbyTesting.functionTests.harness.RunTest store/onlineBackupTest4.sql done -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - Derby 420592 - Sun DBTG
[Auto-generated mail] *Derby* 420592/2006-07-10 19:46:15 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 3717714 0 105.29% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-420592.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/420592.html *Jvm: 1.5* NA NA NANA CYGWIN_NT-5.1_i686-unknown 2675673 2 115.30% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 1675674 2 105.47% Linux-2.6.9-34.ELsmp_x86_64-x86_64 4675671 2 176.72% SunOS-5.10_i86pc-i386 NA NA NANA SunOS-5.10_sun4u-sparc NA NA NANA SunOS-5.11_i86pc-i386 NA NA NANA SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-420592.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/420592.html *Jvm: 1.4* NA NA NANA CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0669669 4 105.85% Linux-2.6.9-34.ELsmp_x86_64-x86_64 3669666 4 206.73% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-420592.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/420592.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/420592.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: Language based matching
aa as one letter was removed from the Norwegian language in 1938 (å had been optional since 1917). It is only used in names today and it is true what Anders says about the phonebook (also about the foreign names where aa is treated like two letters). I don't think it would be wise to not let a.* match Aasen (wich in modern writing would be Åsen). Knut Anders Hatlen wrote: Kathey Marsden [EMAIL PROTECTED] writes: Does anyone know of an easy built in Java mechanism for Locale sensitive matching? I continue to work with a user trying to develop a strategy for language based string type handling in Derby 10.1. The ordering seems doable with the approach in http://wiki.apache.org/db-derby/LanguageBasedOrdering For , =. comparisons I was able to implement a LOCALE_COMPARE function pretty easily using Collators as well, but matching (LIKE replacement) seems harder.For example in Norwegian we need to have aa be treated as one character and in the US have it treated as two. So given the values acorn, aacorn, and aass ( a Norwegian brewery) , and matching a.*, we should see three rows in english and just one in Norwegian. [snip] Hi Kathey, It is true that in a Norwegian phone book, Wanvik is listed before Waagan. However, Haas (which is not a Norwegian name) would be listed before Hatlen. Likewise, geographical names from other countries could have aa which should be treated as two characters in Norwegian (Saarland, Saarbrücken, Haag). Also, you could have composite words like pizzaauksjon (pizza auction - whatever that is) which would be listed before pizzabakar (pizza baker) in a dictionary. You could also have words where the stem ends with an a and the ending starts with an a, like dataa which consists of data (same word as in English) and a (definite article, plural, neuter). It is not possible to decide how aa should be treated without knowing the context, so in general I think it is best if Derby just treats aa as two characters and lets the application do the magic if magic is required. But, as many others have said, IANAL... (I Am Not A Linguist) -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: OpenPGP digital signature
[jira] Updated: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
[ http://issues.apache.org/jira/browse/DERBY-1497?page=all ]
Andreas Korneliussen updated DERBY-1497:
Attachment: DERBY-1497.diff
The attached patch fixes the problem by not providning the error object as
parameter to message.
assert failure in MessageUtil, because exception thrown with too many
parameters when handling OutOfMemoryError
---
Key: DERBY-1497
URL: http://issues.apache.org/jira/browse/DERBY-1497
Project: Derby
Type: Sub-task
Components: Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Trivial
Attachments: DERBY-1497.diff
If the VM throws a OutOfMemoryException, which is caught in:
NetStatementReply.copyEXTDTA:
protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException
{
try {
parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
byte[] data = null;
if (longValueForDecryption_ == null) {
data = (getData(null)).toByteArray();
} else {
data = longValueForDecryption_;
dssLength_ = 0;
longValueForDecryption_ = null;
}
netCursor.extdtaData_.add(data);
} catch (java.lang.OutOfMemoryError e) { --- outofmemory
agent_.accumulateChainBreakingReadExceptionAndThrow(new
DisconnectException(agent_,
new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
e)); - message does not take parameters, causing assert
failure
}
}
Instead of getting the message: java.sql.SQLException: Attempt to fully
materialize lob data that is too large for the JVM. The connection has been
terminated.
I am getting an assert:
Exception in thread main
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of
parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1498) avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams
avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams --- Key: DERBY-1498 URL: http://issues.apache.org/jira/browse/DERBY-1498 Project: Derby Type: Sub-task Components: Network Server Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assigned to: Andreas Korneliussen Priority: Trivial In DRDAConnThread.readAndSetExtParams(..) all the bytes of a LOB is concatenated to a string and traced, when running in debug mode: This makes it harder to debug OutOfMemory errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1498) avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams
[ http://issues.apache.org/jira/browse/DERBY-1498?page=all ] Andreas Korneliussen updated DERBY-1498: Attachment: DERBY-1498.diff Attached is a patch which instead logs the length of the byte array. avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams --- Key: DERBY-1498 URL: http://issues.apache.org/jira/browse/DERBY-1498 Project: Derby Type: Sub-task Components: Network Server Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Trivial Attachments: DERBY-1498.diff In DRDAConnThread.readAndSetExtParams(..) all the bytes of a LOB is concatenated to a string and traced, when running in debug mode: This makes it harder to debug OutOfMemory errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1498) avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams
[ http://issues.apache.org/jira/browse/DERBY-1498?page=all ] Andreas Korneliussen updated DERBY-1498: Derby Info: [Patch Available] avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams --- Key: DERBY-1498 URL: http://issues.apache.org/jira/browse/DERBY-1498 Project: Derby Type: Sub-task Components: Network Server Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Trivial Attachments: DERBY-1498.diff In DRDAConnThread.readAndSetExtParams(..) all the bytes of a LOB is concatenated to a string and traced, when running in debug mode: This makes it harder to debug OutOfMemory errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
[ http://issues.apache.org/jira/browse/DERBY-1497?page=all ]
Andreas Korneliussen updated DERBY-1497:
Derby Info: [Patch Available]
assert failure in MessageUtil, because exception thrown with too many
parameters when handling OutOfMemoryError
---
Key: DERBY-1497
URL: http://issues.apache.org/jira/browse/DERBY-1497
Project: Derby
Type: Sub-task
Components: Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Trivial
Attachments: DERBY-1497.diff
If the VM throws a OutOfMemoryException, which is caught in:
NetStatementReply.copyEXTDTA:
protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException
{
try {
parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
byte[] data = null;
if (longValueForDecryption_ == null) {
data = (getData(null)).toByteArray();
} else {
data = longValueForDecryption_;
dssLength_ = 0;
longValueForDecryption_ = null;
}
netCursor.extdtaData_.add(data);
} catch (java.lang.OutOfMemoryError e) { --- outofmemory
agent_.accumulateChainBreakingReadExceptionAndThrow(new
DisconnectException(agent_,
new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
e)); - message does not take parameters, causing assert
failure
}
}
Instead of getting the message: java.sql.SQLException: Attempt to fully
materialize lob data that is too large for the JVM. The connection has been
terminated.
I am getting an assert:
Exception in thread main
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of
parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-550) BLOB : java.lang.OutOfMemoryError with network JDBC driver (org.apache.derby.jdbc.ClientDriver)
Do we support streaming in the embedded driver? The embedded driver supports streaming. If you i.e call PreparedStatement.setBinaryStream(int parameterIndex, InpuStream x, int length), all the data of the InpuStream will be inserted into the row when doing executeUpdate(), *without* expanding all the data of the stream into memory. The same applies to updatable resultsets (ResultSet.updateBinaryStream(..) and ResultSet.updateRow()). Andreas
[jira] Commented: (DERBY-1261) Two triggers on same table cause ERROR 54038: Maximum depth of nested triggers was exceeded.
[ http://issues.apache.org/jira/browse/DERBY-1261?page=comments#action_12420298 ] Fernanda Pizzorno commented on DERBY-1261: -- I agree with Deepa's interpretation that a trigger should be able to fire itself, but based on the following paragraph on section 4.38 of the spec, I believe that the same row-level trigger should not be executed more than once for the same row. If a row-level trigger RLT is considered as executed for some row R in SC, then RLT is not subsequently executed for R. I looked into this issue when I was working on other trigger related issues (DERBY-1043 and DERBY-1064) and I found out that the behavior of the trigger (recursive or not) changed when changes were made to the definition of the table. Regardless of which interpretation of the spec is correct, the sudden change on the behavior of the trigger is definitively a bug. When I create the trigger tr1 on table t1 it is not recursive. create table t1 (a int, b int); insert into t1 (a) values (1), (2), (3), (4), (5); create trigger tr1 after update on t1 referencing old as old for each row mode db2sql update t1 set b = 1 where a = old.a + 1; update t1 set a = a + 10 where a = 1; select * from t1; A |B --- 11 |NULL 2 |1 3 |NULL 4 |NULL 5 |NULL 5 rows selected If I later create a new trigger on table t1 or add a column to table t1 as the two examples below show, the trigger tr1 becomes recursive. Example 1: creating a new trigger create trigger tr2 after update on t1 referencing old as old for each row mode db2sql values(old.a); update t1 set a = a + 10 where a = 1; select * from t1; A |B --- 11 |NULL 2 |1 3 |1 4 |1 5 |1 5 rows selected Example 2: adding a column alter table t1 add column c int; update t1 set a = a + 10 where a = 1; select * from t1; A |B |C --- 11 |NULL |NULL 2 |1 |NULL 3 |1 |NULL 4 |1 |NULL 5 |1 |NULL 5 rows selected It seems that changing the definition of t1 (by creating a new trigger, adding a new column, etc) caused the update statement inside the trigger tr1 to be invalidated and later recompiled. I suspect that the first time the update statement is compiled table t1 does not have a trigger tr1 and therefore the update statement does not fire triggers (UpdateResultSet with deferred = false). When the update statement is recompiled (after changes in the definition of the table), the table t1 does have a trigger tr1 and the update statement fires triggers (deferred = true). Two triggers on same table cause ERROR 54038: Maximum depth of nested triggers was exceeded. -- Key: DERBY-1261 URL: http://issues.apache.org/jira/browse/DERBY-1261 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Environment: Embedded on Solaris x86 Reporter: Øystein Grøvlen Two triggers on same table may lead to self-recursion: ij create table t3(i integer primary key, j integer, t timestamp); 0 rows inserted/updated/deleted ij create trigger tr3i after insert on t3 referencing new as new for each row mode db2sql update t3 set t = current_timestamp where i = new.i; 0 rows inserted/updated/deleted ij insert into t3 values (1, 1, NULL); 1 row inserted/updated/deleted ij create trigger tr3u after update on t3 referencing old as old for each row mode db2sql update t3 set t = current_timestamp where i = old.i; 0 rows inserted/updated/deleted ij insert into t3 values (2, 1, NULL); ERROR 54038: Maximum depth of nested triggers was exceeded. ij update t3 set j=j+1; 1 row inserted/updated/deleted ij create trigger tr3u2 after update on t3 referencing old as old for each row mode db2sql update t3 set j = 0 where i = old.i and j 2; 0 rows inserted/updated/deleted ij update t3 set j=j+1; ERROR 54038: Maximum depth of nested triggers was exceeded. From derby.log: 2006-04-27 10:03:54.792 GMT Thread[main,5,main] (XID = 1274), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Cleanup action starting 2006-04-27 10:03:54.792 GMT Thread[main,5,main] (XID = 1274), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Failed Statement is: insert into t3
[jira] Resolved: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
[ http://issues.apache.org/jira/browse/DERBY-1497?page=all ]
Andreas Korneliussen resolved DERBY-1497:
-
Fix Version: 10.2.0.0
Resolution: Fixed
Derby Info: (was: [Patch Available])
Committed revision 420821.
assert failure in MessageUtil, because exception thrown with too many
parameters when handling OutOfMemoryError
---
Key: DERBY-1497
URL: http://issues.apache.org/jira/browse/DERBY-1497
Project: Derby
Type: Sub-task
Components: Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Trivial
Fix For: 10.2.0.0
Attachments: DERBY-1497.diff
If the VM throws a OutOfMemoryException, which is caught in:
NetStatementReply.copyEXTDTA:
protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException
{
try {
parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
byte[] data = null;
if (longValueForDecryption_ == null) {
data = (getData(null)).toByteArray();
} else {
data = longValueForDecryption_;
dssLength_ = 0;
longValueForDecryption_ = null;
}
netCursor.extdtaData_.add(data);
} catch (java.lang.OutOfMemoryError e) { --- outofmemory
agent_.accumulateChainBreakingReadExceptionAndThrow(new
DisconnectException(agent_,
new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
e)); - message does not take parameters, causing assert
failure
}
}
Instead of getting the message: java.sql.SQLException: Attempt to fully
materialize lob data that is too large for the JVM. The connection has been
terminated.
I am getting an assert:
Exception in thread main
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of
parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
[ http://issues.apache.org/jira/browse/DERBY-1497?page=all ]
Andreas Korneliussen closed DERBY-1497:
---
assert failure in MessageUtil, because exception thrown with too many
parameters when handling OutOfMemoryError
---
Key: DERBY-1497
URL: http://issues.apache.org/jira/browse/DERBY-1497
Project: Derby
Type: Sub-task
Components: Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Trivial
Fix For: 10.2.0.0
Attachments: DERBY-1497.diff
If the VM throws a OutOfMemoryException, which is caught in:
NetStatementReply.copyEXTDTA:
protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException
{
try {
parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
byte[] data = null;
if (longValueForDecryption_ == null) {
data = (getData(null)).toByteArray();
} else {
data = longValueForDecryption_;
dssLength_ = 0;
longValueForDecryption_ = null;
}
netCursor.extdtaData_.add(data);
} catch (java.lang.OutOfMemoryError e) { --- outofmemory
agent_.accumulateChainBreakingReadExceptionAndThrow(new
DisconnectException(agent_,
new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
e)); - message does not take parameters, causing assert
failure
}
}
Instead of getting the message: java.sql.SQLException: Attempt to fully
materialize lob data that is too large for the JVM. The connection has been
terminated.
I am getting an assert:
Exception in thread main
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of
parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: behavior of Statement.getGeneratedKeys()
It's not entirely clear to me that Derby is not compliant. I do not believe i indicated it was or was not compliant, my point was is the data type is not what i would expect returned in this scenario. The ResultSetMetaData does correctly described the number, type and properties of the generated keys., ie. it describes the ResultSet correctly. One could say Derby always generates keys internally as of type DECIMAL(31, 0) and that is what getGeneratedKeys() returns, but when it is stored in a column it is mapped to the specific type of that column. The question is why did you decide to do return a data type other then the type of the column that it was defined? This is a more useful thing to discuss instead of just trying to find means to say it is not a Derby problem and Derby is correct. The spec for the getGeneratedKeys() has always been too vague. I won't deny that this could be written better, but this was done before my time and in reality, i do not think you will find a spec out there which does not have areas for clarification. There is a process for requesting improvements in the spec one way is you can log a bug via java.sun.com for a Sun lead spec or send an email to the comments alias for the spec in question. This would be the best way to get clarifications done to the specs. One could even argue that Derby should not return anything because Derby does not have a mechanism to generate a *unique* key field (see first sentence of 13.6 in JDBC 4). Or maybe Derby should only return values when the column is generated and is defined to be the sole column for a primary key constraint (and also unique constraint?). Again this is the original wording going back to JDBC 3.I can look at trying to clarify this a bit for the final version of JDBC 4, but not for the PFD. No promises at this time. This still does answer why DECIMAL(31,0) was chosen as the return type to be returned in all cases? Understanding this question would help in determining what action if any is needed. I guess I'm still curious to the benefit of changing it and am interested to see if a proposed fix adds or removes complexity (and for what value). The one benefit is consistency, you define an Integer, i get an Integer back which represents what was stored in the database. On the flip side, what is the real risk in changing the behavior? Whatever you decide for Derby, the Derby documentation needs clarified as well. We all want Derby to be successful and be the best product it can be. Dan.
Re: JDBC reference implentation
No it is not. Kathey Marsden wrote: Is Derby, JavaDB or something else the JDBC reference implementation these days?
Re: behavior of Statement.getGeneratedKeys()
Kathey Marsden wrote: Rick Hillegas wrote: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that we are not compliant and if non-compliance is a bug, this is a bug. The spec says: Calling ResultSet.getMetaData on the ResultSet object returned by getGeneratedKeys will produce a ResultSetMetaData object that can be used to determine the number, type and properties of the generated keys. 2) If this is a bug, is it permitted to change this behavior in a minor release? Of course debate continues, but I think it would be first good to objectively assess what JDBC calls might be affected.Perhaps whomever is considering making this change could do a thorough analysis and present it to the community. After that we could use this issue as a test case for our goal at http://wiki.apache.org/db-derby/ForwardCompatibility as we look at potential risk and what level of consultation is needed with the user community for the change and when it is appropriate. It should be a good test as our current documented behavior and the spec are at odds. Hi Kathey, I'm muddled. The affected JDBC call is Statement.getGeneratedKeys(). I don't think anyone is proposing to change the behavior of any other JDBC call. But your question makes me anxious. Why do you think other JDBC calls are affected? Kathey
Re: behavior of Statement.getGeneratedKeys()
Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: 1) Is this a bug? Should Statement.getGeneratedKeys() return a ResultSet whose column has the same type as the underyling autogenerated column? Reading from the JDBC 3.0 and JDBC 4.0 spec it seems clear to me that we are not compliant and if non-compliance is a bug, this is a bug. The spec says: Calling ResultSet.getMetaData on the ResultSet object returned by getGeneratedKeys will produce a ResultSetMetaData object that can be used to determine the number, type and properties of the generated keys. 2) If this is a bug, is it permitted to change this behavior in a minor release? Of course debate continues, but I think it would be first good to objectively assess what JDBC calls might be affected.Perhaps whomever is considering making this change could do a thorough analysis and present it to the community. After that we could use this issue as a test case for our goal at http://wiki.apache.org/db-derby/ForwardCompatibility as we look at potential risk and what level of consultation is needed with the user community for the change and when it is appropriate. It should be a good test as our current documented behavior and the spec are at odds. Hi Kathey, I'm muddled. The affected JDBC call is Statement.getGeneratedKeys(). I don't think anyone is proposing to change the behavior of any other JDBC call. But your question makes me anxious. Why do you think other JDBC calls are affected? This is the only method in play here. However, this does return a ResultSet which allows you to get the ResultSetMetaData. The behavior would not change, just that it returns the correct type for the returned column which would then correctly match the column in the base table Kathey
Re: Language based matching
Bernt M. Johnsen wrote:
aa as one letter was removed from the Norwegian language in 1938 (å
had been optional since 1917). It is only used in names today and it is
true what Anders says about the phonebook (also about the foreign names
where aa is treated like two letters). I don't think it would be wise
to not let a.* match Aasen (wich in modern writing would be Åsen).
Thank you so much Knut Anders and Bernt for the clarification on aa.
I guess now I need a new example and need to understand how Locale
specific LIKE processing is functionally different than regular like
behavior and when it is required.
The user I have been working with is actually migrating from Cloudscape
5.1.60 National Character types and the goal was to get a workaround to
achieve the same behavior in Derby. The example came from the doc:
http://publibfi.boulder.ibm.com/epubs/html/cloud51/doc/html/coredocs/sqlj105.htm#1178996
Clearly the Derby code still has the code path for the National Type
special processing.
In org.apache.derby.iapi.types.SQLChar We have a separate code path for
National Character types that passes the Collator.
How is this functionally different than LIKE processing for regular
character types? Can anyone think of another example where this special
processing might be needed?
Thanks
Kathey
Below is a SQLChar code snippet for reference.
public BooleanDataValue like(DataValueDescriptor pattern)
throws StandardException
{
Boolean likeResult;
if (! isNationalString())
{
// note that we call getLength() because the length
// of the char array may be different than the
// length we should be using (i.e. getLength()).
// see getCharArray() for more info
char[] evalCharArray = getCharArray();
char[] patternCharArray = ((SQLChar)pattern).getCharArray();
likeResult = Like.like(evalCharArray,
getLength(),
patternCharArray,
pattern.getLength());
}
else
{
SQLChar patternSQLChar = (SQLChar) pattern;
likeResult = Like.like(getIntArray(),
getIntLength(),
patternSQLChar.getIntArray(),
patternSQLChar.getIntLength(),
getLocaleFinder().getCollator());
}
[jira] Resolved: (DERBY-1498) avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams
[ http://issues.apache.org/jira/browse/DERBY-1498?page=all ] Andreas Korneliussen resolved DERBY-1498: - Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Committed revision 420863. avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams --- Key: DERBY-1498 URL: http://issues.apache.org/jira/browse/DERBY-1498 Project: Derby Type: Sub-task Components: Network Server Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-1498.diff In DRDAConnThread.readAndSetExtParams(..) all the bytes of a LOB is concatenated to a string and traced, when running in debug mode: This makes it harder to debug OutOfMemory errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1498) avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams
[ http://issues.apache.org/jira/browse/DERBY-1498?page=all ] Andreas Korneliussen closed DERBY-1498: --- avoid tracing of LOB data in DRDAConnThread.readAndSetExtParams --- Key: DERBY-1498 URL: http://issues.apache.org/jira/browse/DERBY-1498 Project: Derby Type: Sub-task Components: Network Server Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-1498.diff In DRDAConnThread.readAndSetExtParams(..) all the bytes of a LOB is concatenated to a string and traced, when running in debug mode: This makes it harder to debug OutOfMemory errors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
[
http://issues.apache.org/jira/browse/DERBY-1497?page=comments#action_12420324 ]
Bryan Pendleton commented on DERBY-1497:
It seems like it would be nice if we printed the original exception's stack
trace
somewhere prior to discarding it.
Otherwise, when this happens, all we'll know is that we ran out of memory, but
we
will lose some potentially useful information about exactly which line of code
we
were on when we ran out of memory.
assert failure in MessageUtil, because exception thrown with too many
parameters when handling OutOfMemoryError
---
Key: DERBY-1497
URL: http://issues.apache.org/jira/browse/DERBY-1497
Project: Derby
Type: Sub-task
Components: Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Trivial
Fix For: 10.2.0.0
Attachments: DERBY-1497.diff
If the VM throws a OutOfMemoryException, which is caught in:
NetStatementReply.copyEXTDTA:
protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException
{
try {
parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
byte[] data = null;
if (longValueForDecryption_ == null) {
data = (getData(null)).toByteArray();
} else {
data = longValueForDecryption_;
dssLength_ = 0;
longValueForDecryption_ = null;
}
netCursor.extdtaData_.add(data);
} catch (java.lang.OutOfMemoryError e) { --- outofmemory
agent_.accumulateChainBreakingReadExceptionAndThrow(new
DisconnectException(agent_,
new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
e)); - message does not take parameters, causing assert
failure
}
}
Instead of getting the message: java.sql.SQLException: Attempt to fully
materialize lob data that is too large for the JVM. The connection has been
terminated.
I am getting an assert:
Exception in thread main
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of
parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Language based matching
Bernt M. Johnsen wrote: aa as one letter was removed from the Norwegian language in 1938 (å had been optional since 1917). It is only used in names today and it is true what Anders says about the phonebook (also about the foreign names where aa is treated like two letters). I don't think it would be wise to not let a.* match Aasen (wich in modern writing would be Åsen). I think Kathey was just using this as an example of how the LIKE operator can be different when using locale based collation. I would hope that Derby or a workaround would use the locale collation alrady provided by Java and not set up a home-grown scheme. Thus the rules for aa in Norwegian would come from the JDK. Dan.
[jira] Commented: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
[
http://issues.apache.org/jira/browse/DERBY-1497?page=comments#action_12420328 ]
Andreas Korneliussen commented on DERBY-1497:
-
Sure that would be an improvement. It would only work on java 6, since other
VMs do not give a stack trace on OutOfMemoryError.
Before the patch, the stack trace from OutOfMemoryError was already lost, since
the code used this constructor of DisconnectException:
public DisconnectException(Agent agent, ClientMessageId msgid, Object arg1) {
this(agent, msgid, new Object[] { arg1 });
}
which at some point would call:
public DisconnectException(Agent agent, ClientMessageId msgid,
Object[] args, SqlCode sqlcode) {
this(agent, msgid, args, sqlcode, (Throwable)null);
}
(The OutOfMemoryException is part of args, not throwable, and its stacktrace
lost)
assert failure in MessageUtil, because exception thrown with too many
parameters when handling OutOfMemoryError
---
Key: DERBY-1497
URL: http://issues.apache.org/jira/browse/DERBY-1497
Project: Derby
Type: Sub-task
Components: Network Client
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Trivial
Fix For: 10.2.0.0
Attachments: DERBY-1497.diff
If the VM throws a OutOfMemoryException, which is caught in:
NetStatementReply.copyEXTDTA:
protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException
{
try {
parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
byte[] data = null;
if (longValueForDecryption_ == null) {
data = (getData(null)).toByteArray();
} else {
data = longValueForDecryption_;
dssLength_ = 0;
longValueForDecryption_ = null;
}
netCursor.extdtaData_.add(data);
} catch (java.lang.OutOfMemoryError e) { --- outofmemory
agent_.accumulateChainBreakingReadExceptionAndThrow(new
DisconnectException(agent_,
new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
e)); - message does not take parameters, causing assert
failure
}
}
Instead of getting the message: java.sql.SQLException: Attempt to fully
materialize lob data that is too large for the JVM. The connection has been
terminated.
I am getting an assert:
Exception in thread main
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of
parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: JDBC reference implentation
JavaDB is Sun supported version of Apache Derby, the open source embedded database written in pure java! Derby was cloudscape(IBM). They are not reference implementations of JDBC!!! On 7/11/06, Kathey Marsden [EMAIL PROTECTED] wrote: Is Derby, JavaDB or something else the JDBC reference implementation these days?
Re: behavior of Statement.getGeneratedKeys()
I'd like to try to summarize where I think the discussion stands: 1) Lance, our JDBC expert, has confirmed that this is not a compliance problem. That means this is not a bug. 2) Lance would like to change the behavior of Statement.getGeneratedKeys(). Currently this method always returns a ResultSet whose column has the canonical type DECIMAL( 31, 0). He would like this method to return a ResultSet whose column type changes depending on the type of the actual autogenerated column in the affected table; that is, the column could have type SMALLINT, INT, or BIGINT. 3) It does not seem that this change would have a very big impact on customers. At least, we have not been able to imagine how this would impact customers adversely. However, this is just theory and we have not polled the user community yet. So what do we think? A) Does anyone prefer the current behavior over Lance's proposed behavior? B) Does this kind of change violate our policies for minor releases? C) Are there other objections to this change? D) Would we like to poll the user community now? Regards, -Rick
Regression Test Failure! - TinderBox_Derby 420822 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 420822/2006-07-11 14:42:53 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 120.06% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-420822.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/420822.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/420822.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
Bryan Pendleton (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1497?page=comments#action_12420324 ] Bryan Pendleton commented on DERBY-1497: It seems like it would be nice if we printed the original exception's stack trace somewhere prior to discarding it. Otherwise, when this happens, all we'll know is that we ran out of memory, but we will lose some potentially useful information about exactly which line of code we were on when we ran out of memory. Unless the streaming could be fixed so that we avoid outofmemoryerrors on the receiver side, I would propose the following: We know the size of the LOB, and can check if it can go into memory (using the Runtime class). If it cannot go into memory, we can throw an SQLException, instead of consuming all memory in the VM until we get OutOfMemoryError, catch the OutOfMemoryException and throw a new SQLException. I think this approach is better, because of the following: * Although it is the LOB which is taking almost all the memory in the VM, the OutOfMemoryError may be thrown in another thread in the VM, causing side-effects on other connections or on the application itself. * We may actually go out of memory when trying to create a new SQLException in the error handler for the OutOfMemoryError I think this could be done both on the server side and the client side. -- Andreas
Re: Language based matching
Hi Kathey,
Here is my understanding of how the disabled national string types worked:
1) A national string type used the collation ordering appropriate to the
locale of the database. That collation ordering, in turn, was specified
by the jdk and could not be overriden.
2) The collation ordering determined the meaning of , =, and for
national strings. For a given locale, the rules can be quite tricky. If
you're not familiar with a locale, you are likely to be surprised by the
visibly different strings which nevertheless turn out to be = to one
another.
3) The locale-sensitive meaning of , =, and affected the operation of
all orderings of national strings, including sorts, indexes, unions,
group-by's, like's, between's, and in's.
At one point I was keen on re-enabling the national string types. Now I
am leaning toward implementing the ANSI collation language. I think this
is more powerful. In particular, it lets you support more than one
language-sensitive ordering in the same database.
You and your customer face a hard problem trying to migrate national
strings from Cloudscape 5.1.60 into Derby 10.1.3 or 10.2. I'm at a loss
how to do this in a way that preserves Cloudscape's performance.
Regards,
-Rick
Kathey Marsden wrote:
Bernt M. Johnsen wrote:
aa as one letter was removed from the Norwegian language in 1938 (å
had been optional since 1917). It is only used in names today and it is
true what Anders says about the phonebook (also about the foreign names
where aa is treated like two letters). I don't think it would be wise
to not let a.* match Aasen (wich in modern writing would be Åsen).
Thank you so much Knut Anders and Bernt for the clarification on
aa. I guess now I need a new example and need to understand how
Locale specific LIKE processing is functionally different than
regular like behavior and when it is required.
The user I have been working with is actually migrating from
Cloudscape 5.1.60 National Character types and the goal was to get a
workaround to achieve the same behavior in Derby. The example came
from the doc:
http://publibfi.boulder.ibm.com/epubs/html/cloud51/doc/html/coredocs/sqlj105.htm#1178996
Clearly the Derby code still has the code path for the National Type
special processing.
In org.apache.derby.iapi.types.SQLChar We have a separate code path
for National Character types that passes the Collator.
How is this functionally different than LIKE processing for regular
character types? Can anyone think of another example where this
special processing might be needed?
Thanks
Kathey
Below is a SQLChar code snippet for reference.
public BooleanDataValue like(DataValueDescriptor pattern)
throws StandardException
{
Boolean likeResult;
if (! isNationalString())
{
// note that we call getLength() because the length
// of the char array may be different than the
// length we should be using (i.e. getLength()).
// see getCharArray() for more info
char[] evalCharArray = getCharArray();
char[] patternCharArray = ((SQLChar)pattern).getCharArray();
likeResult = Like.like(evalCharArray,
getLength(),
patternCharArray,
pattern.getLength());
}
else
{
SQLChar patternSQLChar = (SQLChar) pattern;
likeResult = Like.like(getIntArray(),
getIntLength(),
patternSQLChar.getIntArray(),
patternSQLChar.getIntLength(),
getLocaleFinder().getCollator());
}
[jira] Updated: (DERBY-551) Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body.
[ http://issues.apache.org/jira/browse/DERBY-551?page=all ] Deepa Remesh updated DERBY-551: --- Attachment: derby-551-patch1-v1.diff derby-551-patch1-v1.status Attaching a patch 'derby-551-patch1-v1.diff' for review/commit. This patch allows invoking procedures in triggered sql statement. It is based on 'derby-551-draft3.diff' Changes are: * Modifies the parser to allow call statement in the trigger action. * Changes the validateStatement in InternalTriggerExecutionContext to catch following statements not allowed in triggers: - DDL statements are not allowed in triggers. This was caught as an assert failure as this would be caught at compile time in case of direct use of DDL statements. Since use of DDL statement inside a procedure will not be caught at compile time, patch changes the assert to a SQLException. - Insert, update, delete statements are not allowed in a before trigger. On the same lines, a procedure that modifies sql data should not be allowed in a before trigger. This is also caught at runtime. This uses the existing check in InternalTriggerExecutionContext.validateStatement. However, the existing check was limited to the trigger table. This check was modified to check for use of insert,update,delete statements on any table. * Adds a new test lang/procedureInTrigger.sql to derbylang suite. The test is based on the scenarios in ' ProcedureInTrigger_Tests_v1.html'. Only one case (calling procedures that modify SQL data in before triggers) is handled differently by this patch. Trigger creation will pass but firing will fail. This behaviour will change once we move this check to compile time. So I have not modified the test case document. Also, I have not added the test cases for recursive triggers as I am not sure about the expected behaviour. This is being discussed as part of DERBY-1261 on derby-dev. * Modifies tests and master files which used to check that call statement cannot be part of trigger action. Once this issue is resolved, we would need updates to documentation. I will open a sub-task for this later. Ran derbyall with both sane and insane jars using Sun jdk 1.4.2 on Windows XP. No failures. Please take a look at this patch. Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body. - Key: DERBY-551 URL: http://issues.apache.org/jira/browse/DERBY-551 Project: Derby Type: New Feature Components: SQL Versions: 10.1.1.0 Environment: All platforms Reporter: Satheesh Bandaram Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: ProcedureInTrigger_Tests_v1.html, derby-551-draft1.diff, derby-551-draft1.status, derby-551-draft2.status, derby-551-draft3.diff, derby-551-draft3.status, derby-551-patch1-v1.diff, derby-551-patch1-v1.status, derby-551draft2.diff Derby currently doesn't allow CALL statement to be used in a trigger body. It would be great to allow java stored procedure invocation inside a trigger. Since Derby doesn't have SQL procedure language, triggers can only execute a single SQL statement. If we allow stored procedures in triggers, it would be possible to write a trigger that involves more than just one SQL statement. Functions are currently allowed, but they are read-only. I believe it is fairly easy to support this enhancement. Need good amount of testing though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420337 ] Mamta A. Satoor commented on DERBY-1330: I have come across one test failure in derbyall suite with my changes, so please don't commit the latest patch just yet. Provide runtime privilege checking for grant/revoke functionality - Key: DERBY-1330 URL: http://issues.apache.org/jira/browse/DERBY-1330 Project: Derby Type: Sub-task Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt Additional work needs to be done for grant/revoke to make sure that only users with required privileges can access various database objects. In order to do that, first we need to collect the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM. Once we have this information then when a user tries to access an object, the required SYS.SYSREQUIREDPERM privileges for the object will be checked against the user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. The database object access will succeed only if the user has the necessary privileges. SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point and hence no runtime privilege checking is getting done at this point. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1380) Interface changes introduced in Mustang build 86
[ http://issues.apache.org/jira/browse/DERBY-1380?page=all ] Rick Hillegas resolved DERBY-1380: -- Resolution: Fixed Interface changes introduced in Mustang build 86 Key: DERBY-1380 URL: http://issues.apache.org/jira/browse/DERBY-1380 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Environment: Any Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Critical Fix For: 10.2.0.0 Attachments: derby-1380.v1.diff, derby-1380.v1.stat, derby-1380.v2.diff, derbyall_fail.v1.txt Build 86 of Mustang introduced changes to the Connection interface that were not compatible with the existing Derby implementions. createArray() was renamed createArrayOf() and setClientInfoProperties() now throws SQLClientInfoException (rather than ClientInfoException). The result of this is that it is not possible to build Derby with build 86. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1380) Interface changes introduced in Mustang build 86
[ http://issues.apache.org/jira/browse/DERBY-1380?page=all ] Rick Hillegas closed DERBY-1380: Interface changes introduced in Mustang build 86 Key: DERBY-1380 URL: http://issues.apache.org/jira/browse/DERBY-1380 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Environment: Any Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Critical Fix For: 10.2.0.0 Attachments: derby-1380.v1.diff, derby-1380.v1.stat, derby-1380.v2.diff, derbyall_fail.v1.txt Build 86 of Mustang introduced changes to the Connection interface that were not compatible with the existing Derby implementions. createArray() was renamed createArrayOf() and setClientInfoProperties() now throws SQLClientInfoException (rather than ClientInfoException). The result of this is that it is not possible to build Derby with build 86. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1279) Bad column name in DatabaseMetaData.getColumns()
[ http://issues.apache.org/jira/browse/DERBY-1279?page=all ] Rick Hillegas resolved DERBY-1279: -- Resolution: Fixed Fixed with DERBY-137. Bad column name in DatabaseMetaData.getColumns() Key: DERBY-1279 URL: http://issues.apache.org/jira/browse/DERBY-1279 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 This method returns a column named SCOPE_CATLOG. Derby has corrected this typo to SCOPE_CATALOG. To conform to the spec, Derby should faithfully mis-spell this column name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1279) Bad column name in DatabaseMetaData.getColumns()
[ http://issues.apache.org/jira/browse/DERBY-1279?page=all ] Rick Hillegas closed DERBY-1279: Bad column name in DatabaseMetaData.getColumns() Key: DERBY-1279 URL: http://issues.apache.org/jira/browse/DERBY-1279 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 This method returns a column named SCOPE_CATLOG. Derby has corrected this typo to SCOPE_CATALOG. To conform to the spec, Derby should faithfully mis-spell this column name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1496) testSecMec fails with jcc2.8 with 131 jvms
[ http://issues.apache.org/jira/browse/DERBY-1496?page=all ] Myrna van Lunteren reassigned DERBY-1496: - Assign To: Myrna van Lunteren testSecMec fails with jcc2.8 with 131 jvms -- Key: DERBY-1496 URL: http://issues.apache.org/jira/browse/DERBY-1496 Project: Derby Type: Improvement Components: Test Versions: 10.2.0.0 Reporter: Sunitha Kambhampati Assignee: Myrna van Lunteren Priority: Minor derbynet/testSecMec.java fails with jcc2.8 with 131 vms. I have checked the diff and it is a master update with difference in the exception, message string. diff snippet: 8 del T5: jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9; - EXCEPTION java.security.InvalidAlgorithmParameterException is caught when initializing EncryptionManager 'Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)' 8a8 T5: jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9; - EXCEPTION java.security.NoSuchAlgorithmException is caught when initializing EncryptionManager 'DH KeyPairGenerator not available' 14 del There is difference in the exception message and will require lot of jvm specific master files which can become difficult to maintain. Myrna suggested that this might be a good test to convert to junit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1496) testSecMec fails with jcc2.8 with 131 jvms
[ http://issues.apache.org/jira/browse/DERBY-1496?page=comments#action_12420343 ] Myrna van Lunteren commented on DERBY-1496: --- I want to try converting this one. I'll report on the experience when done. testSecMec fails with jcc2.8 with 131 jvms -- Key: DERBY-1496 URL: http://issues.apache.org/jira/browse/DERBY-1496 Project: Derby Type: Improvement Components: Test Versions: 10.2.0.0 Reporter: Sunitha Kambhampati Assignee: Myrna van Lunteren Priority: Minor derbynet/testSecMec.java fails with jcc2.8 with 131 vms. I have checked the diff and it is a master update with difference in the exception, message string. diff snippet: 8 del T5: jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9; - EXCEPTION java.security.InvalidAlgorithmParameterException is caught when initializing EncryptionManager 'Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)' 8a8 T5: jdbc:derby:net://xxxFILTERED_HOSTNAMExxx:xxxFILTEREDPORTxxx/wombat:user=neelima;password=lee;securityMechanism=9; - EXCEPTION java.security.NoSuchAlgorithmException is caught when initializing EncryptionManager 'DH KeyPairGenerator not available' 14 del There is difference in the exception message and will require lot of jvm specific master files which can become difficult to maintain. Myrna suggested that this might be a good test to convert to junit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1491) Provide ALTER TABLE functionality to change a column's default value
[ http://issues.apache.org/jira/browse/DERBY-1491?page=comments#action_12420346 ] Bryan Pendleton commented on DERBY-1491: I think I don't like this syntax. I think that it would be better to provide support for the syntax ALTER TABLE tablename ALTER [COLUMN] columnname SET DEFAULT defaultvalue and ALTER TABLE tablename ALTER [COLUMN] columnname DROP DEFAULT I will revisit this patch and investigate providing this alternate syntax. Provide ALTER TABLE functionality to change a column's default value Key: DERBY-1491 URL: http://issues.apache.org/jira/browse/DERBY-1491 Project: Derby Type: New Feature Components: Documentation, SQL Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Assignee: Bryan Pendleton Attachments: modifyDefault_1.diff Provide a way to alter the default value for an existing column in an existing table. The syntax should probably some variant of the ALTER TABLE statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Fixed issues missing a fix in version marker
There are 85 Fixed Issues with no fix version according to the report linked from http://wiki.apache.org/db-derby/DerbyJiraReports. Presumably all of these are fixed in the mainline and so these improvements will automatically turn up in 10.2 when we cut the branch next month. Is there any reason that I should not mark these as fix in 10.2? Thanks, -Rick
[jira] Updated: (DERBY-1483) Java Function defined with a BIGINT parameter invokes the method with a signature of method(long) rather than method(Long)
[ http://issues.apache.org/jira/browse/DERBY-1483?page=all ]
Rick Hillegas updated DERBY-1483:
-
Component: Documentation
Assigning this to Documentation component.
Java Function defined with a BIGINT parameter invokes the method with a
signature of method(long) rather than method(Long)
--
Key: DERBY-1483
URL: http://issues.apache.org/jira/browse/DERBY-1483
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.2.1
Reporter: Stan Bradbury
Priority: Minor
Calling a function passing BIGINT to a method accepting Long fails with the
message:
ERROR 42X50: No method was found that matched the method call
derbyJavaUtils.bigintToHexString(long), tried all combinations of object and
primitive types and any possible type conversion for any parameters the
method call may have. The method might exist but it is not public and/or
static, or the parameter types are not method invocation convertible.
The method needs to accept the primative type: long to work. BIGINT as
docuemented as having a compile time type of java.lang.Long - this is why I
expected the example method to work: see the Reference manual:
http://db.apache.org/derby/docs/10.1/ref/rrefsqlj30435.html.
Example: define the function bigintToHexString to accept a BIGINT parameter
(see below) and reference the corresponding java method bigintToHexString
(shown below) that accepts a Long. Add the jarfile with the class to the DB,
setup the database classpath and invoke with the query shown.
Java Class:
import java.sql.*;
public class derbyJavaUtils
{
// bigintToHexString
public static String bigintToHexString(Long myBigint)
{
return myBigint.toHexString(myBigint.longValue());
}
// bigintToHexString2 - this will work if used for the function
public static String bigintToHexString2(long myBigint)
{
Long myLong = null;
return myLong.toHexString(myBigint);
}
}
COMPILE IT AND JAR IT : jar -cvf derbyJavaUtils.jar DerbyJavaUtils.class
Setup the function as follows in a database:
.. CALL sqlj.install_jar( 'derbyJavaUtils.jar','APP.derbyJavaUtils',0);
.. CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath',
'APP.derbyJavaUtils');
.. CREATE FUNCTION app.bigintToHexString(hexString bigint)
RETURNS VARCHAR(16)
PARAMETER STYLE JAVA NO SQL
LANGUAGE JAVA
EXTERNAL NAME 'derbyJavaUtils.bigintToHexString'
=== One possible test query:
select 'C' || bigintToHexString2(CONGLOMERATENUMBER) || '.dat', TABLENAME,
ISINDEX
from SYS.SYSCONGLOMERATES a, SYS.SYSTABLES b
where a.TABLEID = b.TABLEID
As mention in the code comments the method: bigintToHexString2 - will work
if used for the function
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-685) Unexpected SQL Error
[ http://issues.apache.org/jira/browse/DERBY-685?page=all ] Rick Hillegas updated DERBY-685: Component: Store Assigning this to Store component. Unexpected SQL Error Key: DERBY-685 URL: http://issues.apache.org/jira/browse/DERBY-685 Project: Derby Type: Bug Components: Store Versions: 10.0.2.1 Environment: Windows XP Embedded Reporter: roy mylchreest Attachments: DerbyStack.txt We are running Derby on over 20 IBM Revelation shop tills and about once a day we get the message. ERROR XSLA4: Cannot write to the log, most likely the log is full. Please delete unnecessary files. It is also possible that the file system is read only, or the disk has failed, or some other problems with the media This results in the till having to be re-booted, much to the frustration of the cashier and the customer. However on investigation everything seems fine, the log is not full and there is plenty of room on the disk. Could anybody give me some advice on this please as it is becoming a major issue for our retail operations. thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-607) Parameters to SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE should not be case sensitive
[ http://issues.apache.org/jira/browse/DERBY-607?page=all ] Rick Hillegas updated DERBY-607: Component: SQL Assigning this to SQL component. Parameters to SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE should not be case sensitive -- Key: DERBY-607 URL: http://issues.apache.org/jira/browse/DERBY-607 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0 Environment: Java 1.5.0_04 on Windows Server 2003 Web Edition Reporter: Jeffrey Aguilera The schema and table name parameters to SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE are case sensitive, contrary to normal SQL conventions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-558) Optimizer hangs with query that uses more than 6 tables and does subquery flattening.
[ http://issues.apache.org/jira/browse/DERBY-558?page=all ] Rick Hillegas updated DERBY-558: Component: SQL Assigning to SQL component. Optimizer hangs with query that uses more than 6 tables and does subquery flattening. - Key: DERBY-558 URL: http://issues.apache.org/jira/browse/DERBY-558 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0, 10.0.2.1, 10.0.2.0, 10.1.2.0, 10.2.0.0, 10.0.2.2 Environment: Running query in ij with derby.optimizer.noTimeout=true Reporter: A B Assignee: A B Fix For: 10.1.2.0, 10.2.0.0 Attachments: d558.patch, repro.sql I was running a query that has a large number (hundreds) of tables in it and I set the derby property derby.optimizer.noTimeout to true to see what plan Derby would choose as the _best_ plan for the query. When doing so, I ran into a situation where the optimizer hung forever--which is wrong. I expect that setting noTimeout to true might cause the query to run more slowly (since it has to evaluate ALL possible join orders for all of the tables in question), but it should _not_ cause the optimizer to hang forever. I noticed that subquery flattening is peformed on the query, which introduces dependencies between the various tables and thus restricts the possible join orders that the optimizer can choose (see http://db.apache.org/derby/docs/10.1/tuning/ctuntransform25868.html). I was eventually able to track the problem down to code in OptimizerImpl where, for queries with more than 6 tables, a certain jumping algorithm is used to try to allow the optimizer to find a better plan more quickly. Long story short, there is logic in the jumping mechanism that tries to put the tables into a legal join order, but in certain (rare) cases where multiple join order dependencies have to be enforced, the jump logic can end up looping indefinitely, causing the hang in the optimizer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-409) ClientDataSource setConnectionAttributes(create=true) fails with An attempt was made to access a database, mydbcreate=true, which was not found.
[ http://issues.apache.org/jira/browse/DERBY-409?page=all ] Rick Hillegas updated DERBY-409: Component: JDBC Assigning to JDBC component. ClientDataSource setConnectionAttributes(create=true) fails with An attempt was made to access a database, mydbcreate=true, which was not found. -- Key: DERBY-409 URL: http://issues.apache.org/jira/browse/DERBY-409 Project: Derby Type: Bug Components: JDBC Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Assignee: Philip Wilder Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.1 Attachments: ConnectionAttributes.java, Derby409.patch ClientDataSource setConnectionAttributes(create=true) fails with An attempt was made to access a database, mydbcreate=true, which was not found. The method does not seem to insert a semicolon before the attributes. run attached repro to produce the error below $java ConnectionAttributes embedded setConnectionAttributes client setConnectionAttributes org.apache.derby.client.am.DisconnectException: The application server rejected establishment of the connection. An attempt was made to access a database, mydbcreate=true, which was not found. at org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java) at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java) at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java) at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java) at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java) at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java) at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java) at org.apache.derby.client.net.NetConnection.initialize(NetConnection.java) at org.apache.derby.client.net.NetConnection.init(NetConnection.java) at org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java) at org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java) at ConnectionAttributes.main(ConnectionAttributes.java:28) $ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1261) Two triggers on same table cause ERROR 54038: Maximum depth of nested triggers was exceeded.
[ http://issues.apache.org/jira/browse/DERBY-1261?page=comments#action_12420354 ] Deepa Remesh commented on DERBY-1261: - Thanks Fernanda for sharing your thoughts on this. I have a slightly different understanding of the following statement: If a row-level trigger RLT is considered as executed for some row R in SC, then RLT is not subsequently executed for R. I had read both these statements together and thought (in a given trigger execution context) implicitly applies to row-level triggers too. A statement-level trigger that is considered as executed for a state change SC (in a given trigger execution context) is not subsequently executed for SC. If a row-level trigger RLT is considered as executed for some row R in SC, then RLT is not subsequently executed for R. To me, it looked like a SC is tied to a TEC. So I had interpreted it as: If a row-level trigger RLT is considered as executed for some row R in SC (in a given trigger execution context), then RLT is not subsequently executed for R. Is this the right interpretation? If yes, I think the same row-level trigger can be executed more than once for the same row from different TECs. It can be executed only once for the same row from the same TEC. Two triggers on same table cause ERROR 54038: Maximum depth of nested triggers was exceeded. -- Key: DERBY-1261 URL: http://issues.apache.org/jira/browse/DERBY-1261 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Environment: Embedded on Solaris x86 Reporter: Øystein Grøvlen Two triggers on same table may lead to self-recursion: ij create table t3(i integer primary key, j integer, t timestamp); 0 rows inserted/updated/deleted ij create trigger tr3i after insert on t3 referencing new as new for each row mode db2sql update t3 set t = current_timestamp where i = new.i; 0 rows inserted/updated/deleted ij insert into t3 values (1, 1, NULL); 1 row inserted/updated/deleted ij create trigger tr3u after update on t3 referencing old as old for each row mode db2sql update t3 set t = current_timestamp where i = old.i; 0 rows inserted/updated/deleted ij insert into t3 values (2, 1, NULL); ERROR 54038: Maximum depth of nested triggers was exceeded. ij update t3 set j=j+1; 1 row inserted/updated/deleted ij create trigger tr3u2 after update on t3 referencing old as old for each row mode db2sql update t3 set j = 0 where i = old.i and j 2; 0 rows inserted/updated/deleted ij update t3 set j=j+1; ERROR 54038: Maximum depth of nested triggers was exceeded. From derby.log: 2006-04-27 10:03:54.792 GMT Thread[main,5,main] (XID = 1274), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Cleanup action starting 2006-04-27 10:03:54.792 GMT Thread[main,5,main] (XID = 1274), (SESSIONID = 0), (DATABASE = testDB), (DRDAID = null), Failed Statement is: insert into t3 values (2, 1, NULL) ERROR 54038: Maximum depth of nested triggers was exceeded. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.pushTriggerExecutionContext(GenericLanguageConnectionContext.java:2104) at org.apache.derby.impl.sql.execute.InternalTriggerExecutionContext.init(InternalTriggerExecutionContext.java:179) at org.apache.derby.impl.sql.execute.GenericExecutionFactory.getTriggerExecutionContext(GenericExecutionFactory.java:302) at org.apache.derby.impl.sql.execute.TriggerEventActivator.init(TriggerEventActivator.java:105) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireBeforeTriggers(UpdateResultSet.java:798) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:283) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:169) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:110) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:277) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1134) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:522) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1161) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:497) at
[jira] Updated: (DERBY-390) Import/export fails with table names that are quoted in SQL like import to table Order
[ http://issues.apache.org/jira/browse/DERBY-390?page=all ] Rick Hillegas updated DERBY-390: Component: Tools Assigning to Tools component. Import/export fails with table names that are quoted in SQL like import to table Order -- Key: DERBY-390 URL: http://issues.apache.org/jira/browse/DERBY-390 Project: Derby Type: Bug Components: Tools Versions: 10.0.2.1 Reporter: Suresh Thalamati Assignee: Suresh Thalamati Fix For: 10.1.1.0, 10.2.0.0 Attachments: derby390.diff import fails irrespective off whether the name is passed as a quoted sttring or not: ij call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR XIE0M: Table 'ORDER' does not exist. ij call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 13.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 13. Export works with a quoted table name but fails if the name is not quoted : call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; --- PASSES ij call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 15.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 15. Repro: connect 'jdbc:derby:wombat;create=true'; create table ORDER(a int ) ; insert into ORDER values(1) ; insert into ORDER values(2) ; insert into ORDER values(3) ; call SYSCS_UTIL.SYSCS_EXPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null) ; -- Perform Import call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR XIE0M: Table 'ORDER' does not exist. call SYSCS_UTIL.SYSCS_IMPORT_TABLE (null, 'ORDER' , 'order.dat' , null, null, null, 0) ; ERROR 38000: The exception 'SQL Exception: Syntax error: Encountered ORDER at line 1, column 13.' was thrown while evaluating an expression. ERROR 42X01: Syntax error: Encountered ORDER at line 1, column 13. Note: I think the same problem will occur with when quoted schema Names and column names are passed to import/export procedures. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-388) Intermittent failures when executing UPDATE trigger statements
[ http://issues.apache.org/jira/browse/DERBY-388?page=all ] Rick Hillegas updated DERBY-388: Component: SQL Assigning to SQL component. Intermittent failures when executing UPDATE trigger statements -- Key: DERBY-388 URL: http://issues.apache.org/jira/browse/DERBY-388 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.1, 10.0.2.0, 10.1.1.0 Reporter: A B Assignee: A B Fix For: 10.0.2.2, 10.1.2.0, 10.2.0.0, 10.1.1.1 Attachments: derby-388_test.patch, derby-388_v3.patch, go.java If I define an UPDATE trigger and then I repeatedly perform a table update that fires the trigger over many rows, I occasionally see intermittent failures of two kinds: 1) a null pointer exception, and/or 2) a syntax error. The NPE stack trace is this: java.lang.NullPointerException at org.apache.derby.impl.sql.GenericPreparedStatement.makeValid(GenericPreparedStatement.java:808) at org.apache.derby.impl.sql.GenericPreparedStatement.rePrepare(GenericPreparedStatement.java:229) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:342) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:166) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:108) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:296) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(UpdateResultSet.java:824) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:292) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1100) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1271) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:259) The syntax error stack trace is this: ERROR 42X01: Syntax error: org.apache.derby.iapi.db.Factory::getTriggerExecutionContext. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311) at org.apache.derby.impl.sql.compile.MethodCallNode.resolveMethodCall(MethodCallNode.java:666) at org.apache.derby.impl.sql.compile.StaticMethodCallNode.bindExpression(StaticMethodCallNode.java:455) at org.apache.derby.impl.sql.compile.NonStaticMethodCallNode.bindExpression(NonStaticMethodCallNode.java:170) at org.apache.derby.impl.sql.compile.NonStaticMethodCallNode.bindExpression(NonStaticMethodCallNode.java:170) at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(JavaToSQLValueNode.java:250) at org.apache.derby.impl.sql.compile.CastNode.bindExpression(CastNode.java:224) at [snip] org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:247) at org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:507) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:332) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107) at org.apache.derby.impl.sql.GenericPreparedStatement.makeValid(GenericPreparedStatement.java:811) at org.apache.derby.impl.sql.GenericPreparedStatement.rePrepare(GenericPreparedStatement.java:229) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:342) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java:166) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:108) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:296) at org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(UpdateResultSet.java:824) at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:292) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1100) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1271) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:259) In both cases, it looks like the error happens when Derby decides (internally) to recompile the trigger-action statement in the middle of trigger processing--depending on the state of the underlying Statement object that
[jira] Updated: (DERBY-371) Document known client/embedded differences for the Version 10.1 release
[ http://issues.apache.org/jira/browse/DERBY-371?page=all ] Rick Hillegas updated DERBY-371: Component: Documentation Assigning to Documentation component. Document known client/embedded differences for the Version 10.1 release Key: DERBY-371 URL: http://issues.apache.org/jira/browse/DERBY-371 Project: Derby Type: Sub-task Components: Documentation Versions: 10.1.1.0 Reporter: Kathey Marsden Fix For: 10.1.1.0 Attachments: derby371update2.zip The known differences between the Client and embedded driver listed in the seciton Comparision and/or differences with the Derby Embedded Driver in the Client spec at: http://incubator.apache.org/derby/papers/DerbyClientSpec.html Should be documented for the 10.1 release. It should also be noted that there may be additional differences that are not documented and in the future the client driver may be changed to match embedded. For example SQLStates for exceptions generated from the client may be changed to match embedded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-361) Unknown page format error while doing recovery after a a crash while doing in place compress.
[ http://issues.apache.org/jira/browse/DERBY-361?page=all ]
Rick Hillegas updated DERBY-361:
Component: Store
Assigning to Store component.
Unknown page format error while doing recovery after a a crash while
doing in place compress.
--
Key: DERBY-361
URL: http://issues.apache.org/jira/browse/DERBY-361
Project: Derby
Type: Bug
Components: Store
Versions: 10.1.1.0
Environment: Windows.
Reporter: Suresh Thalamati
Assignee: Mike Matrigali
Fix For: 10.1.1.0
Attachments: derby2.log, wombat.jar
Crash was done manually when compress was almost in the end.
Log trace before the crash:
DEBUG LogTrace OUTPUT: Write log record: tranId=14527 instant: (23,6270154)
leng
th: 20BeginXact null transactionStatus 0
DEBUG LogTrace OUTPUT: Write log record: tranId=14527 instant: (23,6270190)
leng
th: 25
Page Operation: Page(0,Container(0, 768)) pageVersion 9567 :
CompressSpaceOpera
tion: newHighestPage = 0;num_pages_truncated = 956 to Page(0,Container(0,
768))
DEBUG LogTrace OUTPUT: Flush log to 1350071
DEBUG LogTrace OUTPUT: Write log record: tranId=Null instant: (23,6251544)
lengt
h: 21
Checksum Operation algorithm = 1 value = 3588488 data length= 18650
DEBUG LogTrace OUTPUT: Begin log sync...
DEBUG LogTrace OUTPUT: end log sync.
DEBUG LogTrace OUTPUT: Flush log to 6270235
DEBUG LogTrace OUTPUT: Begin log sync...
DEBUG LogTrace OUTPUT: end log sync.
DEBUG LogTrace OUTPUT: Write log record: tranId=14527 instant: (24,61)
length: 1
7
EndXact null Committed : transactionStatus = Committed
---
C:\suresht\databasesjava -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij
ij version 10.1
ij call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP' , 'T1' , 1 , 1, 1) ;
IJ ERROR: Unable to establish connection
ij connect 'jdbc:derby:wombat';
ERROR XJ040: Failed to start database 'wombat', see the next exception for
detai
ls.
ERROR XSDB1: Unknown page format at page Page(102,Container(0, 768))
ij
What was done on the DB :
$ rm -rf wombat
$ ij
C:\suresht\databasesrem set DERBY_INSTALL=
C:\suresht\databasesjava -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij
ij version 10.1
ij Terminate batch job (Y/N)? ^C
$ ij
C:\suresht\databasesrem set DERBY_INSTALL=
C:\suresht\databasesjava -Dij.protocol=jdbc:derby: org.apache.derby.tools.ij
ij version 10.1
ij connect 'jdbc:derby:wombat;create=true';
ij create table t1(a int ) ;
0 rows inserted/updated/deleted
ij insert into t1 values(1) ;
1 row inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
1 row inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
2 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
4 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
8 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
16 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
32 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
64 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
128 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
256 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
512 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
1024 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
2048 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
4096 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
8192 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
16384 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
32768 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
65536 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
131072 rows inserted/updated/deleted
ij insert into t1 select a + 1 from t1 ;
262144 rows inserted/updated/deleted
ij commit ;
ij delete from t1 ;
524288 rows inserted/updated/deleted
ij select * from new org.apache.derby.diag.SpaceTable('T1') ;
ERROR 42X01: Syntax error: Encountered EOF at line 1, column 57.
ij select * from new org.apache.derby.diag.SpaceTable('T1') t ;
CONGLOMERATENAME
|ISIND|NUMALLOCATEDPAGES
|NUM
FREEPAGES|NUMUNFILLEDPAGES|PAGESIZE |ESTIMSPACESAVING
---
T1
|0 |1
|382
6|1 |4096 |15671296
1 row
[jira] Updated: (DERBY-309) Regression: store/backupRestore1.java fails
[ http://issues.apache.org/jira/browse/DERBY-309?page=all ] Rick Hillegas updated DERBY-309: Component: Test Assigning to Test component. Regression: store/backupRestore1.java fails --- Key: DERBY-309 URL: http://issues.apache.org/jira/browse/DERBY-309 Project: Derby Type: Bug Components: Test Versions: 10.1.1.0 Environment: Build: Linux 2.4.20-31.9 i686 i386, Linux 2.4.19-4GB unknown Execution: Linux 2.4.20-31.9 i686 i386, Linux-2.4.21-27.ELsmp i686-i686, SunOS-5.10 i86pc-i386, SunOS-5.10 sun4u-sparc, SunOS-5.9 sun4u-sparc, CYGWIN NT-5.2 i686-unknown, Linux 2.4.19-4GB unknown Reporter: Ole Solberg Assignee: Daniel John Debrunner Fix For: 10.1.1.0 store/backupRestore1.java failes in suites derbyall, storeall and storemore since ~revision 171143 (2005-05-22 20:56:57 CEST). See e.g. http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.4.20-31.9_i686-i686/171357-storemore_diff.txt *** Start Suite: storeall 2005-05-22 23:36:21 *** -- Java Information -- Java Version:1.5.0 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.5.0/jre Java classpath: /home/os136789/Apache/Derby/trunk/jars/insane/derby.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyclient.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbytools.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbynet.jar:/usr/local/share/java/db2jcc/lib/db2jcc.jar:/usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyTesting.jar:/home/os136789/Apache/Derby/trunk/tools/java/jakarta-oro-2.0.8.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_de_DE.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_es.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_fr.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_it.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_ja_JP.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_ko_KR.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_pt_BR.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_zh_CN.jar:/home/os136789/Apache/Derby/trunk/jars/insane/derbyLocale_zh_TW.jar OS name: Linux OS architecture: i386 OS version: 2.4.20-31.9 Java user name: os136789 Java user home: /home/os136789 Java user dir: /export/home/tmp/os136789/testingDerby/Linux-2.4.20-31.9_i686-i686/storeall java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/home/os136789/Derby/trunk/jars/insane/derby.jar] 10.1.0.0 alpha - (171357M) [/home/os136789/Derby/trunk/jars/insane/derbyclient.jar] 10.1.0.0 alpha - (171357M) [/home/os136789/Derby/trunk/jars/insane/derbytools.jar] 10.1.0.0 alpha - (171357M) [/home/os136789/Derby/trunk/jars/insane/derbynet.jar] 10.1.0.0 alpha - (171357M) [/usr/local/share/java/db2jcc/lib/db2jcc.jar] 2.4 - (17) [/usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar] 2.4 - (17) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.1.0.0 alpha - (171357M) Found support for locale: [es] version: 10.1.0.0 alpha - (171357M) Found support for locale: [fr] version: 10.1.0.0 alpha - (171357M) Found support for locale: [it] version: 10.1.0.0 alpha - (171357M) Found support for locale: [ja_JP] version: 10.1.0.0 alpha - (171357M) Found support for locale: [ko_KR] version: 10.1.0.0 alpha - (171357M) Found support for locale: [pt_BR] version: 10.1.0.0 alpha - (171357M) Found support for locale: [zh_CN] version: 10.1.0.0 alpha - (171357M) Found support for locale: [zh_TW] version: 10.1.0.0 alpha - (171357M) -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY
[ http://issues.apache.org/jira/browse/DERBY-308?page=all ] Rick Hillegas updated DERBY-308: Component: Tools Assigning to Tools component. Modify dblook to support GENERATED BY DEFAULT AS IDENTITY --- Key: DERBY-308 URL: http://issues.apache.org/jira/browse/DERBY-308 Project: Derby Type: Sub-task Components: Tools Versions: 10.1.1.0 Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama Fix For: 10.1.1.0 Attachments: DERBY-308.patch The Derby dblook utility needs to support GENERATED BY DEFAULT AS IDENTITY. This issue was notified in next mail. http://article.gmane.org/gmane.comp.apache.db.derby.devel/4096 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-226) intermittent SQLException in test jdbcapi/testRelative.java
[ http://issues.apache.org/jira/browse/DERBY-226?page=all ] Rick Hillegas updated DERBY-226: Component: Test Assigning this to Test component. intermittent SQLException in test jdbcapi/testRelative.java --- Key: DERBY-226 URL: http://issues.apache.org/jira/browse/DERBY-226 Project: Derby Type: Bug Components: Test Versions: 10.0.2.1 Reporter: Myrna van Lunteren Assignee: Shreyas Kaushik Fix For: 10.0.2.2 There is an intermittent failure in the test jdbcapi/testRelative.java. The diff is similar to the following: 6a7 SQL Exception: Invalid cursor state - no current row. 9 del SQL Exception: Invalid cursor state - no current row. Test Failed. It might be a timing issue related to doing a sqle.printStackTrace() in the case of an expected exception. The issue maybe with more than the test - but the test also has a problem: the master shows that we have an unexpected exception which doesn't make sense in the master. Generally only expected exceptions would be checked into the master and would not print a stack trace. Unexpected exceptions should cause the test to fail and should print a stack trace. Further analysis is necessary to identify why there is an exception why it /its timing is intermittent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-153) Bad Eclipse plugin version specification
[ http://issues.apache.org/jira/browse/DERBY-153?page=all ] Rick Hillegas updated DERBY-153: Component: Eclipse Plug-in Assigning to Eclipse-plugin component. Bad Eclipse plugin version specification Key: DERBY-153 URL: http://issues.apache.org/jira/browse/DERBY-153 Project: Derby Type: Bug Components: Eclipse Plug-in Versions: 10.1.1.0 Environment: Eclipse 3.1 M5 (probably problematic also with earlier versions) Reporter: Jörg von Frantzius Assignee: Andrew McIntyre Fix For: 10.0.2.2, 10.1.1.0 Attachments: eclipseplugin.diff In the plugin.xml of the Derby Eclipse plugin, the version specification reads 10.1.0.0 (124830), which Eclipse complains about as being illegal. In consequence, the plugin is not loaded. The Eclipse docs have the following to say about the version specification: Plug-in version format is major.minor.service.qualifier. Stripping the (1234830), whatever that is anyway, solves the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-106) HashJoinStrategy leads to java.lang.OutOfMemoryError
[ http://issues.apache.org/jira/browse/DERBY-106?page=all ]
Rick Hillegas updated DERBY-106:
Component: SQL
Assigning to SQL component.
HashJoinStrategy leads to java.lang.OutOfMemoryError
Key: DERBY-106
URL: http://issues.apache.org/jira/browse/DERBY-106
Project: Derby
Type: Bug
Components: SQL
Reporter: Gerald Khin
Fix For: 10.1.1.0
My application is running out of memory: I encounterd a
java.lang.OutOfMemoryError. I used -Xmx256M. Unfortunatley, I cannot spend an
arbitrary amount of JVM memory.
Then, I commented out the line in class OptimizerFactoryImpl which was adding
the HashJoinStrategy to the set of Join strategies:
if (joinStrategySet == null)
{
//JoinStrategy[] jss = new JoinStrategy[2];
JoinStrategy[] jss = new JoinStrategy[1];
jss[0] = new NestedLoopJoinStrategy();
//jss[1] = new HashJoinStrategy();
joinStrategySet = jss;
}
And with these changes the OutOfMemoryError has gone away! And it works even
with -Xmx128M!!!
So I guess that there is a major memory issue with this HashJoin strategy
implementation.
If it turns out to be too complicated to make the memory consumption more
predicatble or even bounded to some configurable limit, then I need at least
as a workaround a way to turn off the HashJoin strategy completely: I did it
by patching and building my own derby.jar, but if there would be an official
solution with some kind of switch like a system property, it would be great!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-40) Cannot set default value for BIGINT
[ http://issues.apache.org/jira/browse/DERBY-40?page=all ] Rick Hillegas updated DERBY-40: --- Component: SQL Assigning to SQL component. Cannot set default value for BIGINT --- Key: DERBY-40 URL: http://issues.apache.org/jira/browse/DERBY-40 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Environment: WINXP+sp2 jdk1.4.2_03, jdk1.3, Filesystem is NTFS Reporter: Weiming YIN Assignee: A B Fix For: 10.0.2.0 I create a table in ij, give a default value for BIGINT type will occur error. This is my SQL sentence : create table test (id BIGINT default 0); the result is ERROR 42894: DEFAULT value or IDENTITY attribute value is not valid for column 'ID'. but the following sql works well. create table test (id int default 0); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2) Can't compile Derby on OS X
[ http://issues.apache.org/jira/browse/DERBY-2?page=all ] Rick Hillegas updated DERBY-2: -- Component: Build tools Assigning to Build Tools component. Can't compile Derby on OS X --- Key: DERBY-2 URL: http://issues.apache.org/jira/browse/DERBY-2 Project: Derby Type: Bug Components: Build tools Environment: OS X 10.3.5, Java 1.4.2_05, Dual G5 Reporter: Tom Santos Fix For: 10.0.2.0 I went through all the steps in BUILDING.txt (including downloading all of the jars except osgi.jar) and have tried to build using both the default compiler and jikes. I've included both outputs in this message. My ant.properties file: j14lib=/System/Library/Frameworks/JavaVM.framework/Home/lib j13lib=/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib build.compiler=jikes Output when using Jikes (note: I get tons of compile errors that all look like the one I've provided, all while compiling compile_iapi_jdbc_jdbc2): . . . [echo] Ant environment: [echo] Base Directory: /Users/tom/dev/java/derby [echo] Build output: /Users/tom/dev/java/derby/classes [echo] Compiler: jikes [echo] Sane = true [echo] Proceed = no . . . compile_iapi_jdbc_jdbc2: [javac] Compiling 3 source files to /Users/tom/dev/java/derby/classes [javac] Found 2 semantic errors compiling BrokeredPreparedStatement.java: [javac] 24. public class BrokeredPreparedStatement extends BrokeredStatement [javac] ^---^ [javac] *** Semantic Error: The abstract method void setURL(int $1, java.net.URL $2) throws java.sql.SQLException;, inherited from type java.sql.PreparedStatement, is not implemented in the non-abstract class org.apache.derby.iapi.jdbc.BrokeredPreparedStatement. . . . BUILD FAILED /Users/tom/dev/java/derby/build.xml:137: The following error occurred while executing this line: /Users/tom/dev/java/derby/java/engine/build.xml:43: The following error occurred while executing this line: /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/build.xml:46: The following error occurred while executing this line: /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/jdbc/build.xml:64: Compile failed; see the compiler error output for details. Output when using the default compiler: . . . [echo] Ant environment: [echo] Base Directory: /Users/tom/dev/java/derby [echo] Build output: /Users/tom/dev/java/derby/classes [echo] Compiler: modern [echo] Sane = true [echo] Proceed = no . . . compile_iapi_jdbc_jdbc2: [javac] Compiling 3 source files to /Users/tom/dev/java/derby/classes [javac] Fatal Error: Unable to locate package java.lang in classpath or bootclasspath BUILD FAILED /Users/tom/dev/java/derby/build.xml:137: The following error occurred while executing this line: /Users/tom/dev/java/derby/java/engine/build.xml:43: The following error occurred while executing this line: /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/build.xml:46: The following error occurred while executing this line: /Users/tom/dev/java/derby/java/engine/org/apache/derby/iapi/jdbc/build.xml:64: Compile failed; see the compiler error output for details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
missing components
I just went through the lists of Open issues with no Component and Resolved Issues with no Component linked from http://wiki.apache.org/db-derby/DerbyJiraReports. For most of these, I hazarded a guess about the correct component. However, a few still puzzle me: 625, 1480 - These appear to be JVM/JIT issues. We don't have a component for these. 86 - This has to do with changing Cloudscape references to say Derby instead. I would appreciate the community's advice: 1) Should we create a new component for JVM/JIT issues? 2) What should we do with issue 86? Does this deserve a new component? Should we create a catch-all Miscellaneous component for these outliers? Thanks, -Rick
[jira] Closed: (DERBY-1398) Miscellaneous copy-editting problems in the user guides
[ http://issues.apache.org/jira/browse/DERBY-1398?page=all ] Rick Hillegas closed DERBY-1398: Miscellaneous copy-editting problems in the user guides --- Key: DERBY-1398 URL: http://issues.apache.org/jira/browse/DERBY-1398 Project: Derby Type: Bug Components: Documentation Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Fix For: 10.2.0.0 Attachments: bug1398_miscDoc_01.diff We should clean up these copy-editting problems: Admin Guide Update Copyrights in all docs Part One...About this guide and the Network Server documentation and and - and Part One...Accessing the Network Server by using the network client driver retrieveMessageText: Is this synchronization cruft: ...or when starting new units of work. Part One...XA and the Network Server We should say that the Derby Network Client is an example of a compliant DRDA client which you can use for distributed transactions. Part One...Using the Derby ij tool with the Network Server Do you really need the DRIVER command? Doesn't ij figure this out by itself? Part One...Differences between the embedded client and the network client driver These differences between network and embedded clients may need revisiting: * There are no localized error messages for the network client. * The network client driver fully materializes LOBS when retrieving a row. * To use an encrypted user id and password, you need to have the IBM's Java Cryptography Extension (JCE) Version 1.2.1 or later. Developer's Guide Upgrade Soft Upgrade Soft upgrade allows you TO ... Application development overview last sentence to serve AS... Derby server-side programming Programming trigger actions Examples of trigger actions insert space between the and flight_history Triggers and exceptions before to the statement - before the statement Getting Started Guide Installing and working with Derby Installing Derby This downloads page includes provides - This downloads page provides Reference Guide About this guide How this guide is organized Information about Derby's implementation of the JDBC interface include - Information about Derby's implementation of the JDBC interface, including JDBC Reference java.sql.Blob and java.sql.Clob I don't know what the following phrase means: SQL extension over SQL Notes on the same column so could result - on the same column could result Working With Derby Guide What next with Derby as your next step in leaning about - as your next step in learning about -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1152) Failures in sysinfo and sysinfo_withproperties induced by classpath wiring
[ http://issues.apache.org/jira/browse/DERBY-1152?page=all ] Rick Hillegas closed DERBY-1152: Failures in sysinfo and sysinfo_withproperties induced by classpath wiring -- Key: DERBY-1152 URL: http://issues.apache.org/jira/browse/DERBY-1152 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Bryan Pendleton Fix For: 10.2.0.0 Attachments: derby-1152-looser-policy.diff If you wire your classpath together out of the compiled classtree and the checked-in jars, you get the following error in the sysinfo and sysinfo_withproperties tests. You don't see this error if you run against the built Derby jar files: 15d14 Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read) 43d41 Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read) 72d69 Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read) Test Failed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-937) Instability in wisconsin test
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Rick Hillegas closed DERBY-937: --- Instability in wisconsin test - Key: DERBY-937 URL: http://issues.apache.org/jira/browse/DERBY-937 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.1.2.4 Reporter: Rick Hillegas Assignee: Andreas Korneliussen Fix For: 10.2.0.0 Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-862) Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-862?page=all ] Rick Hillegas closed DERBY-862: --- Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6 -- Key: DERBY-862 URL: http://issues.apache.org/jira/browse/DERBY-862 Project: Derby Type: Improvement Components: Javadoc Reporter: Rick Hillegas Assignee: Rick Hillegas Fix For: 10.2.0.0 Attachments: bug862.diff, bug862_misc1.diff, bug862_misc2.diff, bug862_misc3.diff, bug862_misc4.diff, bug862_misc5.diff, bug862_rev2.diff, clean_javadoc.output, svn_status.bug862, svn_status_rev2.bug862 Right now, the derbydocs target produces a blizzard of warnings. In addition, javadoc fails under jdk1.6 because of illegal html in Property.java and ij.jj. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-689) Various improvements to compatibility test.
[ http://issues.apache.org/jira/browse/DERBY-689?page=all ] Rick Hillegas closed DERBY-689: --- Various improvements to compatibility test. --- Key: DERBY-689 URL: http://issues.apache.org/jira/browse/DERBY-689 Project: Derby Type: Improvement Components: Test Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: bug689.diff, bug689_2.diff Improve compatibility test as various reviewers requested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-578) Grouped select from temporary table raises null pointer exception in byte code generator
[ http://issues.apache.org/jira/browse/DERBY-578?page=all ] Rick Hillegas closed DERBY-578: --- Grouped select from temporary table raises null pointer exception in byte code generator Key: DERBY-578 URL: http://issues.apache.org/jira/browse/DERBY-578 Project: Derby Type: Bug Components: SQL, Services Reporter: Rick Hillegas Assignee: Manish Khettry Fix For: 10.2.0.0 Attachments: 578.diff.new.txt, 578.diff.txt, derby578_06282006_diff.txt, predicatePushdown.out.patch The last statement in the following script: autocommit off; declare global temporary table session.ztemp ( orderID varchar( 50 ) ) not logged; select orderID from session.ztemp group by orderID; raises the following stack trace in the trunk: java.lang.NullPointerException at java.util.Hashtable.get(Hashtable.java:333) at org.apache.derby.iapi.services.classfile.ClassHolder.findMatchingEntry(ClassHolder.java:656) at org.apache.derby.iapi.services.classfile.ClassHolder.addUtf8Entry(ClassHolder.java:482) at org.apache.derby.iapi.services.classfile.ClassHolder.addString(ClassHolder.java:506) at org.apache.derby.iapi.services.classfile.ClassHolder.addConstant(ClassHolder.java:302) at org.apache.derby.impl.services.bytecode.BCMethod.push(BCMethod.java:452) at org.apache.derby.impl.sql.compile.FromBaseTable.generateDistinctScan(FromBaseTable.java:3216) at org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet(FromBaseTable.java:3032) at org.apache.derby.impl.sql.compile.FromBaseTable.generate(FromBaseTable.java:2978) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1196) at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1145) at org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(ScrollInsensitiveResultSetNode.java:109) at org.apache.derby.impl.sql.compile.ReadCursorNode.generate(ReadCursorNode.java:118) at org.apache.derby.impl.sql.compile.CursorNode.generate(CursorNode.java:546) at org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.java:232) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:433) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:704) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:533) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:203) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Resolved issues that aren't closed
According to the Resolved issues that are not closed list linked from http://wiki.apache.org/db-derby/DerbyJiraReports, there are 281 issues which have been resolved but which the reporter has not closed. Could everyone spend a half hour reviewing the resolved issues they reported and close them out as appropriate? Thanks, -Rick
[jira] Commented: (DERBY-1480) Crash with JVM 1.4.2_08-b03
[ http://issues.apache.org/jira/browse/DERBY-1480?page=comments#action_12420377 ] Andrew McIntyre commented on DERBY-1480: Is this a reproducible problem? If so, did you try running with the JIT off? Either way, I doubt that this is a problem with Derby. It appears to be a problem with your JVM. You should file a bug report with a reproducible testcase with your JVM vendor. If there is no further activity on this issue here, I will close it in a couple of days, as I do not believe it to be a problem with Derby. Crash with JVM 1.4.2_08-b03 --- Key: DERBY-1480 URL: http://issues.apache.org/jira/browse/DERBY-1480 Project: Derby Type: Bug Versions: 10.0.2.1 Environment: solaris 10 Reporter: Holger Tewis Priority: Blocker Derby crashes. derby.logs says: 2006-07-05 20:24:16.522 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.0.2.1 - (106978): instance c013800d-010c-405c-c29d-cbf29dbb on database directory /derby Database Class Loader started - derby.database.classpath='' hs_err_pid19973.log says: Unexpected Signal : 11 occurred at PC=0xF9DAE628 Function=org.apache.derby.impl.store.raw.data.BasePage.shiftUp(I)Lorg/apache/derby/impl/store/raw/data/StoredRecordHeader; (compiled Java code) Library=(N/A) Current Java thread: Dynamic libraries: 0x1 /opt/java/j2sdk1.4.2_08/jre/bin/java 0xff3f8000 /lib/libthread.so.1 0xff3a /lib/libdl.so.1 0xff28 /lib/libc.so.1 0xff27 /platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1 0xfec0 /opt/java/j2sdk1.4.2_08/jre/lib/sparc/client/libjvm.so 0xff23 /usr/lib/libCrun.so.1 0xff20 /lib/libsocket.so.1 0xff10 /lib/libnsl.so.1 0xff1e /lib/libm.so.1 0xff26 /usr/lib/libsched.so.1 0xfeb0 /lib/libm.so.2 0xff0d /lib/libscf.so.1 0xff0b /lib/libdoor.so.1 0xff09 /lib/libuutil.so.1 0xff07 /lib/libmd5.so.1 0xff05 /platform/SUNW,Sun-Fire-V440/lib/libmd5_psr.so.1 0xff03 /lib/libmp.so.2 0xfead /opt/java/j2sdk1.4.2_08/jre/lib/sparc/native_threads/libhpi.so 0xfeaa /opt/java/j2sdk1.4.2_08/jre/lib/sparc/libverify.so 0xfea6 /opt/java/j2sdk1.4.2_08/jre/lib/sparc/libjava.so 0xfea4 /opt/java/j2sdk1.4.2_08/jre/lib/sparc/libzip.so 0xf051 /opt/java/j2sdk1.4.2_08/jre/lib/sparc/libnet.so 0xefc6 /opt/java/j2sdk1.4.2_08/jre/lib/sparc/libioser12.so 0xefc4 /opt/java/j2sdk1.4.2_08/jre/lib/sparc/libnio.so 0xefa6 /lib/librt.so.1 0xef3d /lib/libaio.so.1 0xef8e /usr/lib/libsendfile.so.1 Heap at VM Abort: Heap def new generation total 4032K, used 2264K [0xf180, 0xf1c0, 0xf280) eden space 3968K, 55% used [0xf180, 0xf1a26360, 0xf1be) from space 64K, 100% used [0xf1bf, 0xf1c0, 0xf1c0) to space 64K, 0% used [0xf1be, 0xf1be, 0xf1bf) tenured generation total 6824K, used 5573K [0xf280, 0xf2eaa000, 0xf580) the space 6824K, 81% used [0xf280, 0xf2d71750, 0xf2d71800, 0xf2eaa000) compacting perm gen total 10752K, used 10644K [0xf580, 0xf628, 0xf980) the space 10752K, 99% used [0xf580, 0xf62652a8, 0xf6265400, 0xf628) Local Time = Wed Jul 5 22:24:25 2006 Elapsed Time = 13 # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002EF 01 # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode) # -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: missing components
On 7/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: I just went through the lists of Open issues with no Component and Resolved Issues with no Component linked from http://wiki.apache.org/db-derby/DerbyJiraReports. For most of these, I hazarded a guess about the correct component. However, a few still puzzle me: 625, 1480 - These appear to be JVM/JIT issues. We don't have a component for these. 86 - This has to do with changing Cloudscape references to say Derby instead. I would appreciate the community's advice: 1) Should we create a new component for JVM/JIT issues? I don't think so. JVM/JIT issues are not Derby problems, per se, they are a problem for the JVM vendor. We may want to work around them, in which case the component assigned should be the area of the code where the workaround is made, if any. I would say assign 625 to Test (or Regression Test Failure), and I think that 1480 can be closed as Invalid. I'll take care of that, as I want to ask the reporter if this is actually a reproducible problem and whether or not he tried running with the JIT off, and direct him to filing a bug report with his JVM vendor. 2) What should we do with issue 86? Does this deserve a new component? Should we create a catch-all Miscellaneous component for these outliers? For lack of a better component, you could assign it to the Unknown component, it's the current catchall for things that don't fit into any of the other components. Does everything need to have a component? Clearly if there started to be many of the same type of issue, we would want to create a new category, but if it's a one-off sort of thing, is there a problem with leaving things with no component assigned, or assigning it to the Unknown component if it doesn't fit into any other current category? andrew
Google SOC:MySQL to Derby Migration tool design question
Hello As per my earlier post regarding the design document for MySQL to Derby Migration tool located at http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument, I proposed two approches: 1) based on the use of DatabaseMetaData and 2) using DdlUtils tool. The DdlUtils tool seems not be capable of migrating views, CHECK constraints, and stored procedures. I would like to know what do you think if DdlUtils tool can be reused for migrating the tables and Indexes, and use the DatabaseMetadata for migrating views and stored procedures? . Your comments are appreciated. Thanks Ramin Moazeni
[jira] Updated: (DERBY-584) Mismatch between DatabaseMetaData and ResultSetMetaData for NUMERIC type
[ http://issues.apache.org/jira/browse/DERBY-584?page=all ] Rick Hillegas updated DERBY-584: Version: 10.1.1.0 Update which version this bug affects. Mismatch between DatabaseMetaData and ResultSetMetaData for NUMERIC type Key: DERBY-584 URL: http://issues.apache.org/jira/browse/DERBY-584 Project: Derby Type: Bug Components: JDBC Versions: 10.1.1.0 Reporter: Rick Hillegas The Derby Reference Manual says that NUMERIC is a synonyn for DECIMAL. If you create a NUMERIC column, the Derby client DatabaseMetaData reports that the type is java.sql.NUMERIC. However, if you select from the table, the ResultSetMetaData reports that the type is java.sql.DECIMAL. I don't really care what type we report. I just think we should be consistent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Resolved issues that aren't closed
On 7/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: According to the Resolved issues that are not closed list linked from http://wiki.apache.org/db-derby/DerbyJiraReports, there are 281 issues which have been resolved but which the reporter has not closed. Could everyone spend a half hour reviewing the resolved issues they reported and close them out as appropriate? +1! Let's make it really easy... Click this link: http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10594status=5reporterSelect=issue_current_usersorter/field=issuekeysorter/order=DESC and then bulk change all your issues to closed that need to be closed. thanks, andrew
[jira] Updated: (DERBY-565) Misleading parser diagnostics
[ http://issues.apache.org/jira/browse/DERBY-565?page=all ] Rick Hillegas updated DERBY-565: Version: 10.1.1.0 Update affects version field. Misleading parser diagnostics - Key: DERBY-565 URL: http://issues.apache.org/jira/browse/DERBY-565 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0 Reporter: Rick Hillegas Priority: Minor Bryan Pendleton reports: When I mistype 'join' as 'joing', the error message that I get actually complains about the word 'left'. It ought to, in my opinion, complain about the word 'joing', since that is truly the word with the syntax error in it. ij select * from t1 left outer joing t2 on t1.c2=t2.c1; ERROR 42X01: Syntax error: Encountered left at line 1, column 18. I don't know if this is a PITA to fix or not, but I thought I'd send it along anyway since it was so easy to reproduce. --- This appears to be a problem with hand-coded lookahead logic. Although fixing this particular lookahead issue might be trivial, this is part of a larger problem since the parser is liberally peppered with similar hand-coded lookahead logic. Coming up with a general solution might involve some creativity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1175) Derby Server and Administration Guide - Accessing the Network Server by using the DB2 Universal Driver
[ http://issues.apache.org/jira/browse/DERBY-1175?page=all ] Halley Pacheco de Oliveira closed DERBY-1175: - Assign To: Halley Pacheco de Oliveira Derby Server and Administration Guide - Accessing the Network Server by using the DB2 Universal Driver -- Key: DERBY-1175 URL: http://issues.apache.org/jira/browse/DERBY-1175 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.3 Environment: DITA files Reporter: Halley Pacheco de Oliveira Assignee: Halley Pacheco de Oliveira Fix For: 10.2.0.0 Attachments: cadminapps810777.diff, cadminapps810777.diff.html In Accessing the Network Server by using the DB2 Universal Driver is written: logWriter A character output stream. All logging and tracing messages print to the logWriter property. traceLevel Specifies the granularity of logging messages to the logWriter property. traceFile Provides an explicit file location for the trace output. and in Accessing the Network Server by using the network client driver is written: traceLevel The level of client tracing if traceFile or traceDirectory are set. So I think that in Accessing the Network Server by using the DB2 Universal Driver logging should be replaced by tracing in traceLevel: traceLevel Specifies the granularity of tracing messages to the logWriter property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1195) Derby Server and Administration Guide - derby.drda.keepAlive
[ http://issues.apache.org/jira/browse/DERBY-1195?page=all ] Halley Pacheco de Oliveira closed DERBY-1195: - Derby Server and Administration Guide - derby.drda.keepAlive Key: DERBY-1195 URL: http://issues.apache.org/jira/browse/DERBY-1195 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.3 Environment: DITA files Reporter: Halley Pacheco de Oliveira Assignee: Halley Pacheco de Oliveira Priority: Minor Fix For: 10.2.0.0 Attachments: radmindrdakeepalive.diff, radmindrdakeepalive.diff.html, radmindrdakeepalive.html, radmindrdakeepalive_a.diff, radmindrdakeepalive_a.diff.html, radmindrdakeepalive_a.html It is written: derby.drda.keepAlive Indicates whether SO_KEEPALIVE is enabled on sockets. The keepAlive mechanism is used to detect when clients disconnect unexpectedly. A keepalive probe is sent to the client if a long time (by default, more than two hours) passes with no other data being sent or received. derby. The drda.keepAlive property is used to detect and clean up connections for clients on powered-off machines or clients that have disconnected unexpectedly. If the property is set to false, Derby will not attempt to clean up disconnected clients. The keepAlive mechanism might be disabled if clients need to resume work without reconnecting even after being disconnected from the network for some time. To disable keepAlive probes on Network Server connections, set this property to false. In this previous paragraph, the fourth sentence has only one word, derby. I think this sentence is lost in the paragraph. In the source file there is also an empty section containing only one empty title. I think these tags can be removed from the file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - TinderBox_Derby 420895 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 420895/2006-07-11 17:22:58 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 118.64% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-420895.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/420895.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/420895.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Closed: (DERBY-1138) Derby Reference Manual translated into Brazilian Portuguese
[ http://issues.apache.org/jira/browse/DERBY-1138?page=all ] Halley Pacheco de Oliveira closed DERBY-1138: - Derby Reference Manual translated into Brazilian Portuguese --- Key: DERBY-1138 URL: http://issues.apache.org/jira/browse/DERBY-1138 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.2.3 Environment: DITA-sourced documentation Reporter: Halley Pacheco de Oliveira Assignee: Halley Pacheco de Oliveira Fix For: 10.2.0.0 Attachments: ref.tgz DITA files from %DOC_ROOT%/trunk/src/ref translated into Brazilian Portuguese to add a new entry in DITA-sourced documentation / Manuals / Brazilian Portuguese -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1123) Derby Reference Manual - SYSCS_UTIL.SYSCS_CHECK_TABLE
[ http://issues.apache.org/jira/browse/DERBY-1123?page=all ] Halley Pacheco de Oliveira closed DERBY-1123: - Assign To: Halley Pacheco de Oliveira Derby Reference Manual - SYSCS_UTIL.SYSCS_CHECK_TABLE - Key: DERBY-1123 URL: http://issues.apache.org/jira/browse/DERBY-1123 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.3 Environment: DITA files Reporter: Halley Pacheco de Oliveira Assignee: Halley Pacheco de Oliveira Fix For: 10.2.0.0 Attachments: SYSCS_CHECK_TABLE.diff, SYSCS_CHECK_TABLE_JEFF_modified.diff In SYSCS_UTIL.SYSCS_CHECK_TABLE is written: The SYSCS_UTIL.SYSCS_CHECK_TABLE function checks the specified table, ensuring that all of its indexes are consistent with the base table. When tables are consistent, the method returns a SMALLINT with value 1. If the tables are inconsistent, the function will throw an exception. I think that in the last two sentences of this paragraph the word tables should be changed to indexes, because it is the indexes that are being tested for consistency with the base table, and to maintain the word tables it should be in the singular (table) and not in the plural (tables), because the function tests just one table at each call. So the patched paragraph becomes: The SYSCS_UTIL.SYSCS_CHECK_TABLE function checks the specified table, ensuring that all of its indexes are consistent with the base table. When indexes are consistent, the method returns a SMALLINT with value 1. If the indexes are inconsistent, the function will throw an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ] A B closed DERBY-137: - Fix contributed and committed by Knut, so I'm closing the issue. Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical Fix For: 10.2.0.0 Attachments: derby-137-v1.diff, derby-137-v1.stat, derby-137-v2.diff, derby-137-v2.stat BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-780) Getting Started manual translated into Brazilian Portuguese
[ http://issues.apache.org/jira/browse/DERBY-780?page=all ] Halley Pacheco de Oliveira closed DERBY-780: Getting Started manual translated into Brazilian Portuguese --- Key: DERBY-780 URL: http://issues.apache.org/jira/browse/DERBY-780 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Environment: DITA-sourced documentation Reporter: Halley Pacheco de Oliveira Assignee: Halley Pacheco de Oliveira Fix For: 10.2.0.0 Attachments: getstart.tgz, getstart1.diff DITA files from %DOC_ROOT%/trunk/src/getstart translated into Brazilian Portuguese to be attached following Andrew McIntyre [EMAIL PROTECTED] instructions Re: How do I contribute translation? 11501 and 11503 on derby-dev Digest 13 Dec 2005 23:33:11 - Issue 597 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1376) File java/engine/org/apache/derby/loc/messages_en.properties - Message XSLAT.D
[ http://issues.apache.org/jira/browse/DERBY-1376?page=all ]
Halley Pacheco de Oliveira closed DERBY-1376:
-
Assign To: Halley Pacheco de Oliveira
File java/engine/org/apache/derby/loc/messages_en.properties - Message XSLAT.D
--
Key: DERBY-1376
URL: http://issues.apache.org/jira/browse/DERBY-1376
Project: Derby
Type: Improvement
Components: Localization
Versions: 10.1.2.5, 10.1.3.0
Environment: Text for exceptions
Reporter: Halley Pacheco de Oliveira
Assignee: Halley Pacheco de Oliveira
Priority: Minor
Fix For: 10.1.3.0, 10.2.0.0, 10.1.2.5
The message XSLAT.D (String LOG_SEGMENT_EXIST = XSLAT.D;) states:
XSLAT.D=Log directory {0} exists. Please make sure specified logDevice
location is correct.
But it seems by the source code that the problem is not that this directory
exists, but the fact that it is not empty (// make sure log directory is
empty, in LogToFile.java). So it seems to me that the following message would
be better:
XSLAT.D=Log directory {0} is not empty. Please make sure specified logDevice
location is correct.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Revoke REFERENCES privilege and drop foreign key constraint
Hi, Did anyone get a chance to go through this mail and see if I am going the right track for solving the problem? thanks, Mamta On 7/8/06, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, Based on functional specification attached to DERBY-1330, I am working on having REVOKE REFERENCES privilegedrop all the foreign key constraints dependent on that privilege. I thought, this would involve going through SYSTABLEPERMS and SYSCOLPERMS in execute phase of of REVOKE statementto find all the privilege descriptorsthat would get impacted by the REVOKE REFERENCES statement. And then let the depenency manager find all the objects that depend on those privilege descriptors andsend a REVOKE_PRIVILEGE to all those dependents. When the ConstraintDescriptor.makeInvalid method receives REOVKE_PRIVILEGE, it can simply call DataDictionary().dropConstraintDescriptor(...).But this doesn't seem to do the magic and does not clean up everything (for instance, after the REVOKE REFERENCE statement is over, TableDescriptor which had foreign key defined on it still holds on to the foreign key). I looked through alter table constant action to see what happens when a user issues a drop constraint foreignkeyname and it seems like there is lot more involved then simply calling the data dictionary to drop the constraint descriptor. In order to accomplish the same behavior, I am thinking that rather than calling just DataDictionary().dropConstraintDescriptor(...) method in the ConstraintDescriptor.makeInvalid method, I shouldissue a sql statement drop constraint foreignkeyname inside ConstraintDescriptor.makeInvalid methodand let it take care of all the necessary steps. Does anyone have any thoughts on my approach? Thanks, Mamta
[jira] Closed: (DERBY-438) Update triggers on tables with BLOB and CLOB columns fail at execution time if the triggered-SQL-statement references the LOB column(s).
[ http://issues.apache.org/jira/browse/DERBY-438?page=all ] A B closed DERBY-438: - Many patches contributed and committed by Dan, the last of which has been in the codeline for over a month now. So I'm closing this issue. Update triggers on tables with BLOB and CLOB columns fail at execution time if the triggered-SQL-statement references the LOB column(s). Key: DERBY-438 URL: http://issues.apache.org/jira/browse/DERBY-438 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0, 10.2.0.0, 10.0.2.2 Reporter: A B Assignee: Daniel John Debrunner Fix For: 10.2.0.0 Attachments: derby438_draft_statement_LOB_patch.txt, go.java Suppose I have 1) a table t1 with blob data in it, and 2) an UPDATE trigger tr1 defined on that table, where the triggered-SQL-action for tr1 references the blob column from the updated (new) row. Ex: create table t1 (id int, updated smallint, bl blob(32000)); create trigger tr1 after update on t1 referencing new as n_row for each row mode db2sql values length(n_row.bl); Assuming that t1 has been populated with some data, then attempts to update t1 will fire the trigger, but the result will be one of the two following errors: 1) If blob data is 32K... If the actual data in the table is less than 32K in length, the result will be: ERROR XCL12: An attempt was made to put a data value of type 'org.apache.derby.impl.jdbc.EmbedBlob' into a data value of type 'BLOB'. 2) If blob data is 32K... If at least one row in the table has blob data that is longer than 32K (which means that Derby will stream it, so far as I can tell), then the error will be: ERROR XCL30: An IOException was thrown when reading a 'BLOB' from an InputStream. ERROR XJ001: Java exception: ': java.io.EOFException'. Note that for data larger than 32K, this error will occur regardless of whether or not the triggered-SQL-statement references the blob column. Surprisingly, it doesn't (appear to) matter what the trigger statement is actually doing--so long as it references the blob column at least once, one of these two errors will occur, depending on the length of the data. And if the data is greater than 32k, then the error will happen regardless of what the trigger does or whether or not it references the blob column. I looked at the documentation for UPDATE statements and TRIGGER statements, but nowhere did I see anything saying that either of these will not work with blobs. So as far as I can tell, both of the above scenarios should succeed... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-861) Intermittent failure of store/readlocks.sql
[ http://issues.apache.org/jira/browse/DERBY-861?page=all ] A B closed DERBY-861: - Haven't seen this diff in the main codeline after Mike's fix, so I'm marking the issue as closed. As Mike said in his comments, if anyone sees the problem again s/he should open a new Jira issue for further tracking. Intermittent failure of store/readlocks.sql --- Key: DERBY-861 URL: http://issues.apache.org/jira/browse/DERBY-861 Project: Derby Type: Bug Components: Regression Test Failure Versions: 10.2.0.0 Reporter: A B Assignee: Mike Matrigali Priority: Minor Fix For: 10.2.0.0 The store/readlocks.sql test in derbyall fails intermittently with the following diff: *** Start: readlocks jdk1.3.1_15 storeall:storemore 2006-01-22 03:25:51 *** 19532a19533 APP |UserTran|ROW |1 |S |A |(2,6) |GRANT|ACTIVE Test Failed. *** End: readlocks jdk1.3.1_15 storeall:storemore 2006-01-22 03:30:30 *** i.e. it looks like there is an extra lock in the printed lock table. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1007) Optimizer can return incorrect best cost estimates with nested subqueries, which leads to generation of sub-optimal plans.
[ http://issues.apache.org/jira/browse/DERBY-1007?page=all ]
A B closed DERBY-1007:
--
Changes have been in 10.1 and 10.2 codelines for over a month now, so I'm
marking the issue as closed.
Optimizer can return incorrect best cost estimates with nested subqueries,
which leads to generation of sub-optimal plans.
Key: DERBY-1007
URL: http://issues.apache.org/jira/browse/DERBY-1007
Project: Derby
Type: Bug
Components: Performance
Versions: 10.2.0.0
Reporter: A B
Assignee: A B
Priority: Minor
Fix For: 10.2.0.0, 10.1.2.4, 10.1.2.5
Attachments: d1007_followup_v1.patch, d1007_v1.patch, d1007_v1.stat
When optimizing a query that has nested subqueries in it, it's possible that
the optimizer for the subqueries will return cost estimates that are lower
than what they were actually calculated to be. The result is that the outer
query can pick an access plan that is sub-optimal.
Filing this jira issue based on the thread [OPTIMIZER] OptimizerImpl best
plans for subqueries? from derby-dev. Description that follows is pasted
from that email:
http://article.gmane.org/gmane.comp.apache.db.derby.devel/14836
Following example of what I saw when tracing through the code demonstrates
the problem.
select x1.j, x2.b from
(select distinct i,j from t1) x1,
(select distinct a,b from t3) x2
where x1.i = x2.a;
During optimization of this query we will create three instancesof
OptimizerImpl:
OI_0: For select x1.j, x2.b from x1, x2 where x1.i = x2.a
OI_1: For select distinct i,j from t1
OI_2: For select distinct a,b from t3
Query ran against a clean codeline when T1 had 1 row and T3 had 50,000.
-- Top-level call is made to the optimize() method of the
outermost SelectNode, which creates OI_0.
-- OI_0: picks join order {X1, X2} and calls X1.optimizeIt()
-- X1: *creates* OI_1 and makes calls to optimize it.
-- OI_1: picks join order {T1} and calls T1.optimizeIt()
-- T1: returns a cost of 20.
-- OI_1: saves 20 as new best cost and tells T1 to save it.
-- X1: calls OI_1.getOptimizedCost(), which returns 20. X1
then returns 20 to OI_0.
-- OI_0: calls X2.optimizeIt()
-- X2: *creates* OI_2 and makes calls to optimize it.
-- OI_2: picks join order {T3} and calls T3.optimizeIt()
-- T3: returns a cost of 64700.
-- OI_2: saves 64700 as new best cost and tells T3 to save it.
-- X2: calls OI_2.getOptimizedCost(), which returns 64700. X2
then returns 64700 to OI_0.
-- OI_0: saves 20 + 64700 = 64720 as new best cost and tells
X1 to save 20 and X2 to save 64700.
-- OI_0: picks join order {X2, X1} and calls X2.optimizeIt()
-- X2: *fetches* OI_2 and makes calls to optimize it.
-- OI_2: picks join order {T3} and calls T3.optimizeIt()
-- T3: returns a cost of 10783.
-- OI_2: saves 10783 as new best cost and tells T3 to save it.
-- X2: calls OI_2.getOptimizedCost(), which returns 10783. X2
then returns 10783 to OI_0.
-- OI_0: calls X1.optimizeIt()
-- X1: *fetches* OI_1 and makes calls to optimize it.
-- OI_1: picks join order {T1} and calls T1.optimizeIt()
-- T1: returns a cost of *1 MILLION!*.
-- OI_1: rejects new cost (1 mil 20) and does nothing.
-- X1: calls OI_1.getOptimizedCost(), which returns *20*. X1
then returns 20 to OI_0...this seems WRONG!
-- OI_0: saves 10783 + 20 = 10803 as new best cost and tells
X2 to save 10783 and X1 to save 20.
So in the end, the outer-most OptimizerImpl chooses join order {X2, X1}
because it thought the cost of this join order was only 10783, which is
better than 64720. However, the _actual_ cost of the join order was really
estimated at 1 million--so the outer OptimizerImpl chose (and will generate)
a plan that, according to the estimates, was (hugely) sub-optimal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1073) Reset optimizer timeout for subqueries on a per-round basis to allow consideration of plans that use pushed predicates.
[ http://issues.apache.org/jira/browse/DERBY-1073?page=all ]
A B closed DERBY-1073:
--
All changes committed to 10.1 and 10.2 codelines and no further issues
reported, so closing.
Reset optimizer timeout for subqueries on a per-round basis to allow
consideration of plans that use pushed predicates.
---
Key: DERBY-1073
URL: http://issues.apache.org/jira/browse/DERBY-1073
Project: Derby
Type: Sub-task
Components: Performance
Versions: 10.2.0.0
Reporter: A B
Assignee: A B
Priority: Minor
Fix For: 10.2.0.0, 10.1.2.4, 10.1.2.5
Attachments: d1073_timeoutFix_v1.patch, d1073_v1.patch, d1073_v2.patch
I wanted to file this as subtask to DERBY-805, but since DERBY-805 is itself
a subtask to DERBY-649, I was not able to do so. So I'm creating this issue
as a(nother) subtaks for DERBY-649.
[ Based on derby-dev thread found here:
http://article.gmane.org/gmane.comp.apache.db.derby.devel/16007 ]
If we have a query such as:
select ... from
(select t1.i, t2.j from t1, t2 where ...) X1,
T3
where ...
then we would have one outer query and one subquery. The outer query
would be select ... from X1, T3, the subquery would be select t1.i, t2.j
from t1, t2.
In this case the Derby optimizer will create two instances of OptimizerImpl:
one for the outer query (call it OI_OQ) and one for the subquery (call it
OI_SQ). Each OptimizerImpl has its own timeout clock that it initializes
at creation time--but never resets. If timeout occurs, the OptimizerImpl
will stop searching for the best plan and will just take the best plan
found so far.
That said, for every permutation of the outer query a call will be made to
optimize the subquery. To simplify things, let's assume there are only two
permutations of the outer query: one with join order {X1, T3} and another
with join order {T3, X1}.
Now let's say we're looking at the first permutation {X1, T3}. OI_OQ will
make a call to optimize the subquery represented by OI_SQ. Let's further say
that the subquery tries some permutation {T1, T2} and then times out. It
then returns the plan information for {T1, T2} to the outer query. The outer
query, which has *not* yet timed out, then decides to try its second
permutation {T3, X1}. So it again makes a call to optimize the subquery. In
this case, the subquery--which has already timed out--will *immediately*
return without trying to optimize anything. The outer query will then make a
decision about its second permutation based on the un-optimized subquery's
plan results.
This hasn't really been an issue to date because the best plan chosen by
the subquery is typically independent of the outer query's current
permutation--with the exception of outerCost, which is passed in from the
outer query and is factored into the subquery's cost estimates. Because of
this relative independence, the plan chosen by the subquery would rarely (if
ever?) change with different permutations of the outer query, so if the
subquery timed out once there was no point in trying to re-optimize it again
later.
With DERBY-805, though, Derby has acquired the ability to push predicates
from outer queries down into subqueries--which means that the outer join
order can have a very significant impact on the plan chosen by the subquery.
But because the timeout mechanism is never reset, we could end up skipping
the second optimization phase of the subquery, which means we never get a
chance to see how much the outer predicates can help, and thus we could end
up skipping over some plans that have the potential to give us significant
performance improvement.
So resolution of this issue would involve resetting the timeout state for
subqueries to allow the Derby optimizer to consider plans that rely on pushed
predicates.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1386) Wrong results with query using LIKE and ESCAPE clause that includes %, \, and _
[ http://issues.apache.org/jira/browse/DERBY-1386?page=all ]
A B closed DERBY-1386:
--
Fix verified in 10.1 and 10.2, so I'm marking it closed. Thanks Knut Anders!
Wrong results with query using LIKE and ESCAPE clause that includes %, \,
and _
-
Key: DERBY-1386
URL: http://issues.apache.org/jira/browse/DERBY-1386
Project: Derby
Type: Bug
Components: SQL
Versions: 10.2.0.0, 10.1.2.5
Reporter: A B
Assignee: Knut Anders Hatlen
Priority: Critical
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.5
Attachments: derby-1386-v1.diff, derby-1386-v1.stat
After the fix for DERBY-1262 was checked in, I'm noticing that the following
query now returns different results. Prior to the fix for DERBY-1262 the
query returned 2 rows; now it doesn't return any rows.
create table escTable (c1 char(10));
insert into escTable values ('%_\a');
insert into escTable values ('%_b');
insert into escTable values ('%c');
insert into escTable values ('d');
insert into escTable values ('%_\e');
select c1 from escTable where c1 like '\%\_\\%' ESCAPE '\';
Before DERBY-1262, the SELECT returned:
C1
--
%_\a
%_\e
2 rows selected
Now it returns:
C1
--
0 rows selected
Brief inspection of the query and data suggest to me that these new results
(i.e. no rows) are wrong, and that Derby should in fact return 2 rows/.
Based on comments in DERBY-1262, I'm creating a new Jira issue for the
regression since it has been checked into the 10.1 maintenance branch. I've
set the priority to Critical since this could potentially delay a 10.1.3
release--I.e. I don't think we'd want to release 10.1.3 knowing that we have
a wrong results regression. But if anyone thinks that's not the correct
priority, feel free to speak up.
Other option, of course, is to back out the change for DERBY-1262 in 10.1 and
then lower the priority accordingly.
Input/feedback/comments would be appreciated.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1468) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol.
[ http://issues.apache.org/jira/browse/DERBY-1468?page=all ] A B closed DERBY-1468: -- Fix committed and I verified using the ODBC test that prompted the filing of the issue. Thanks for addressing this, Knut Anders. Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol. Key: DERBY-1468 URL: http://issues.apache.org/jira/browse/DERBY-1468 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0 Reporter: A B Assignee: Knut Anders Hatlen Fix For: 10.2.0.0 Attachments: derby-1468-v1.diff, derby-1468-v1.stat When a client sends a QRYROWSET value of zero to the server, DRDA indicates that the server should not return any rows. But the current Derby Server treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one) and thus performs pre-fetching (as of DERBY-822), which it shouldn't do. As a result, clients that send a QRYROWSET of 0 and do not expect data could see unexpected results--for example, the DB2 ODBC driver will return the first row of data twice for scrollable cursors because of this issue. Relevant discussion: http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659 Some quotes from DRDA manuals: 1) DRDA Manual v3 for OPNQRY: The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. 2) Page 698 of V.3 says: A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the server to return no rows with the OPNQRYRM for the cursor or result set. A QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset cursors and results in the application server generating a SYNTAXRM with a SYNERRCD value of '15'x (reserved value not allowed). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1331) Derby's set schema behavior is not compliant with SQL 2003 Foundation spec.
[ http://issues.apache.org/jira/browse/DERBY-1331?page=all ] Mamta A. Satoor updated DERBY-1331: --- Version: 10.1.3.1 10.1.3.0 10.1.2.1 10.1.1.0 10.0.2.1 10.0.2.0 Derby's set schema behavior is not compliant with SQL 2003 Foundation spec. - Key: DERBY-1331 URL: http://issues.apache.org/jira/browse/DERBY-1331 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Mamta A. Satoor As per SQL2003 Foundation spec, Pg 913 Section 18.6 set schema statement 3b) Otherwise, the default unqualified schema name of the current SQL-session is set to V. As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be 1)make a database connection 2)set schema to 'schema1' 3)call an external procedure using CALL statement and change schema to 'schema2' 4)After the call to external procedure, check current schema Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-159) When Derby runs in Network Server mode, client does not receive warnings generated by Derby
[ http://issues.apache.org/jira/browse/DERBY-159?page=all ]
Mamta A. Satoor updated DERBY-159:
--
Version: 10.1.3.1
10.1.3.0
10.1.2.1
10.1.1.0
10.0.2.1
10.0.2.0
When Derby runs in Network Server mode, client does not receive warnings
generated by Derby
---
Key: DERBY-159
URL: http://issues.apache.org/jira/browse/DERBY-159
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.3.1, 10.1.3.0, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0
Reporter: Mamta A. Satoor
A simple code below will demonstrate that warnings generated by Derby running
in Server mode do not make their way to client. The client code below is
trying to create the database db1drda which already exsits. Server generates
a warning for that but the client cde below does not print it.
con =
DriverManager.getConnection(jdbc:derby:net://localhost:1527/db1drda;create=true:retrieveMessagesFromServerOnGetMessage=true;,
app, app);
SQLWarning warnings1 = con.getWarnings();
System.out.println(database exists, should get warning);
while (warnings1 != null)
{
System.out.println(warnings on connection = + warnings1);
warnings1 = warnings1.getNextWarning();
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1392) Corner case behaviour in RAFContainer#writePage() can cause invalid data to be written to data files
[ http://issues.apache.org/jira/browse/DERBY-1392?page=all ] Anders Morken closed DERBY-1392: Time to close this one. Thanks for the help, Mike. =) Corner case behaviour in RAFContainer#writePage() can cause invalid data to be written to data files Key: DERBY-1392 URL: http://issues.apache.org/jira/browse/DERBY-1392 Project: Derby Type: Bug Components: Store Versions: 10.2.0.0, 10.1.2.0 Environment: Platforms that throw an IOException when writing beyond the EOF, but permit the write to proceed if the file is padded, then written. Reporter: Anders Morken Assignee: Anders Morken Priority: Minor Fix For: 10.2.0.0, 10.1.3.1 Attachments: DERBY-1392-1.patch java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java#writePage(...) will attempt to retry a write if an IOException is thrown on the first attempt. However, the next attempt does not add container header data to the first page, nor does it encrypt the data if the database is encrypted. I'd expect this bug to be case silent corruption of encrypted databases if the code path was actually exercised. The fact that this bug still lives and nobody has discovered it is possibly an indication of how uncommon this code path is. Since the comment in the code says nothing about exactly what platforms the workaround was intended for, I don't know if these platforms are still supported for Derby. There's also a workaround for an EPOC Java bug earlier in the code - EPOC only had a Java 1.1 VM, which is no longer supported. I'll attach a patch for the issue, but I wonder if we might as well remove the retry code path if it is never used? (If you're paranoid, this could also be considered a security issue. If someone could cause IO errors for Derby at will, they could make Derby write the database without encryption - but there are far easier ways to attack Derby if you've got that kind of access, so I'm discounting that. =) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1311) wisconsin test fails on 10.1 codeline on wctme5.7_foundation
[ http://issues.apache.org/jira/browse/DERBY-1311?page=all ] Sunitha Kambhampati closed DERBY-1311: -- wisconsin test fails on 10.1 codeline on wctme5.7_foundation Key: DERBY-1311 URL: http://issues.apache.org/jira/browse/DERBY-1311 Project: Derby Type: Test Components: Test Versions: 10.1.2.4 Reporter: Sunitha Kambhampati Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.5 Attachments: DERBY-1311_20060515.diff With derby jars at 10.1.2.4 - (400222) , 05/05 regression test run of derbyall on 10.1 codeline shows failure with wisconsin test with wctme5.7. Deepa pointed out in DERBY-937 that wisconsin test has been enabled to run with j2me/foundation only in the trunk. It was not enabled in 10.1 branch. The exclude lines got removed from wisconsin_app.properties as part of port for DERBY-616 and hence we are seeing the failure. The issue ERROR 40XT0: An internal error was identified by RawStore module is actually caused by another exception which can be seen earlier in the diff file: ERROR XJ001: Java exception: java.math.BigDecimal: java.lang.NoClassDefFoundError'. This exception is expected as BigDecimal class is not available in this environment. ERROR 40XT0: An internal error was identified by RawStore module. Resolution is to disable this test in 10.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1309) Test lang/updatableResultSet.java fails on wctme5.7_foundation
[ http://issues.apache.org/jira/browse/DERBY-1309?page=all ] Sunitha Kambhampati closed DERBY-1309: -- Test lang/updatableResultSet.java fails on wctme5.7_foundation -- Key: DERBY-1309 URL: http://issues.apache.org/jira/browse/DERBY-1309 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Environment: derby jars used - 10.2.0.0 alpha - (400220), machine is a win2000. Reporter: Sunitha Kambhampati Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-1309_20060515.diff 05/05/2006 regression test run of derbyall shows the following test failure with wctme5.7_foundation, lang/updatableResultSet.java * Diff file derbyall/derbylang/updatableResultSet.diff *** Start: updatableResultSet jdkJ2ME Foundation Specification v1.0 derbyall:derbylang 2006-05-07 10:52:37 *** 3 del WARNING 01J03: Scroll sensitive and scroll insensitive updatable ResultSets are not currently implemented. 4 del requested TYPE_SCROLL_INSENSITIVE, CONCUR_UPDATABLE but that is not supported 4a3,7 This test has been removed because scrollable insensitive updatable result sets have been implemented. Negative Test2 - request for scroll sensitive updatable resultset will give an updatable scroll insensitive resultset WARNING 01J02: Scroll sensitive cursors are not currently implemented. requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but that is not supported Jira issue Derby-154 : When client connects to Network Server using JCC, it incorrectly shows support for scroll sensitive updatable resultsets 5a9,11 Make sure that we got CONCUR_UPDATABLE? true Rest of the test removed because scrollable insensitive updatable result sets have been implemented. Negative Test3 - request a read only resultset and attempt deleteRow and updateRow on it 7 del ownDeletesAreVisible(ResultSet.TYPE_SCROLL_INSENSITIVE)? false 8 del othersDeletesAreVisible(ResultSet.TYPE_SCROLL_INSENSITIVE)? false 9 del deletesAreDetected(ResultSet.TYPE_SCROLL_INSENSITIVE)? false 10,28d12 JDBC 2.0 updatable resultset api will fail on this resultset because this is not an updatable resultset SQL State : XJ083 Got expected exception 'deleteRow' not allowed because the ResultSet is not an updatable ResultSet. SQL State : XJ083 Got expected exception 'updateRow' not allowed because the ResultSet is not an updatable ResultSet. Negative Test2 - request for scroll sensitive updatable resultset will give a read only scroll insensitive resultset WARNING 01J02: Scroll sensitive cursors are not currently implemented. WARNING 01J03: Scroll sensitive and scroll insensitive updatable ResultSets are not currently implemented. requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but that is not supported Jira issue Derby-154 : When client connects to Network Server using JCC, it incorrectly shows support for scroll sensitive updatable resultsets Make sure that we got TYPE_SCROLL_INSENSITIVE? true Make sure that we got CONCUR_READ_ONLY? true JDBC 2.0 updatable resultset api will fail on this resultset because this is not an updatable resultset SQL State : XJ083 Got expected exception 'deleteRow' not allowed because the ResultSet is not an updatable ResultSet. SQL State : XJ083 Got expected exception 'updateRow' not allowed because the ResultSet is not an updatable ResultSet. Negative Test3 - request a read only resultset and attempt deleteRow and updateRow on it Make sure that we got CONCUR_READ_ONLY? true 54d37 Will see the warnings in embedded mode only 2774 del Got expected exception: This method cannot be invoked unless the cursor is positioned on the insert row. 2774a2757 Got expected exception: This method cannot be invoked while the cursor is not on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY. Test Failed. *** End: updatableResultSet jdkJ2ME Foundation Specification v1.0 derbyall:derbylang 2006-05-07 10:53:25 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1385) update reference manual: scrollable insensitive resultsets will no longer be closed implicitly after a next
[ http://issues.apache.org/jira/browse/DERBY-1385?page=all ] Andreas Korneliussen closed DERBY-1385: --- update reference manual: scrollable insensitive resultsets will no longer be closed implicitly after a next --- Key: DERBY-1385 URL: http://issues.apache.org/jira/browse/DERBY-1385 Project: Derby Type: Sub-task Components: Documentation Versions: 10.2.0.0 Reporter: Andreas Korneliussen Assignee: Fernanda Pizzorno Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1385-doc.diff, derby-1385-doc.stat Remove note from reference manual: src/ref/rrefjdbc77156.dita) Note: When working with scrolling insensitive ResultSets when auto-commit mode is turned on, the only positioning method that can close the ResultSet automatically is the next() method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-998) tests jdbcapi/SURTest.junit and jdbcapi/SURQueryMixTest.junit run twice in derbynetclientmats
[ http://issues.apache.org/jira/browse/DERBY-998?page=all ] Myrna van Lunteren reassigned DERBY-998: Assign To: David Van Couvering tests jdbcapi/SURTest.junit and jdbcapi/SURQueryMixTest.junit run twice in derbynetclientmats - Key: DERBY-998 URL: http://issues.apache.org/jira/browse/DERBY-998 Project: Derby Type: Test Components: Test Versions: 10.2.0.0 Reporter: Myrna van Lunteren Assignee: David Van Couvering Priority: Trivial The tests SURTest.junit and SURQueryMixTest.junit both appear in derbynetclientmats.runall as well as in jdbcapi.runall. So it unnecessarily runs twice, because jdbcapi is already included in the suites in derbynetclientmats.properties. It should be removed from derbynetclientmats.runall. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1308) Tests jdbcapi/HoldabilityTest.junit, jdbcapi/UpdateXXXTest.junit,jdbcapi/SURTest.junit fail on wctme5.7_foundation
[ http://issues.apache.org/jira/browse/DERBY-1308?page=all ] Sunitha Kambhampati closed DERBY-1308: -- Tests jdbcapi/HoldabilityTest.junit, jdbcapi/UpdateXXXTest.junit,jdbcapi/SURTest.junit fail on wctme5.7_foundation -- Key: DERBY-1308 URL: http://issues.apache.org/jira/browse/DERBY-1308 Project: Derby Type: Bug Components: Test, Regression Test Failure Versions: 10.2.0.0 Environment: derby jars used - 10.2.0.0 alpha - (400220), machine is a win2000. Reporter: Sunitha Kambhampati Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-1308_20060524.diff, DERBY-1308_20060524.stat, DERBY-1308_2_20060524.diff, DERBY-1308_2_20060524.stat, DERBY-1308_3_20060527.diff, DERBY-1308_3_20060527.stat 05/05/2006 regression test run of derbyall shows the following test failure with wctme5.7_foundation, derbyall/derbyall.fail:jdbcapi/HoldabilityTest.junit derbyall/derbyall.fail:jdbcapi/UpdateXXXTest.junit derbyall/derbyall.fail:jdbcapi/SURTest.junit Diff is a CNFE with ConnectionPoolDataSource. * Diff file derbyall/jdbcapi/HoldabilityTest.diff *** Start: HoldabilityTest jdkJ2ME Foundation Specification v1.0 derbyall:jdbcapi 2006-05-07 11:31:05 *** 0 add Exception in thread main java.lang.NoClassDefFoundError: javax.sql.ConnectionPoolDataSource Test Failed. *** End: HoldabilityTest jdkJ2ME Foundation Specification v1.0 derbyall:jdbcapi 2006-05-07 11:31:06 *** My guess is these tests need to excluded from running in this environment. Can someone please confirm. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1277) Call to rs.isLast() may cause rs.getXXX() return values from the last row instead of the current row in scrollable resultsets
[ http://issues.apache.org/jira/browse/DERBY-1277?page=all ] Andreas Korneliussen closed DERBY-1277: --- Call to rs.isLast() may cause rs.getXXX() return values from the last row instead of the current row in scrollable resultsets - Key: DERBY-1277 URL: http://issues.apache.org/jira/browse/DERBY-1277 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0, 10.1.2.1 Reporter: Andreas Korneliussen Assignee: Andreas Korneliussen Fix For: 10.2.0.0 Attachments: DERBY-1277.diff, DERBY-1277.stat In scrollable updatable resultset, a call to rs.isLast() may cause rs.getXXX() return values from the last row, instead of for the current row. This may be related to the fact that on calls to isLast() the scroll insensitive resultset moves to the last row, and then moves back to the current row (see DERBY-1276 for related information). The call to isLast() seems to have a sideeffect when the resultset is updatable. I have test which does the following: Statement stmt1 = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE); ResultSet rs = stmt1.executeQuery(select * from testRelative); rs.next(); // First Record System.out.println(First record is: + rs.getString(name)); rs.relative(2); // Third Record System.out.println(Third record is: + rs.getString(name)); System.out.println( isLast= + rs.isLast()); System.out.println(Third record is: + rs.getString(name)); The output is: First record is: work1 Third record is: work3 isLast=false Third record is: work4 isLast()==false The issue may also be reproduced by applying the following patch to testRelative: Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java === --- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java (revision 399224) +++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java (working copy) @@ -60,7 +60,7 @@ pStmt.executeBatch(); con.commit(); - stmt1 = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY); + stmt1 = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE); rs = stmt1.executeQuery(select * from testRelative); rs.next(); // First Record -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1226) test resultset.java fails with 10.2 derby client with zOS
[ http://issues.apache.org/jira/browse/DERBY-1226?page=all ]
Myrna van Lunteren reassigned DERBY-1226:
-
Assign To: Sunitha Kambhampati
test resultset.java fails with 10.2 derby client with zOS
-
Key: DERBY-1226
URL: http://issues.apache.org/jira/browse/DERBY-1226
Project: Derby
Type: Bug
Components: Regression Test Failure
Versions: 10.2.0.0
Environment: zOS and ibm14 or ibm15
Reporter: Myrna van Lunteren
Assignee: Sunitha Kambhampati
The test jdbcapi/resultset.java fails with ibm14 and ibm15 with 10.2 Does not
fail with ibm 10.1.2
The failure is that apparently there's a Data Conversion SQLException
occurring. There is no stack in the resultset.tmp file, nor any useful
details in the .log. A repro is needed, but I'm logging the failure first.
this is the diff:
-
Framework: DerbyNetClient
*** Start: resultset jdk1.4.2 DerbyNetClient 2006-04-17 19:40:07 ***
1948 del
COL1(datatype : DATE, precision : 10, scale : 0)
1949 del
1950 del
{2000-01-01}
1951 del
{null}
1952 del
{null}
1953 del
{2000-01-01}
1953a1948
Data Conversion SQLException
1956 del
COL1(datatype : TIME, precision : 8, scale : 0)
1957 del
---
1958 del
{15:30:20}
1959 del
{null}
1960 del
{null}
1961 del
{null}
1961a1951
Data Conversion SQLException
1964 del
COL1(datatype : TIMESTAMP, precision : 26, scale : 6)
1965 del
-
1966 del
{xxFILTERED-TIMESTAMPx}
1967 del
{null}
1968 del
{null}
1969 del
{null}
1969a1954
Data Conversion SQLException
-
This does fail with both ibm14 and ibm15, it does not fail with jcc, it does
not fail with 10.1.(current build).
I marked it as Regression, because it doesn't occur with 10.1, but I can't
say whether this test ever passed since implementing the fix for DERBY-877.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-95) NPE when passing in url instead of database name to EmbeddedXADataSource
[ http://issues.apache.org/jira/browse/DERBY-95?page=all ] Myrna van Lunteren reassigned DERBY-95: --- Assign To: Shreyas Kaushik NPE when passing in url instead of database name to EmbeddedXADataSource Key: DERBY-95 URL: http://issues.apache.org/jira/browse/DERBY-95 Project: Derby Type: Bug Components: JDBC Reporter: Myrna van Lunteren Assignee: Shreyas Kaushik Priority: Minor Fix For: 10.0.2.1 Attachments: Derby-95.diff, Derby-95_latest.diff When passing in a url (e.g. jdbc:derby:mydb) instead of just the database name (e.g. mydb) the XADataSource gives a NullPointerException. It should either handle this a little more gracefully give an error, or accept the url (like EmbeddedDataSource does). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-95) NPE when passing in url instead of database name to EmbeddedXADataSource
[ http://issues.apache.org/jira/browse/DERBY-95?page=all ] Myrna van Lunteren closed DERBY-95: --- NPE when passing in url instead of database name to EmbeddedXADataSource Key: DERBY-95 URL: http://issues.apache.org/jira/browse/DERBY-95 Project: Derby Type: Bug Components: JDBC Reporter: Myrna van Lunteren Assignee: Shreyas Kaushik Priority: Minor Fix For: 10.0.2.1 Attachments: Derby-95.diff, Derby-95_latest.diff When passing in a url (e.g. jdbc:derby:mydb) instead of just the database name (e.g. mydb) the XADataSource gives a NullPointerException. It should either handle this a little more gracefully give an error, or accept the url (like EmbeddedDataSource does). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-575) test blobclob4BLOB fails on OS 390
[ http://issues.apache.org/jira/browse/DERBY-575?page=all ] Myrna van Lunteren closed DERBY-575: test blobclob4BLOB fails on OS 390 -- Key: DERBY-575 URL: http://issues.apache.org/jira/browse/DERBY-575 Project: Derby Type: Bug Components: Test Versions: 10.1.1.0 Environment: OS/390 (z/OS 1.06; IBM j2RE 1.4.2) Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.1.3.0, 10.2.0.0 Attachments: DERBY-575_101_20060502.diff, DERBY-575_101_20060502.stat, DERBY-575_102_20060424.diff, DERBY-575_102_20060424.stat The subtest clobNegativeTest_Derby265 in test jdbcapi/blobclob4BLOB assumes that the length of the file used (aclob.txt) is 30 but on OS 390 (z/OS), after conversion to EBCDIC, the length is 297000. The test should be modified to not use a hardcoded size. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-632) test dataSourcePermissions_net doesn't run with derby client (unless db2jcc is in classpath)
[ http://issues.apache.org/jira/browse/DERBY-632?page=all ] Myrna van Lunteren closed DERBY-632: test dataSourcePermissions_net doesn't run with derby client (unless db2jcc is in classpath) Key: DERBY-632 URL: http://issues.apache.org/jira/browse/DERBY-632 Project: Derby Type: Bug Components: Test Versions: 10.1.1.0 Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 Attachments: derby632.diff, derby632.stat The test derbynet/dataSourcePermissions_net.java doesn't run with derbyclient, unless IBM's Universal Driver is in the classpath. The test gets erroneously skipped with the following comment: This test/suite is excluded from running with JCC versions at or before 1.1. There's something wrong in the test harness' skipping mechanism that it decides this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
