Re: Question on Grant revoke functional spec
Daniel John Debrunner wrote: Satheesh Bandaram wrote: Derby currently doesn't support WITH GRANT OPTION. So, while it is OK for 'mamta2' here to create the view, an error *should be* raised if this user attempts to grant access to columns derived from user 'mamta1' table. What's the reference (section number) for this from the SQL 2003 spec, especially for the definition of columns derived? I am still trying to access SQL 2003 spec to confirm what it says. My soft copy seems to be corrupted... doesn't come up anymore. But I have DB2 8.1.5 installed on my machine and tried to confirm what DB2 does in this situation. It indeed raises an error, trying to GRANT access to columns derived from another table not owned by the view owner. But it does allow this GRANT to suceed if the SELECT privilege to the view owner was granted WITH GRANT OPTION. Again, I will try to get hold of SQL 2003 spec on Monday and confirm what it says. Satheesh
[jira] Updated: (DERBY-1539) As per the functional spec attached to DERBY-1330, a trigger should be dropped when a privilege required by the trigger is revoked.
[ http://issues.apache.org/jira/browse/DERBY-1539?page=all ] Mamta A. Satoor updated DERBY-1539: --- Attachment: DERBY1539V4diffDropTriggerOnRevokeRequiredPrivilege.txt DERBY1539V4statDropTriggerOnRevokeRequiredPrivilege.txt Recently, I had submitted a patch(DERBY1539V3diffDropTriggerOnRevoke.txt) for triggers which will drop the triggers if a revoke privilege is issued on a table/routine used by the trigger. That patch dropped the trigger even if the trigger didn't depend on the permission type/column on the table. And the patch dropped the trigger if the trigger depended on the routine. eg for current behavior on revoke table level privilege mamta1 create table t1(c11 int, c12 int); grant select, update, trigger on t1 to mamta2 mamta2 create a trigger on mamta1.t1 with action as select * from some other table -- notice that the trigger object above depends only on the trigger privilege on mamta1.t1 mamta1 revoke select on t1 from mamta2 -- this revoke ends up dropping the trigger even though trigger doesnot rely on select permission eg for current behavior on revoke column level privilege mamta1 create table t1(c11 int, c12 int); grant trigger on t1 to mamta2 create table t2(c21 int, c22 int); grant select(c21, c22) on t2 to mamta2 mamta2 create a trigger on mamta1.t1 with action as select c21 from mamta1.t2 -- notice that the trigger object above depends only on the trigger privilege on mamta1.t1, and -- select privilege on mamta1.t2.c21 mamta1 revoke select(c22) on t2 from mamta2 -- this revoke ends up dropping the trigger even though trigger doesnot rely on select -- permission on column c22 of table t2 eg for current behavior on revoke column level privilege mamta1 create function f1 grant execute on f1 to mamta2 mamta2 create table t1 create trigger on t1 with action that executes mamta1.f1 mamta1 revoke execute on f1 from mamta2 RESTRICT -- this revoke ends up dropping the trigger even though revoke execute is supposed to have -- RESTRICT behavior, which means that -- if there are dependent objects, then revoke execute should fail. Couldn't implement this in earlier -- patch because dependents didn't know what kind of revoke was issued. All they knew was revoke -- issued against one of the objects that the dependent relied on. With the idea of working in incremental steps, I submitted the earlier patch as the first step towards implementing revoke privilege. As the next step, I am attaching another patch (DERBY1539V4diffDropTriggerOnRevokeRequiredPrivilege.txt ), which will fix the problem mentioned above in the egs. This patch currently only deals with triggers. The next steps are to implement similar behavior for views and constraints. The svn stat -q o/p for this patch is attached as DERBY1539V4statDropTriggerOnRevokeRequiredPrivilege.txt. Note that I have added a new file in this patch. The reason for implementing REVOKE EXECUTE ... RESTRICT in this patch is that prior to this patch, there was no way of knowing what kind of revoke privilege is issued by the user and hence even on revoke execute, I was dropping the dependent objects. With this patch, now we know what kind of revoke privilege has been issued and when the dependent gets revoke execute action, it can now throw an exception. Grant revoke tests have run fine with this patch. I fired derbyall suite couple hrs back on my Windows XP machine with Sun'd jdk1.4 and no errors so far. More information on the current patch's implementation details is as follows. 1)BasicDependencyManager, TriggerDescriptor SYSTABLEPERMS has one row per table, grantee, grantor. That row has various fields to indicate what type of permissions(insert, trigger, update etc) are available for that key. The row is also uniquely identified by a UUID. Currently, when an object is created and it needs a particular pemission type on a given table, grantee, grantor, the dependency manager(DM) only tracks the dependency using UUID and it doesn't keep track of the exact permission type required. Because of this, currently, any permission type that gets revoked on table, grantee, grantor, it ends up dropping the dependent object, whether or not the dependent object really needs that permission type. eg(copying the eg from the beginning of this comment mamta1 create table t1(c11 int, c12 int); grant select, update, trigger on t1 to mamta2 mamta2 create a trigger on mamta1.t1 with action as select * from some other table -- notice that the trigger object above depends only on
[jira] Created: (DERBY-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take
Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take it as error. Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Client, Network Server Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama There exists difference between Engine and Network Client/Engine around type compatibility judgement in character typed column when null value was passed as InputStream. -- 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-1535) Trial 2 for DERBY-550, improve use of Engine from NetworkServer and reduce memory usage
[ http://issues.apache.org/jira/browse/DERBY-1535?page=comments#action_12424361 ] Tomohito Nakayama commented on DERBY-1535: -- Continuing survey, I found the type compatibility problem around null value typed as InputStream seems to be not so tiny problem. I created new task, DERBY-1610. Trial 2 for DERBY-550, improve use of Engine from NetworkServer and reduce memory usage --- Key: DERBY-1535 URL: http://issues.apache.org/jira/browse/DERBY-1535 Project: Derby Issue Type: Sub-task Components: Network Server Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1513_1535.patch, DERBY-1513_1535_2.patch, DERBY-1535.patch, serverMemoryUsage.xls, serverMemoryUsage_1513_1535.xls Through DERBY-1513, Trial 1 for DERBY-550, it was suggested that NetworkServer seems to use Engine inefficiently and use too much of memory. This task try to improve the use of Engine from NetworkServer and try to reduce memory usage. -- 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-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take
[ http://issues.apache.org/jira/browse/DERBY-1610?page=all ] Tomohito Nakayama updated DERBY-1610: - Attachment: TestNullChar.java Result of the execution is as next : In the case of Network Client/Server : [EMAIL PROTECTED]:~/derby/test/20060730$ java TestNullChar streamAsNull: null setNull: null In the case of Engine : [EMAIL PROTECTED]:~/derby/test/20060730$ java TestNullChar embedded streamAsNull: java.sql.SQLException: An attempt was made to get a data value of type 'CHAR' from a data value of type 'java.io.InputStream'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:44) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:94) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:180) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java:1958) at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(ConnectionChild.java:153) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(EmbedPreparedStatement.java:1611) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.checkBinaryStreamConditions(EmbedPreparedStatement.java:923) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setBinaryStream(EmbedPreparedStatement.java:839) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setBinaryStream(EmbedPreparedStatement.java:853) at TestNullChar.updateStreamAsNull(TestNullChar.java:118) at TestNullChar.main(TestNullChar.java:46) java.sql.SQLException: Invalid cursor state - no current row. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:44) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:104) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:168) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java:1952) at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(ConnectionChild.java:147) at org.apache.derby.impl.jdbc.EmbedResultSet.checkOnRow(EmbedResultSet.java:325) at org.apache.derby.impl.jdbc.EmbedResultSet.getColumn(EmbedResultSet.java:4378) at org.apache.derby.impl.jdbc.EmbedResultSet.getString(EmbedResultSet.java:680) at TestNullChar.updateStreamAsNull(TestNullChar.java:139) at TestNullChar.main(TestNullChar.java:46) setNull: null Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take it as error. Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: TestNullChar.java There exists difference between Engine and Network Client/Engine around type compatibility judgement in character typed column when null value was passed as InputStream. -- 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-98) Add support for delete functionality using JDBC 2.0 updatable resultset apis
[ http://issues.apache.org/jira/browse/DERBY-98?page=all ] Mamta A. Satoor closed DERBY-98. Resolution: Fixed Closing this issue since delete functionality using JDBC 2.0 has been implemented for all the types of resultsets supported by Derby at this point. Add support for delete functionality using JDBC 2.0 updatable resultset apis Key: DERBY-98 URL: http://issues.apache.org/jira/browse/DERBY-98 Project: Derby Issue Type: New Feature Components: JDBC Affects Versions: 10.1.1.0 Reporter: Mamta A. Satoor The JDBC 2.0 API introduced the ability to update/delete/insert rows from a resultset using methods in the Java programming language rather than having to send an SQL command. This Jira entry is to track the delete rows functionality using JDBC 2.0 apis. -- 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-99) Add support for update functionality using JDBC 2.0 updatable resultset apis
[ http://issues.apache.org/jira/browse/DERBY-99?page=all ] Mamta A. Satoor closed DERBY-99. Resolution: Fixed Closing this issue since update functionality using JDBC 2.0 has been implemented for all the types of resultsets supported by Derby at this point. Add support for update functionality using JDBC 2.0 updatable resultset apis Key: DERBY-99 URL: http://issues.apache.org/jira/browse/DERBY-99 Project: Derby Issue Type: New Feature Components: JDBC Affects Versions: 10.1.1.0 Reporter: Mamta A. Satoor The JDBC 2.0 API introduced the ability to update/delete/insert rows from a resultset using methods in the Java programming language rather than having to send an SQL command. This Jira entry is to track the update rows functionality using JDBC 2.0 apis. -- 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-100) Add support for insert functionality using JDBC 2.0 updatable resultset apis
[ http://issues.apache.org/jira/browse/DERBY-100?page=all ] Mamta A. Satoor closed DERBY-100. - Resolution: Fixed Derby Info: (was: [Release Note Needed]) Closing this issue since insert functionality using JDBC 2.0 has been implemented for all the types of resultsets supported by Derby at this point. Add support for insert functionality using JDBC 2.0 updatable resultset apis Key: DERBY-100 URL: http://issues.apache.org/jira/browse/DERBY-100 Project: Derby Issue Type: New Feature Components: JDBC Affects Versions: 10.1.1.0 Reporter: Mamta A. Satoor Fix For: 10.2.0.0 Attachments: DERBY-100-2.diff, DERBY-100-2.stat, DERBY-100-3.diff, DERBY-100-3.stat, DERBY-100-4.diff, DERBY-100-4.stat, DERBY-100.diff, DERBY-100.stat The JDBC 2.0 API introduced the ability to update/delete/insert rows from a resultset using methods in the Java programming language rather than having to send an SQL command. This Jira entry is to track the insert rows functionality using JDBC 2.0 apis. -- 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-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not ta
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12424366 ] Tomohito Nakayama commented on DERBY-1610: -- Using jdb, I found that next code is executed at NetworkServer in both case of setBinaryStream method with null and setNull method. Step completed: thread=DRDAConnThread_3, org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(), line=4,047 bci=722 4,047 ps.setNull(i+1, pmeta.getParameterType(i+1)); I think current implementation of NetworkClient/NetworkServer handle them in same way both to call setBinaryStream method with null value and to call of setNull method. Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take it as error. Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: TestNullChar.java There exists difference between Engine and Network Client/Engine around type compatibility judgement in character typed column when null value was passed as InputStream. -- 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-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not ta
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12424368 ] Tomohito Nakayama commented on DERBY-1610: -- I think current behavior of Engine is reasonable. When setNull method was called, type information of the null value is specified. Then, Engine can determine whether the type of null value is acceptable. On the other hand, when setBinaryStream method was called, type information of the null value is not specified. Then Engine does not have any other way other than takeing the null value as incompatible type error. Now questionable part is implementation of NetworkClient/NetoworkServer around type of value, especially null value. Current behavior looks like as if NetworkClient/NetworkServer ignore type of null value. Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take it as error. Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: TestNullChar.java There exists difference between Engine and Network Client/Engine around type compatibility judgement in character typed column when null value was passed as InputStream. -- 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 426827 - Sun DBTG
[Auto-generated mail] *Derby* 426827/2006-07-29 19:46:14 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* NA NA NANA SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-426827.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/426827.html *Jvm: 1.5* NA NA NANA CYGWIN_NT-5.1_i686-unknown 3684681 2 118.17% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 0684684 2 106.45% Linux-2.6.9-34.ELsmp_x86_64-x86_64 4684680 2 174.12% 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-426827.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/426827.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 0678678 4 105.98% Linux-2.6.9-34.ELsmp_x86_64-x86_64 3678675 4 216.61% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-426827.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/426827.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/426827.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-1606) derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation
[ http://issues.apache.org/jira/browse/DERBY-1606?page=all ] Myrna van Lunteren updated DERBY-1606: -- Summary: derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation (was: derbyrunjartest hangs with wctme5.7 always uses j9_13) And now that I've got a foundation run going, I found this test hangs with that jvm. I think it is because the test does not pass on required properties, and again, it's trying to run j9_13, which is not correct wctme5.7_foundation, we need j9_foundation. For info, this is the process that I think is hanging: myrna 6100 4564 0 06:28:43 xyz 0:00 j9 -Duser.language=en -Duser.country=US -Xbootclasspath/a:null -jar C:/p4/p4main/opensource/jars/insane/derbyrun.jar ij --help Note the -Xbootclasspath/a:null. The output shows it did try to get going; derbyrunjartest.tmp shows: ij --help: I suggest we stop this test from running with these jvms until the problem can be addressed. derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation --- Key: DERBY-1606 URL: http://issues.apache.org/jira/browse/DERBY-1606 Project: Derby Issue Type: Test Affects Versions: 10.0.2.0 Reporter: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 derbyrunjartest hangs with wctme5.7. I am not sure what the hook up is but if I do this: j9 -jcl:max -Xbootclasspath/p:c:/wctme5.7/ive/lib/jclMax/classes.zip;c:/wctme5.7/ive/lib/charconv.zip;c:/wctme5.7/ive/lib/database_enabler.jar -jar c:/derbyt/svn2/trunk/jars/sane/derbyrun.jar ij --help I get successfully: Usage: java org.apache.derby.tools.ij [-p propertyfile] [-ca connectionAttribute PropertyFile] [inputfile] Also, when looking at the code of this test, it forces the jvm class to be used to be j9_13 whenever the jvm as set in RunTest starts with J9. However, wctme5.7 is j9_22 and this also prevents running with foundation (assuming that's supported). -- 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-1606) derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation
[ http://issues.apache.org/jira/browse/DERBY-1606?page=all ] Myrna van Lunteren updated DERBY-1606: -- Derby Info: [Patch Available] derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation --- Key: DERBY-1606 URL: http://issues.apache.org/jira/browse/DERBY-1606 Project: Derby Issue Type: Test Affects Versions: 10.0.2.0 Reporter: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-1606_20060730_skip.diff derbyrunjartest hangs with wctme5.7. I am not sure what the hook up is but if I do this: j9 -jcl:max -Xbootclasspath/p:c:/wctme5.7/ive/lib/jclMax/classes.zip;c:/wctme5.7/ive/lib/charconv.zip;c:/wctme5.7/ive/lib/database_enabler.jar -jar c:/derbyt/svn2/trunk/jars/sane/derbyrun.jar ij --help I get successfully: Usage: java org.apache.derby.tools.ij [-p propertyfile] [-ca connectionAttribute PropertyFile] [inputfile] Also, when looking at the code of this test, it forces the jvm class to be used to be j9_13 whenever the jvm as set in RunTest starts with J9. However, wctme5.7 is j9_22 and this also prevents running with foundation (assuming that's supported). -- 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-1606) derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation
[ http://issues.apache.org/jira/browse/DERBY-1606?page=all ] Myrna van Lunteren updated DERBY-1606: -- Attachment: DERBY-1606_20060730_skip.diff Attaching a patch to make test derbyrunjartest get skipped for j9 and j9_foundation. Interim solution. derbyrunjartest hangs with wctme5.7 always uses j9_13; hangs with _foundation --- Key: DERBY-1606 URL: http://issues.apache.org/jira/browse/DERBY-1606 Project: Derby Issue Type: Test Affects Versions: 10.0.2.0 Reporter: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-1606_20060730_skip.diff derbyrunjartest hangs with wctme5.7. I am not sure what the hook up is but if I do this: j9 -jcl:max -Xbootclasspath/p:c:/wctme5.7/ive/lib/jclMax/classes.zip;c:/wctme5.7/ive/lib/charconv.zip;c:/wctme5.7/ive/lib/database_enabler.jar -jar c:/derbyt/svn2/trunk/jars/sane/derbyrun.jar ij --help I get successfully: Usage: java org.apache.derby.tools.ij [-p propertyfile] [-ca connectionAttribute PropertyFile] [inputfile] Also, when looking at the code of this test, it forces the jvm class to be used to be j9_13 whenever the jvm as set in RunTest starts with J9. However, wctme5.7 is j9_22 and this also prevents running with foundation (assuming that's supported). -- 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-1462) Test harness incorrectly catches db.lck WARNINGS generated during STORE tests and lists the tests as failed in *_fail.txt.
[ http://issues.apache.org/jira/browse/DERBY-1462?page=all ] Myrna van Lunteren updated DERBY-1462: -- Attachment: DERBY-1462_102_20060730.diff Fixing a problem in the previous patch with this one - DERBY-1462_20060730.diff. The test store/streamingColumn.java would fail because shortbanner was not found - fixed up the build.xml. Lesson to self... Test harness incorrectly catches db.lck WARNINGS generated during STORE tests and lists the tests as failed in *_fail.txt. -- Key: DERBY-1462 URL: http://issues.apache.org/jira/browse/DERBY-1462 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.1.2.5, 10.1.2.4, 10.1.2.3, 10.1.2.2, 10.1.2.1, 10.1.3.0, 10.1.3.1 Environment: IBM 1.3.1 JRE for LINUX (and possibly other JRE 1.3.1 environments) Reporter: Stan Bradbury Assigned To: Myrna van Lunteren Priority: Minor Attachments: DERBY-1462_102_20060713.diff, DERBY-1462_102_20060713.stat, DERBY-1462_102_20060730.diff The following store tests from derbyall do not shutdown cleanly so leave the db.lck file on disk. This is OK! It is done by design to test recovery. THE PROBLEM, when run on Linux using IBM JRE 1.3.1 sp 10 the test harness 'sees' the warnings and lists the tests as having failed. The harness should ignore this warnings as the tests proceed and complete cleanly. Tests INCORRECLTY reported as failed: derbyall/derbynetclientmats/derbynetmats.fail:stress/stress.multi derbyall/derbynetmats/derbynetmats.fail:stress/stress.multi derbyall/storeall/storeall.fail:storetests/st_1.sql derbyall/storeall/storeall.fail:unit/recoveryTest.unit erbyall/storeall/storeall.fail:store/LogChecksumRecovery.java derbyall/storeall/storeall.fail:store/LogChecksumRecovery1.java erbyall/storeall/storeall.fail:store/MaxLogNumberRecovery.java derbyall/storeall/storeall.fail:store/oc_rec1.java derbyall/storeall/storeall.fail:store/oc_rec2.java derbyall/storeall/storeall.fail:store/oc_rec3.java derbyall/storeall/storeall.fail:store/oc_rec4.java derbyall/storeall/storeall.fail:store/dropcrash.java derbyall/storeall/storeall.fail:store/dropcrash2.java Example Error message: WARNING: Derby (instance FILTERED-UUID) is attempting to boot the database csf:/local1/131TST/Store1/storeall/storerecovery/storerecovery/wombat even though Derby (instance FILTERED-UUID) may still be active. Only one instance of Derby should boot a database at a time. Severe and non-recoverable corruption can result and may have already occurred. -- 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-1547) Add svn version number to DatabaseMetaData getDatabaseProductVersion and getDriverVersion() to improve supportability
[ http://issues.apache.org/jira/browse/DERBY-1547?page=all ] Kathey Marsden updated DERBY-1547: -- Urgency: Normal (was: Low) Changing this to Normal Urgency. It would be a huge supportability improvement, and can only happen in a feature release, so it would be good to get in now. Add svn version number to DatabaseMetaData getDatabaseProductVersion and getDriverVersion() to improve supportability --- Key: DERBY-1547 URL: http://issues.apache.org/jira/browse/DERBY-1547 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.1.3.2 Reporter: Kathey Marsden Priority: Minor Fix For: 10.2.0.0 getDatabaseProductVersion and getDriverVersion() report only the four digit Derby version number and not the svn build number. It would be useful to return the full version including the build number as sysinfo does: e.g. 10.1.2.4 - (392472), That way it will be clear from application logs that collect this information exactly what revision level they are running if they are using rolled up fixes on the maintenance branch between releases. There may be risk in doing this however if applications are parsing the version information, but hopefully they will use getDatabaseMajorVersion() , getDatbaseMinorVersion, getDriverMajorVersion, and getDriverMinorVersion for such proccessing. -- 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-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on
[
http://issues.apache.org/jira/browse/DERBY-1327?page=comments#action_12424398 ]
Kathey Marsden commented on DERBY-1327:
---
APAR link for tracking:
http://www-1.ibm.com/support/docview.wss?uid=swg1IY86935
Identity column can be created with wrong and very large start with value
with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on
--
Key: DERBY-1327
URL: http://issues.apache.org/jira/browse/DERBY-1327
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.1.2.4, 10.2.0.0
Reporter: Kathey Marsden
Assigned To: Mamta A. Satoor
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.5
Attachments: Derby1327WrongStartKeyPatch1CodelineTrunk.txt,
Derby1327WrongStartKeyPatch1SvnDiff101.txt,
Derby1327WrongStartKeyPatch1SvnStat101.txt
Using the following JRE with JIT on an identity column may be created with a
wrong and very large START WITH value. When the problem occurs it affects
not only the table being created, but also other tables that were created in
previous transactions.
For example attempting to create 1000 tables with identity columns the 126th
table creation changes the start with value in sys.syscolumns to
41628850257395713 for ALL 125 tables. Attempts to insert into any of the
tables cause
SQL Exception: A truncation error was encountered trying to
shrink ... to length 12.
This program will create up to 1000 tables until the problem
occurs
Note:
- The problem does not occur with -Xnojit (JIT OFF)
- The problem, when it occurs, changes not only the table being
created but all previous tables created. See output below.
Every thing was fine up until mytable126 and then all the
tables got changed to start with 41628850257395713
- Problem occurs with autocommit on/off.
- The problem occurs after the create table but before the
commit.
- If the non-identity columns are removed the problem does not
reproduce.
import java.sql.DatabaseMetaData;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import java.sql.DriverManager;
public class BadStartWith
{
public static void main (String args [])throws Exception
{
testBadStartWith();
}
/**
* After some number of table creations with JIT turned on, the START
WITH value
* for the table being created and all the ones already created gets
mysteriously
* changed with pwi32dev-20060412 (SR2)
*
* @throws Exception
*/
public static void testBadStartWith() throws Exception
{
Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance();
Connection conn =
DriverManager.getConnection(jdbc:derby:wombat;create=true);
conn.setAutoCommit(false);
Statement stmt = null;
DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
System.out.println(md.getDriverName());
dropAllAppTables(conn);
System.out.println(Create tables until we get a wrong Start
with value);
stmt = conn.createStatement();
// numBadStartWith will be changed if any columns get a bad
start with value.
int numBadStartWith = 0;
try {
// create 1000 tables. Break out if we get a table
that has a bad
// start with value.
for (int i = 0; (i 1000) (numBadStartWith == 0);
i++)
{
String tableName = APP.MYTABLE + i;
String createTableSQL = CREATE TABLE + tableName
+ (ROLEID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 2,
INCREMENT BY 1), INSTANCEID INTEGER, STATUS INTEGER, LOGICAL_STATE INTEGER,
LSTATE_TSTAMP TIMESTAMP, UPDT_TSTAMP TIMESTAMP, TSTAMP TIMESTAMP,
CLALEVEL1_CLALEVEL2_CLALEVEL2ID VARCHAR(255),
CLALEVEL1_CLALEVEL2_CLALEVEL3_CLALEVEL3ID VARCHAR(255));
stmt.executeUpdate(createTableSQL);
System.out.println(createTableSQL);
System.out.println(Check before commit);
numBadStartWith = checkBadStartWithCols(conn,2);
conn.commit();
System.out.println(Check after commit);
numBadStartWith = checkBadStartWithCols(conn,2);
if (numBadStartWith 0)
[jira] Commented: (DERBY-1280) Derby throws ERROR XSDG1: Page could not be written to disk, please check if disk is full when there is 20+ gigs of free space ibm 1.5 JVM
[ http://issues.apache.org/jira/browse/DERBY-1280?page=comments#action_12424403 ] Kathey Marsden commented on DERBY-1280: --- If it has been confirmed as a bug, you should be able to get an APAR number which can easily be tracked from the public IBM website. See DERBY-1327 for an example . Derby throws ERROR XSDG1: Page could not be written to disk, please check if disk is full when there is 20+ gigs of free space ibm 1.5 JVM Key: DERBY-1280 URL: http://issues.apache.org/jira/browse/DERBY-1280 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.2.1 Environment: Environment: IBM ThinkCentre, pentium 4, 1 gig memory, 40 gigs of disk Redhat Linux rel 3. IBM Java 1.5 Reporter: Justin Hill Attachments: Limits.java -- Java Information -- Java Version:1.5.0 Java Vendor: IBM Corporation Java home: /opt/ibm/java2-i386-50/jre Java classpath: /home/jhills/JazzDev0411/org.apache.derby.core/derby.jar:/home/jhills/JazzDev0411/org.apache.derby.core/derbyclient.jar:/home/jhills/JazzDev0411/org.apache.derby.core/derbytools.jar:/home/jhills/JazzDev0411/org.apache.derby.core/derbynet.jar OS name: Linux OS architecture: x86 OS version: 2.4.21-37.EL Java user name: jhills Java user home: /home/jhills Java user dir: /home/jhills/JazzDev0411/org.apache.derby.core java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [/home/jhills/JazzDev0411/org.apache.derby.core/derby.jar] 10.1.2.1 - (330608) [/home/jhills/JazzDev0411/org.apache.derby.core/derbyclient.jar] 10.1.2.1 - (330608) [/home/jhills/JazzDev0411/org.apache.derby.core/derbytools.jar] 10.1.2.1 - (330608) [/home/jhills/JazzDev0411/org.apache.derby.core/derbynet.jar] 10.1.2.1 - (330608) -- - Locale Information - -- We are an IBM project that is using Derby and we need a solution or a workaround to this problem. The Derby error is thrown after about 3 hours of running the application which involves a large number of inserts to the database. Even though it is not easy to provide a way to reproduce the error , we can easily reproduce it and are we are willing to work with anyone to assist in finding a solution to this problem. This issue seems to be related to a previously reported issue Derby-151. We are running with autocommit off. It appears that the XSDG1 error is in response to a java.io.IOException being thrown by the native method length in java.io.RandomAccessFile.It always seems to happen while trying to write page #65536 to disk. Below is the derby.log file. 2006-04-28 14:07:03.389 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.1.2.1 - (330608): instance c013800d-010a-e0d2-ba43-0016c308 on database directory /home/jhills/magnolia-runtime/teamRepositoryDB Database Class Loader started - derby.database.classpath='' 2006-04-28 17:26:22.961 GMT Thread[Worker-1,5,main] (XID = 1707467), (SESSIONID = 0), (DATABASE = /home/jhills/magnolia-runtime/teamRepositoryDB), (DRDAID = null), Cleanup action starting 2006-04-28 17:26:22.961 GMT Thread[Worker-1,5,main] (XID = 1707467), (SESSIONID = 0), (DATABASE = /home/jhills/magnolia-runtime/teamRepositoryDB), (DRDAID = null), Failed Statement is: insert into core.content_storage values (?, ?, ?, ?, ?, ?) ERROR XSDG1: Page Page(65536,Container(0, 17488)) could not be written to disk, please check if disk is full. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.data.CachedPage.writePage(Unknown Source) at org.apache.derby.impl.store.raw.data.CachedPage.createIdentity(Unknown Source) at org.apache.derby.impl.services.cache.CachedItem.takeOnIdentity(Unknown Source) at org.apache.derby.impl.services.cache.Clock.addEntry(Unknown Source) at org.apache.derby.impl.services.cache.Clock.create(Unknown Source) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(Unknown Source) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(Unknown Source) at
Re: [jira] Commented: (DERBY-1608) Execution of builtin functions by a user who is not the owner of system schemas gives NPE when authentication and SQL authorization are on.
On 7/29/06, Satheesh Bandaram (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1608?page=comments#action_12424334 ] Satheesh Bandaram commented on DERBY-1608: -- Deepa, I did not realize you had this defect assigned to you, until after I assigned it myself. If you want to fix it yourself, feel free to assign it back to yourself. Otherwise, I can take care of it. Thanks Satheesh for picking this up. I had picked it up as I had found it during upgrade testing and thought I will look a bit into the code in this area. Please go ahead with your proposed fix. Thanks, Deepa
[jira] Commented: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger
[ http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12424405 ] Deepa Remesh commented on DERBY-1435: - Yes. This issue occurs when using the same statement (that was used before dropping the database object referenced in the trigger's action statement). Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger Key: DERBY-1435 URL: http://issues.apache.org/jira/browse/DERBY-1435 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.0.0 Reporter: Deepa Remesh Attachments: repro1435.sql, repro1435_for_functions.sql This exception occurs in the following case: 1. Create tables t1 and t2. Create a trigger on t2 whose triggering action is to insert a row into t1 2. Insert a value v1 into t2. Verify the trigger was fired by looking at contents of t1. 3. Drop table t1. 4. Insert a value v2 into t2. This will give an exception to indicate that table t1 does not exist. 5. Insert the same value v1 into t2. Instead of the exception in Step 4, this gives ERROR XSAI2: The conglomerate (896) requested does not exist. 6. Re-create table t1. 7. Insert v2 into t2. This succeeds. 8. Try to insert the problem value v1 into t2. This still gives ERROR XSAI2: The conglomerate (896) requested does not exist. 9. Shutdown and reconnect to the database. Try to insert the problem value v1 into t2. Now this succeeds. So the exception occurs only in the specific case where we try to insert the same value that we had inserted before dropping the table referenced by the trigger. I'll attach a sql script to repro 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
[jira] Commented: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=comments#action_12424411 ] Kathey Marsden commented on DERBY-815: -- My review comment about hiding CliParam and handling of clearing parameters etc from DRDAConnThread is my only comment for now on this patch. I do not really have my head around all the cases and handling for parameter setting and clearing etc, so look forward to hearing review comments from others on the patch to understand better. My feeble mind might also be able to sort it out better once this change is made. Can we uncheck patch available or would you like more comments on this version? Also I wanted to mention that if you have higher urgency items for 10.2, don't feel compelled to jump on changing this right away. It could easily go into the maintenance branch after releas. I just picked it up as my patch for the week. Thanks Kathey Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Issue Type: Sub-task Components: Network Server, Performance Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.0.2.2 Reporter: Knut Anders Hatlen Assigned To: Dyre Tjeldvoll Priority: Minor Fix For: 10.2.0.0 Attachments: d815_regress.diff, d815_regress.java, derby-815.diff, derby-815.html, derby-815.v3.diff, derby-815.v3.html, derby-815.v3.stat, derby-815.v4.diff, derby-815.v4.stat, derby-815_2.diff, derbyall_report.v4.txt, derbyall_report_with_jdk1.4.v3.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- 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-1543) Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when obje
[ http://issues.apache.org/jira/browse/DERBY-1543?page=comments#action_12424412 ] Mamta A. Satoor commented on DERBY-1543: Satheesh, I ran the upgrade test (upgradeTests/Upgrade_10_1_10_2.java) on a clean client and the test failed. It has following stack trace SQLSTATE(XSAI2):ERROR XSAI2: The conglomerate (-1) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:394) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315) at org.apache.derby.impl.sql.catalog.TabInfoImpl.getRow(TabInfoImpl.java:794) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropTablePermDescriptor(DataDictionaryImpl.java:2509) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropAllTableAndColPermDescriptors(DataDictionaryImpl.java:2416) at org.apache.derby.impl.sql.execute.DropTableConstantAction.executeConstantAction(DropTableConstantAction.java:219) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:357) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) at org.apache.derbyTesting.functionTests.tests.jdbcapi.metadata_test.runTest(metadata_test.java:1192) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runMetadataTest(UpgradeTester.java:900) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runPhase(UpgradeTester.java:367) at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runUpgradeTests(UpgradeTester.java:314) at org.apache.derbyTesting.functionTests.tests.upgradeTests.Upgrade_10_1_10_2.main(Upgrade_10_1_10_2.java:43) Could this be related to your recent changes for dropping the permission descriptors associated with a table? If not, may be I should open a new jira for upgrade test failure. ps I have been out of the loop for last couple days because my laptop died on Thursday. So I hope this is not a known issue and there is already somebody working on it. Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when objects they cover are dropped. Key: DERBY-1543 URL: http://issues.apache.org/jira/browse/DERBY-1543 Project: Derby Issue Type: Sub-task Components: SQL Affects Versions: 10.2.0.0 Reporter: Satheesh Bandaram Assigned To: Satheesh Bandaram Fix For: 10.2.0.0 Attachments: DERBY-1543.out, Derby1543.diff Address two remaining sub-tasks: Add warning when sqlAuthorization is on with authentication off: This is a precautionary warning, since sqlAuthorization doesn't mean much without authentication being ON. Drop permission descriptors when objects they cover are dropped: This applies to tables, routines. When these objects are dropped, automatically drop their permisson descriptors. -- 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-1543) Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when obje
[ http://issues.apache.org/jira/browse/DERBY-1543?page=comments#action_12424413 ] Mamta A. Satoor commented on DERBY-1543: syscat.sql is failing when run with framework as DerbyNetClient. Seems like it might be just a master update issue. I ran the test with Sun jdk1.4 on Windows XP machine as follows java -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest lang/syscat.sql Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when objects they cover are dropped. Key: DERBY-1543 URL: http://issues.apache.org/jira/browse/DERBY-1543 Project: Derby Issue Type: Sub-task Components: SQL Affects Versions: 10.2.0.0 Reporter: Satheesh Bandaram Assigned To: Satheesh Bandaram Fix For: 10.2.0.0 Attachments: DERBY-1543.out, Derby1543.diff Address two remaining sub-tasks: Add warning when sqlAuthorization is on with authentication off: This is a precautionary warning, since sqlAuthorization doesn't mean much without authentication being ON. Drop permission descriptors when objects they cover are dropped: This applies to tables, routines. When these objects are dropped, automatically drop their permisson descriptors. -- 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 426890 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 426890/2006-07-30 17:02:28 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 4684680 2 145.61% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-426890.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/426890.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/426890.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-1543) Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when
This should be mine... I will take a look.SatheeshOn 7/30/06, Mamta A. Satoor (JIRA) derby-dev@db.apache.org wrote:[ http://issues.apache.org/jira/browse/DERBY-1543?page=comments#action_12424412 ]Mamta A. Satoor commented on DERBY-1543:Satheesh, I ran the upgrade test (upgradeTests/Upgrade_10_1_10_2.java) on a clean client and the test failed. It has following stack trace SQLSTATE(XSAI2):ERROR XSAI2: The conglomerate (-1) requested does not exist.at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304)at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate (RAMTransaction.java:394)at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315)at org.apache.derby.impl.sql.catalog.TabInfoImpl.getRow(TabInfoImpl.java:794) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropTablePermDescriptor(DataDictionaryImpl.java:2509)at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropAllTableAndColPermDescriptors (DataDictionaryImpl.java:2416)at org.apache.derby.impl.sql.execute.DropTableConstantAction.executeConstantAction(DropTableConstantAction.java:219)at org.apache.derby.impl.sql.execute.MiscResultSet.open (MiscResultSet.java:56)at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:357)at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java :1181)at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584)at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)at org.apache.derbyTesting.functionTests.tests.jdbcapi.metadata_test.runTest (metadata_test.java:1192)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runMetadataTest(UpgradeTester.java :900)at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runPhase(UpgradeTester.java:367)at org.apache.derbyTesting.functionTests.tests.upgradeTests.UpgradeTester.runUpgradeTests (UpgradeTester.java:314)at org.apache.derbyTesting.functionTests.tests.upgradeTests.Upgrade_10_1_10_2.main(Upgrade_10_1_10_2.java:43)Could this be related to your recent changes for dropping the permission descriptors associated with a table? If not, may be I should open a new jira for upgrade test failure. ps I have been out of the loop for last couple days because my laptop died on Thursday. So I hope this is not a known issue and there is already somebody working on it. Address two remaining issues with GRANT/REVOKE functionality: 1) Add warning when sqlAuthorization is on with authentication off 2) Drop permission descriptors when objects they cover are dropped. Key: DERBY-1543 URL: http://issues.apache.org/jira/browse/DERBY-1543 Project: DerbyIssue Type: Sub-taskComponents: SQL Affects Versions: 10.2.0.0Reporter: Satheesh Bandaram Assigned To: Satheesh Bandaram Fix For: 10.2.0.0 Attachments: DERBY-1543.out, Derby1543.diff Address two remaining sub-tasks: Add warning when sqlAuthorization is on with authentication off: This is a precautionary warning, since sqlAuthorization doesn't mean much without authentication being ON. Drop permission descriptors when objects they cover are dropped: This applies to tables, routines. When these objects are dropped, automatically drop their permisson descriptors.--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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[ http://issues.apache.org/jira/browse/DERBY-1516?page=all ]
Kathey Marsden updated DERBY-1516:
--
Derby Info: [Patch Available]
Inconsistent behavior for getBytes and getSubString for embedded versus
network
---
Key: DERBY-1516
URL: http://issues.apache.org/jira/browse/DERBY-1516
Project: Derby
Issue Type: Bug
Components: JDBC
Reporter: Craig Russell
Priority: Minor
Attachments: DERBY-1516.patch, DERBY-1516.patch
org.apache.derby.client.am.Clob.getSubString(pos, length) and
org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for
less than zero.
if ((pos = 0) || (length 0)) {
throw new SqlException(agent_.logWriter_, Invalid position
+ pos + or length + length);
But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and
org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less
than or equal to zero.
if (length = 0)
throw Util.generateCsSQLException(
SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
The specification does not disallow length of zero, so zero length should be
allowed. I believe that the implementation in org.apache.derby.client.am is
correct, and the implementation in org.apache.derby.impl.jdbc is incorrect.
--
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 426908 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 426908/2006-07-30 20:13:10 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 4684680 2 159.89% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-426908.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/426908.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/426908.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[ http://issues.apache.org/jira/browse/DERBY-1516?page=all ]
Kathey Marsden updated DERBY-1516:
--
Derby Info: (was: [Patch Available])
Thanks Craig for the patch and thanks for volunteering for 10.2. You bring us
up to 43 contributors. I hope we make 50 #:)
The code change looks good.
For the test
- I think it would be good to test both 0 and -1 length.
- I think we need a full derbyall run with the patch in case other tests are
affected. I noticed with DerbyNetClient framework the blobclob4BLOB test
fails with
753 del
EXPECTED SQLSTATE(XJ071): Zero or negative length argument '-76' passed in a
BLOB or CLOB method.
753a753,754
EXPECTED SQLSTATE(XJ071): Negative length argument '-76' passed in a BLOB or
CLOB method.
EXPECTED SQLSTATE(XJ071): Negative length argument '-1' passed in a BLOB or
CLOB method.
Test Failed.
*** End: blobclob4BLOB jdk1.4.2_07 DerbyNetClient 2006-07-30 14:14:40 ***
I think the output is expected but the master needs to be updated, which is a
necessary pain with our diff based harness.
I see the following masters for blobclob4BLOB
./blobclob4BLOB.out
./DerbyNet/blobclob4BLOB.out
./DerbyNetClient/blobclob4BLOB.out
For DerbyNet some folks don't test with that framework. If you don't please
just make a not when you submit the patch that there is a master there that may
need to be updated. Also please assign yourself if you are working actively on
this issue. It is always confusing when there are patches on unassigned issues
because it is not really clear whether the patch author intends to pursue the
fix furthur.
Thanks
Kathey
Inconsistent behavior for getBytes and getSubString for embedded versus
network
---
Key: DERBY-1516
URL: http://issues.apache.org/jira/browse/DERBY-1516
Project: Derby
Issue Type: Bug
Components: JDBC
Reporter: Craig Russell
Priority: Minor
Attachments: DERBY-1516.patch, DERBY-1516.patch
org.apache.derby.client.am.Clob.getSubString(pos, length) and
org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for
less than zero.
if ((pos = 0) || (length 0)) {
throw new SqlException(agent_.logWriter_, Invalid position
+ pos + or length + length);
But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and
org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less
than or equal to zero.
if (length = 0)
throw Util.generateCsSQLException(
SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
The specification does not disallow length of zero, so zero length should be
allowed. I believe that the implementation in org.apache.derby.client.am is
correct, and the implementation in org.apache.derby.impl.jdbc is incorrect.
--
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
[
http://issues.apache.org/jira/browse/DERBY-1516?page=comments#action_12424448 ]
Craig Russell commented on DERBY-1516:
--
Hi Kathey,
Thanks for the feedback on the patch. A few notes:
1. I've added myself to the derby-developers list so I can assign the issue to
myself.
2. The differences in the master blobclob4BLOB.out files shows the
inconsistency of the behaviors quite nicely.
3. I can update the master blobclob4BLOB.out files once we agree what we should
test. What I understand from you is that you would like to see lengths of 0,
-1, and -76 tested, and the master files updated. But the tests in question
clobTest6 and blobTest6 are negative tests that look for exceptions. It's not
clear to me that the test for 0 (which works for the network case) should be
tested here.
4. I noticed an unusual comment in clobTest6:
// 0 or negative position value
if (isDerbyNet)
System.out.println( negative tests for
clob.getSubstring won't run for network server until 5243 is fixed);
Can you translate this? What's a 5243?
Thanks,
Craig
Inconsistent behavior for getBytes and getSubString for embedded versus
network
---
Key: DERBY-1516
URL: http://issues.apache.org/jira/browse/DERBY-1516
Project: Derby
Issue Type: Bug
Components: JDBC
Reporter: Craig Russell
Priority: Minor
Attachments: DERBY-1516.patch, DERBY-1516.patch
org.apache.derby.client.am.Clob.getSubString(pos, length) and
org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for
less than zero.
if ((pos = 0) || (length 0)) {
throw new SqlException(agent_.logWriter_, Invalid position
+ pos + or length + length);
But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and
org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less
than or equal to zero.
if (length = 0)
throw Util.generateCsSQLException(
SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
The specification does not disallow length of zero, so zero length should be
allowed. I believe that the implementation in org.apache.derby.client.am is
correct, and the implementation in org.apache.derby.impl.jdbc is incorrect.
--
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Craig Russell (JIRA) wrote: 2. The differences in the master blobclob4BLOB.out files shows the inconsistency of the behaviors quite nicely. Yes I think analyzing (and eliminating) the master differences for client and embedded would be a great task associated with DERBY-310. 3. It's not clear to me that the test for 0 (which works for the network case) should be tested here. Yes I agree. Now that it is a positive case for both drivers it probably should be tested somewhere else. 4. I noticed an unusual comment in clobTest6: // 0 or negative position value if (isDerbyNet) System.out.println( negative tests for clob.getSubstring won't run for network server until 5243 is fixed); Can you translate this? What's a 5243? 5243 was a JCC bug with this description. JCC clob.getSubString() with a zero negative position or length argument gives a string index out of range exception It was marked fixed 3/23/2004 but unfortunately doesn't say exactly what version that was. I don't have access to the JCC bug database anymore, we'd just have to try and see if it is fixed for JCC 2.4 which is what the master is based on. Kathey
Re: [jira] Commented: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Craig Russell (JIRA) wrote: what we should test. One interesting test with 0 length is the case for getSubString(1,0) for a zero length lob. Should it throw an exception or return a zero length string? Kathey
In Derby SQL Authorization, is drop view the only way to drop a view created by a dba? Will revoke privilege ever drop such a view?
Hi, With Derby SQL Authorization, there are 2 ways a view can get dropped automatically provided it is created by a non-dba user1)drop view command - issued either by the dba or the view owner2)revoke privilege - if the privilege being revoked is required by the view, then view will be dropped automatically I have been thinking about some view testing and wrote a test case where the dba creates a view in a schema owned by some other user and the view is accessing objects from couple different schemas on which the view's schema owner doesn't have access to. The view creation from dba doesn't fail because dba can access any object in any schema and can create any object in any schema. For such a view created by the dba, it looks like the only way to drop that view will be through drop view either by dba or the schema owner. No revoke privilege can cause the view created by dba to drop automatically. This logically sounds correct but I wanted to run it by the community to see if this is the correct behavior. Any Comments on the behavior? Here is an example demonstrating the case above-- View tests-- Let the dba(satConnection) create a view in schema mamta2 (owned by user mamta2). The view's definition accesses -- objects from schema mamta1. The owner of schema mamta2 does not have access to objects in schema mamta1 -- but the create view by dba does not fail because dba has access to all the objects. -- mamta2 will have access to the view created by the dba because mamta2 is owner of the schema mamta2 and -- it has access to all the objects created in it's schema, whether they were created by mamta2 or the dba. -- Any other user (except the dba) will need to get explicit select privileges on the view in order to access it --set connection mamta1;-- Note that mamta1 is creating couple tables but has not granted permissions on those tables to anyonecreate table t11ViewTest (c111 int not null primary key);create table t12ViewTest (c121 int, c122 char); set connection mamta2;-- create an object so that user mamta2 will become owner of the schema mamta2. If I don't do this, dba will-- become owner of schema mamta2 with the create view sql belowcreate table t21ViewTest (c211 int, c212 char); -- connect as dbaset connection satConnection;-- dba is creating a view in schema owned by another user. dba can create objects anywhere and access objects from anywhere-- Notice that user mamta2 does not have access to objects accessed by view below create view mamta2.v21ViewTest as select t1.c111, t2.c122 from mamta1.t11ViewTest as t1, mamta1.t12ViewTest as t2;-- dba can do select from that viewselect * from mamta2.v21ViewTest;set connection mamta2; -- the schema owner can do a select from an object that is part of it's schema even though it was created by the dbaselect * from v21ViewTest; Note that the only way to drop view v21ViewTest will be via drop view issued either by user mamta2 or the dba. Thanks,Mamta
[jira] Created: (DERBY-1611) As per the functional spec attached to DERBY-1330, a view should be dropped when a privilege required by the view is revoked.
As per the functional spec attached to DERBY-1330, a view should be dropped when a privilege required by the view is revoked. - Key: DERBY-1611 URL: http://issues.apache.org/jira/browse/DERBY-1611 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Mamta A. Satoor Fix For: 10.2.0.0 A view tracks its privileges requirements using Derby's Dependency Manager. If any one of those required privileges are revoked, the view should be dropped automatically. I am just creating a new jira entry here so it is easier to track sub items of DERBY-1330. Will link this Jira entry to DERBY-1330. -- 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-1612) As per the functional spec attached to DERBY-1330, a constraint should be dropped when a privilege required by the constraint is revoked.
As per the functional spec attached to DERBY-1330, a constraint should be dropped when a privilege required by the constraint is revoked. - Key: DERBY-1612 URL: http://issues.apache.org/jira/browse/DERBY-1612 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assigned To: Mamta A. Satoor Fix For: 10.2.0.0 A constraint tracks its privileges requirements using Derby's Dependency Manager. If any one of those required privileges are revoked, the constraint should be dropped automatically. I am just creating a new jira entry here so it is easier to track sub items of DERBY-1330. Will link this Jira entry to DERBY-1330. -- 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
