Re: Getting the LangaugeConnectionContext
Jazarine Jamal wrote: Hi Dan.. What I actually am trying to do is to get an object's type..i.e. is it a table, view or synonym.. Hello, I'm still a little bit confused. Are you in JDBC-code, or are you modifying Derby's source code? If you are using JDBC to access a database and need to know the type of something, I think the various metadata calls, as specified by the JDBC standard, is the correct way to get what you want. If you are modifying Derby's source code (writing your own extension, changing behavior or similar), then I think you'll have to give more details before anyone can help you in a good way. regards, -- Kristian Thanks.. On 1/21/08, *Daniel John Debrunner* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jazarine Jamal wrote: I have got the Connection object in the function that i need. I want to if its possible to get the activation object related to the current connection. What are you trying to achieve here? Maybe there's some alternate solution that doesn't require the LCC, but it's hard to help unless it's known what problem you want to solve. Dan.
[jira] Updated: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-3301: -- Attachment: derby-3301-1.stat derby-3301-1.diff The attached diff 'derby-3301-1.diff' works in similar fashion as Katheys diff for DERBY-3257 by - marking any subquery in a WHERE clause as such - skip flattening of the subquery on the where subquery condition This diff produces the correct results: snip --- ij(CONNECTION1) select unbound_e.empid, unbound_p.projid from departments this, employees unbound_e, projects unbound_p where exists ( select 1 from employees this_employees_e where exists ( select 1 from project_employees this_employees_e_projects_p where this_employees_e_projects_p.empid = this_employees_e.empid and this_employees_e.department = this.id and unbound_p.projid = this_employees_e_projects_p.projid and unbound_e.empid = this_employees_e.empid) ); EMPID |PROJID --- 11 |101 12 |101 13 |101 12 |102 13 |102 14 |103 15 |103 7 rows selected snip --- Even though the diff works, the condition for skipping flattening should be relaxed to only apply to EXISTS subqueries in a WHERE clause, not *all* subqueries in a where clause as is done in 'derby-3301-1.diff'. Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) ); PERSONID |PROJID --- 3 |1 5 |3 4 |3 2 |1 1 |1 5 rows selected I'm expecting 7 rows to be returned here, one row for each row in the join table. Here's the schema: CREATE TABLE departments ( ID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, EMP_OF_THE_MONTH INTEGER, COMPANYID INTEGER, DISCRIMINATOR VARCHAR(255), CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies, CONSTRAINT DEPTS_PK PRIMARY KEY (ID) ); CREATE TABLE persons ( PERSONID INTEGER NOT NULL, FIRSTNAME VARCHAR(32) NOT NULL, LASTNAME VARCHAR(32) NOT NULL, MIDDLENAME VARCHAR(32), BIRTHDATE TIMESTAMP NOT NULL, ADDRID INTEGER, STREET VARCHAR(64), CITY VARCHAR(64), STATE CHAR(2), ZIPCODE CHAR(5), COUNTRY VARCHAR(64), HIREDATE TIMESTAMP, WEEKLYHOURS REAL, DEPARTMENT INTEGER, FUNDINGDEPT INTEGER, MANAGER INTEGER, MENTOR INTEGER, HRADVISOR INTEGER, SALARY REAL, WAGE REAL, DISCRIMINATOR varchar(255) NOT NULL, CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments, CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES departments, CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons, CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons, CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons, CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID) ); CREATE TABLE projects ( PROJID INTEGER NOT NULL, NAME VARCHAR(32) NOT NULL, BUDGET DECIMAL(11,2) NOT NULL, DISCRIMINATOR VARCHAR(255), CONSTRAINT PROJS_PK PRIMARY KEY (PROJID) ); CREATE TABLE project_member ( PROJID INTEGER REFERENCES projects NOT NULL, MEMBER
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-1b-jdbc_statementcache.stat derby-3324-1b-jdbc_statementcache.diff 'derby-3324-1b-jdbc_statementcache.diff' replaces version 1a. The following has been changed: 1) Removed keys for statements specifying which auto-generated columns to get, as we currently don't support this in the client driver. Handling this area will need some effort (as part of another issue), as we do support the relevant prepareStatement methods if the array specifying the columns to get is null. 2) Added a new key for CallableStatement (CallKey). 3) Renamed factory methods from newInstance to newPrepared, and introduced newCallable. 4) Renamed method in cache from insertStatement to cacheStatement. 5) Various documentation fixes/changes. 6) Chose to throw assert error if closing a statement in the cache fails. For insane builds, the exception will be ignored. I forgot to handle CallableStatement explicitly. The way this is planned now, is to use a separate key for CallableStatements and then cast the PreparedStatement that comes out of the cache; CallableStatement cs = (CallableStatement)cache.getCached(CallKey) I could add more machinery around this, for instance making sure objects inserted with a CallKey is indeed a CallableStatement, but I'm not sure if it is required for code at this level (Derby internal). I do not want to let the cache know too much about what is going on, as it's only there to hold references for objects implementing the PreparedStatement interface. I plan to commit in a few days, and I also expect there will be another patch with some more tests and the required changes for writing the tests. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3330) provide support for unique constraint over nullable columns
[ https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anurag Shekhar updated DERBY-3330: -- Attachment: derby-3330v2.diff I have done some cleanup in this patch. This patch also includes fixes based on the failures in regression tests. I still have failures in regression tests. I will posting another patch after fixing them. This patch has following changes since the last time. 1. Modified IndexRowGenerator to keep the information if this represents an almost unique index. This information is used by IndexChanger to deffer the inserts for update in case of almost unique index (in addition to unique index). 2. Modified BTreeControler.compareLeftAndRightSiblings to use newly introduced methods to get the record at left and right. These two methods check for deleted record and continue to move to previous (in case of right next) record till it finds a valid record. I have also identified the code changed required for soft upgrade (marked with comments) provide support for unique constraint over nullable columns --- Key: DERBY-3330 URL: https://issues.apache.org/jira/browse/DERBY-3330 Project: Derby Issue Type: New Feature Components: Store Affects Versions: 10.4.0.0 Environment: all Reporter: Anurag Shekhar Assignee: Anurag Shekhar Attachments: derby-3330.diff, derby-3330v2.diff Allow unique constraint over nullable field. Right now derby support unique constraint only over not null columns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress
[ https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561263#action_12561263 ] Knut Anders Hatlen commented on DERBY-3323: --- I don't think we can rely on System.gc() actually freeing and finalizing all unreferenced objects. Its javadoc says that calling the method suggests that the Java Virtual Machine expend effort toward recycling unused objects and that it will make a best effort to reclaim space. Calling it in verifyNoOpenResultSets() as a last attempt before failing is OK, I think, since it increases the likelihood of being able to perform the operation successfully. On the other hand, if a test depends on the side-effects from System.gc() in order to pass, I think it will be inherently unstable (as seen in DERBY-1585). It's not a bug that DROP TABLE fails, in my opinion, since JDBC only guarantees that a ResultSet releases its resources when it has been closed, and the test code resembles a user error, as it does not close the ResultSets and holds resources for an unnecessarily long period. I'd suggest that the cleanup code instead closes the connection (which ensures that all its database and JDBC resources are released, according to its javadoc), and performs DROP TABLE in a different connection. ComparisonFailure in derbyStress Key: DERBY-3323 URL: https://issues.apache.org/jira/browse/DERBY-3323 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: jvm1.4 lin jvm1.5 lin, linN+1 vm1.6 sles,sol, solN+1 jvm1.5 w2003 Reporter: Ole Solberg Assignee: Kathey Marsden Priority: Minor See jvm1.4 lin : http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html jvm1.5 lin, jvm1.5 linN+1 : http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html jvm1.5 w2003: http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html 1) derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure: Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- unexpected exception ] at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) at org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561287#action_12561287 ] Knut Anders Hatlen commented on DERBY-3192: --- The server knows which version of the client it talks to. See impl.drda.AppRequester.getClientType()/greaterThanOrEqualTo(). This could be used to decide which kind of reply to send. Similarly, the client knows the version of the server (see NetDatabaseMetadata.computeFeatureSet_()). Cache session data in the client driver --- Key: DERBY-3192 URL: https://issues.apache.org/jira/browse/DERBY-3192 Project: Derby Issue Type: Improvement Components: JDBC, Network Client, Network Server, Performance, SQL Affects Versions: 10.3.1.4 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Attachments: derby-3192-test.fup1.diff, derby-3192-test.fup2.diff, derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff The reason for doing this is to avoid a rather substantial performance hit observed when the client driver is used together with an appserver that uses connection pooling. There are two problems: 1) The connection pool will compare the isolation level it has stored for the connection with the value returned from Connection.getTransactionIsolation() each and every time someone requests a new connection from the pool. 2) The users of the connection pool (ab)use it to avoid having to keep track of their current connection. So each time a query needs to be executed a call to the connection pool's getConnection() method is made. Getting a connection from the connection pool like this also means that a new PreparedStatement must be prepared each time. The net result is that each query results in the following sequence: getConnection() getTransactionIsolation() -- roundtrip + lookup in server's statement cache prepareStatment() -- roundtrip + lookup in server's statement cache executeQuery()-- roundtrip Arguably this is a user error but when suggesting this I'm kindly informed that this works just fine with other datbases (such as PostgreSQL and ORACLE). The reason why it works is that these databases do statement caching in the driver. I've tried to implement a very (too) simple statement cache in Derby's client driver and to re-enable caching of the isolation level (see https://issues.apache.org/jira/browse/DERBY-1148). With these changes I observe a marked performance improvement when running with appserver load. A proper statment cache cannot be implemented without knowing what the current schema is. If the current schema has changed since the statement was prepared, it is no longer valid and must be evicted from the cache. The problem with caching both the isolation level and the current schema in the driver is that both can change on the server without the client detecting it (through SQL and XA and possibly stored procedures). I think this problem can be overcome if we piggy-back the information we would like to cache on messages going back to the client. This can be done by utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume 3, page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD in the reply, I think it would be possible to cache additional session information when this becomes relevant. It would also be possible to use EXCSQLSET to batch session state changes going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Java ME and ToursDB
Vemund Ostgaard wrote: Myrna van Lunteren wrote: Why there is a difference in the number of tests that are run I can't say off the top...I can look into that next week. Is it possible for you to run with -Dderby.tests.trace=true junit.textui.TestRunner or some other mechanism that gets the list of tests, and attach them (or send them to me)? I'll do that. Myrna discovered that the upgrade tests were not run in the weme6.1-nightlies, so that explains the difference in the number of tests run. Case closed. Vemund
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561290#action_12561290 ] Thomas Vatter commented on DERBY-3302: -- Which version do you recommend for deployment? Will 10.3.2.2 be an official release? NullPointerException during recovery of database with territory-based collation --- Key: DERBY-3302 URL: https://issues.apache.org/jira/browse/DERBY-3302 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Priority: Critical Fix For: 10.3.2.2, 10.4.0.0 Attachments: npe.sql When logical undo is performed on a database with territory-based collation, you may get a NullPointerException in SQLChar.getCollationKey() because SQLChar.getLocaleFinder() returns null. This bug was reported on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3254) Implement the replication failover functionality
[ https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561310#action_12561310 ] V.Narayanan commented on DERBY-3254: I ran the tests on this patch and had a clean run of the junit all suite. Implement the replication failover functionality Key: DERBY-3254 URL: https://issues.apache.org/jira/browse/DERBY-3254 Project: Derby Issue Type: Sub-task Components: Replication Reporter: V.Narayanan Assignee: V.Narayanan Attachments: failover_impl_notforcommit.diff, failover_impl_notforcommit.stat, failover_impl_v1.diff, failover_impl_v1.stat, failover_impl_v2.diff, failover_impl_v2.stat, failover_impl_v3.diff, failover_impl_v3.stat, failover_impl_v4.diff, failover_impl_v4.stat, failover_impl_v5.diff, failover_impl_v5.stat, failover_impl_v6.diff, failover_impl_v6.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3340) Add debug target to Netbeans 6.0 project file
Add debug target to Netbeans 6.0 project file - Key: DERBY-3340 URL: https://issues.apache.org/jira/browse/DERBY-3340 Project: Derby Issue Type: Improvement Components: Tools Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Trivial The project.xml file for Netbeans 6.0 is missing a debug target. Whenever 'svn revert' is executed, the debug target needs to be added again to run the NB debugger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3340) Add debug target to Netbeans 6.0 project file
[ https://issues.apache.org/jira/browse/DERBY-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-3340: -- Attachment: d3340-1.stat d3340-1.diff Attached patch adds a debug target to tools/ide/netbeans/6.0/nbproject/project.xml Add debug target to Netbeans 6.0 project file - Key: DERBY-3340 URL: https://issues.apache.org/jira/browse/DERBY-3340 Project: Derby Issue Type: Improvement Components: Tools Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Trivial Attachments: d3340-1.diff, d3340-1.stat The project.xml file for Netbeans 6.0 is missing a debug target. Whenever 'svn revert' is executed, the debug target needs to be added again to run the NB debugger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3340) Add debug target to Netbeans 6.0 project file
[ https://issues.apache.org/jira/browse/DERBY-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Nielsen updated DERBY-3340: -- Derby Info: [Patch Available] Add debug target to Netbeans 6.0 project file - Key: DERBY-3340 URL: https://issues.apache.org/jira/browse/DERBY-3340 Project: Derby Issue Type: Improvement Components: Tools Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Trivial Attachments: d3340-1.diff, d3340-1.stat The project.xml file for Netbeans 6.0 is missing a debug target. Whenever 'svn revert' is executed, the debug target needs to be added again to run the NB debugger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3340) Add debug target to Netbeans 6.0 project file
[ https://issues.apache.org/jira/browse/DERBY-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561318#action_12561318 ] Kristian Waagan commented on DERBY-3340: +1 to commit from me. I can commit tomorrow unless someone objects. Just to make sure I have gotten this right, I understand that this only makes the debug action available. The first time (in a clean trunk) you press the debug button, you still have to generate the actual debug target. This target specifies what is to be run (for instance ij). We could also consider adding a default debug target, for instance running ij. Changing this target is pretty easy when you have the classpath set up. I think doing this would add another file in the repos: nbproject/ide-file-targets.xml. This would however be handled under a separate issue. Add debug target to Netbeans 6.0 project file - Key: DERBY-3340 URL: https://issues.apache.org/jira/browse/DERBY-3340 Project: Derby Issue Type: Improvement Components: Tools Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Trivial Attachments: d3340-1.diff, d3340-1.stat The project.xml file for Netbeans 6.0 is missing a debug target. Whenever 'svn revert' is executed, the debug target needs to be added again to run the NB debugger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3340) Add debug target to Netbeans 6.0 project file
[ https://issues.apache.org/jira/browse/DERBY-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561323#action_12561323 ] Thomas Nielsen commented on DERBY-3340: --- Yes, this only makes the debug action available in the project. You still have to fill in the correct action (i.e classpath) for the debug target in nbproject/ide-file-targets.xml. Add debug target to Netbeans 6.0 project file - Key: DERBY-3340 URL: https://issues.apache.org/jira/browse/DERBY-3340 Project: Derby Issue Type: Improvement Components: Tools Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Trivial Attachments: d3340-1.diff, d3340-1.stat The project.xml file for Netbeans 6.0 is missing a debug target. Whenever 'svn revert' is executed, the debug target needs to be added again to run the NB debugger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3302) NullPointerException during recovery of database with territory-based collation
[ https://issues.apache.org/jira/browse/DERBY-3302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561319#action_12561319 ] Knut Anders Hatlen commented on DERBY-3302: --- I'm not aware of any plans for making an official 10.3 release any time soon. The tentative schedule for the 10.4 release can be found here: http://wiki.apache.org/db-derby/DerbyTenFourRelease If you want to build your own jar files for deployment, I think you're better off with 10.3. If you use the code in the development trunk, you'll probably run into upgrade issues when you switch to an official release later (databases created with trunk are generally not upgradeable). NullPointerException during recovery of database with territory-based collation --- Key: DERBY-3302 URL: https://issues.apache.org/jira/browse/DERBY-3302 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Knut Anders Hatlen Assignee: Mamta A. Satoor Priority: Critical Fix For: 10.3.2.2, 10.4.0.0 Attachments: npe.sql When logical undo is performed on a database with territory-based collation, you may get a NullPointerException in SQLChar.getCollationKey() because SQLChar.getLocaleFinder() returns null. This bug was reported on derby-user: http://thread.gmane.org/gmane.comp.apache.db.derby.user/8253 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561329#action_12561329 ] oysteing edited comment on DERBY-3184 at 1/22/08 4:49 AM: - Error handling in SlaveDatabase looks good, but since ReplicationLogger does not contain any state, I think it would be better to make logError static. Then you would not have to instantiate in every class where you need error handling. It also worries me a bit that you had to import StandardException in DRDAConnThread, but that is probably not your fault. It seems to me that validateSecMecUSRSSBPWD() does things that maybe should have been handled inside the database. Anyway, we should make sure to test this case. That is, try to connect to a slave database using SecMecUSRSSBPWD. A minor issue: In EmbedConnection: No need to cast se, it is already a StandardException. was (Author: oysteing): Error handling in SlaveDatabase looks good, but since ReplicationLogger does not contain any state, I think it would be better to make logError static. Then you would not have to instantiate in every class where you need error handling. It also worries me a bit that you had to import StandardException in DRDAConnThread, but that is probably not your fault. It seems to me that validateSecMecUSRSSBPWD() does things that maybe should have been handled inside the database. Anyway, we should make sure to test this case. That is, try to connect to a slave database using SecMecUSRSSBPWD. A minor issue: In EmbedConnection: No need to case se, it is already a StandardException. Replication: Connection attempts to a database in slave mode must fail -- Key: DERBY-3184 URL: https://issues.apache.org/jira/browse/DERBY-3184 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat When a database 'X' is booted in slave mode, the call to Monitor.startPersistentService(X,...) will not complete because the call gets stuck in LogToFile#recover. This is intentional. For as long as startPersistentService is blocked, however, other threads that try to connect to 'X' (effectively calling Monitor.findService(X, ...)) will also hang. This is unacceptable, and needs to raise an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561329#action_12561329 ] Øystein Grøvlen commented on DERBY-3184: Error handling in SlaveDatabase looks good, but since ReplicationLogger does not contain any state, I think it would be better to make logError static. Then you would not have to instantiate in every class where you need error handling. It also worries me a bit that you had to import StandardException in DRDAConnThread, but that is probably not your fault. It seems to me that validateSecMecUSRSSBPWD() does things that maybe should have been handled inside the database. Anyway, we should make sure to test this case. That is, try to connect to a slave database using SecMecUSRSSBPWD. A minor issue: In EmbedConnection: No need to case se, it is already a StandardException. Replication: Connection attempts to a database in slave mode must fail -- Key: DERBY-3184 URL: https://issues.apache.org/jira/browse/DERBY-3184 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat When a database 'X' is booted in slave mode, the call to Monitor.startPersistentService(X,...) will not complete because the call gets stuck in LogToFile#recover. This is intentional. For as long as startPersistentService is blocked, however, other threads that try to connect to 'X' (effectively calling Monitor.findService(X, ...)) will also hang. This is unacceptable, and needs to raise an error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3325) Add 'maxStatements' property to ClientConnectionPoolDataSource
[ https://issues.apache.org/jira/browse/DERBY-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3325: --- Derby Info: [Patch Available] Add 'maxStatements' property to ClientConnectionPoolDataSource -- Key: DERBY-3325 URL: https://issues.apache.org/jira/browse/DERBY-3325 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3325-1a-maxStatements.diff, derby-3325-1a-maxStatements.stat The classes in Derby implementing javax.sql.ConnectionPoolDataSource must provide setter and getter methods for the property 'maxStatements'. This property is used to control the whether the data source should produce pooled connections with statement cache capabilities or not, and how big the statement cache is allowed to be. This issue only deals with the client JDBC driver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3325) Add 'maxStatements' property to ClientConnectionPoolDataSource
[ https://issues.apache.org/jira/browse/DERBY-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3325: --- Attachment: derby-3325-1a-maxStatements.stat derby-3325-1a-maxStatements.diff 'derby-3325-1a-maxStatements.diff' introduces the maxStatements property for the ClientConnectionPoolDataSource. The property is specified in the JDBC 4.0 standard, chapter 11.8 (don't remember if it was introduced in an earlier revision). Due to the current inheritance hierarchy, and the type being passed around in Derby, I have added the variable itself and the getter method to ClientBaseDataSource. They don't really belong there, but it was the easiest solution to avoid having to cast objects in the factory methods. If people think we should redesign the hierarchy and/or change the factory method signatures, I'm open for suggestions and opinions. I know there has been an earlier effort towards the hierarchy, so I would have to read up on why things were changed before we change something again. Only ClientPooledConnectionDataSource has a setter method. I have not added it to the XADataSource (I could not find any mention of statement pooling for XA in the standard, as I did for connection pooling). Note that the included test is not yet enabled. Patch ready for review. Add 'maxStatements' property to ClientConnectionPoolDataSource -- Key: DERBY-3325 URL: https://issues.apache.org/jira/browse/DERBY-3325 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3325-1a-maxStatements.diff, derby-3325-1a-maxStatements.stat The classes in Derby implementing javax.sql.ConnectionPoolDataSource must provide setter and getter methods for the property 'maxStatements'. This property is used to control the whether the data source should produce pooled connections with statement cache capabilities or not, and how big the statement cache is allowed to be. This issue only deals with the client JDBC driver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3323) ComparisonFailure in derbyStress
[ https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3323: -- Attachment: derby-3323_diff.txt Attached is a patch which incorporates Knut's suggestion to close the connection to cleanup the result sets. (Thanks Knut!). I hope this is acceptable to all. ComparisonFailure in derbyStress Key: DERBY-3323 URL: https://issues.apache.org/jira/browse/DERBY-3323 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: jvm1.4 lin jvm1.5 lin, linN+1 vm1.6 sles,sol, solN+1 jvm1.5 w2003 Reporter: Ole Solberg Assignee: Kathey Marsden Priority: Minor Attachments: derby-3323_diff.txt See jvm1.4 lin : http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html jvm1.5 lin, jvm1.5 linN+1 : http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html jvm1.5 w2003: http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html 1) derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure: Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- unexpected exception ] at org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) at org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Regression Filter (was Re: Blockers and 10.4)
Kathey Marsden wrote: [EMAIL PROTECTED] wrote: Is this query saved as a public filter in Jira? I could not find it. It is the Jira filter Derby Open Product Regressions. I was wondering if a Jira admin could subscribe derby-dev to this filter to get a report once a week. Hi Kathey, I found a filter called Derby Open Regressions. I have subscribed derby-dev to receive a copy of this report every Sunday. Please let me know if that's not what you wanted. Thanks, -Rick
Regression Test Report - Daily 613931 - Sun DBTG
[Auto-generated mail] *Daily* 613931/2008-01-21 18:01:21 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0273273 072.33% derbyall 01015710157 0 1337.69% suitesAll linN+1 1273272 0 103.05% derbyall 01015710157 0 118.48% suitesAll sles 0273273 072.59% derbyall 01015710157 0 863.65% suitesAll sol 0273273 076.16% derbyall NA NA NANA suitesAll solN+1 0273273 097.07% derbyall 01015710157 0 180.62% suitesAll sparc 0273273 065.52% derbyall 01015710157 0 352.96% suitesAll vista 0273273 093.92% derbyall 091359135 066.20% suitesAll w2003 0273273 096.14% derbyall 091359135 0 130.55% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-613931.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/613931_bySig.html *Jvm: 1.5* lin 0274274 071.38% derbyall 084398439 0 878.32% suitesAll linN+1 0274274 0 100.50% derbyall 084398439 0 120.90% suitesAll sles 0274274 070.51% derbyall 084398439 0 568.74% suitesAll sol 0274274 078.01% derbyall 084398439 0 841.56% suitesAll solN+1 0274274 088.00% derbyall 084398439 0 793.02% suitesAll sparc 0274274 066.68% derbyall 084398439 0 693.58% suitesAll vista 0274274 071.43% derbyall 074177417 0 396.24% suitesAll w2003 0274274 074.44% derbyall 074177417 0 257.05% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-613931.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/613931_bySig.html *Jvm: 1.4* lin 0271271 273.10% derbyall 083878387 0 803.11% suitesAll linN+1 0271271 2 101.89% derbyall 083878387 0 115.71% suitesAll sles 0271271 270.31% derbyall 083878387 0 525.45% suitesAll sol 0271271 277.50% derbyall 083878387 0 676.16% suitesAll solN+1 0271271 288.77% derbyall 083878387 0 745.13% suitesAll sparc 0271271 266.79% derbyall 083878387 0 697.43% suitesAll vista 0271271 271.21% derbyall 073657365 0 388.52% suitesAll w2003 0271271 275.38% derbyall 073667366 0 250.20% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-613931.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/613931_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/613931.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (15 issues) Subscriber: derby-dev Key Summary DERBY-3325 Add 'maxStatements' property to ClientConnectionPoolDataSource https://issues.apache.org/jira/browse/DERBY-3325 DERBY-3184 Replication: Connection attempts to a database in slave mode must fail https://issues.apache.org/jira/browse/DERBY-3184 DERBY-3340 Add debug target to Netbeans 6.0 project file https://issues.apache.org/jira/browse/DERBY-3340 DERBY-3254 Implement the replication failover functionality https://issues.apache.org/jira/browse/DERBY-3254 DERBY-3324 JDBC statement cache implementation https://issues.apache.org/jira/browse/DERBY-3324 DERBY-3050 Convert groupBy.sql tests to JUnit and include them in GroupByTest.java https://issues.apache.org/jira/browse/DERBY-3050 DERBY-3205 Replication: Add connection url command options for starting, stopping slave and for failover https://issues.apache.org/jira/browse/DERBY-3205 DERBY-3137 SQL roles: add catalog support https://issues.apache.org/jira/browse/DERBY-3137 DERBY-3088 convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process https://issues.apache.org/jira/browse/DERBY-3088 DERBY-3169 Add documentation for replication https://issues.apache.org/jira/browse/DERBY-3169 DERBY-2871 XATransactionTest gets XaException: Error executing a XAResource.commit(), server returned XAER_PROTO. https://issues.apache.org/jira/browse/DERBY-2871 DERBY-3117 Adjust master build script to require the Java 5 compiler to build Derby https://issues.apache.org/jira/browse/DERBY-3117 DERBY-2953 Dump the information about rollbacks of the global transaction (introduced in DERBY-2220 and DERBY-2432) to derby.log https://issues.apache.org/jira/browse/DERBY-2953 DERBY-3083 Network server demands a file called derbynet.jar in classpath https://issues.apache.org/jira/browse/DERBY-3083 DERBY-3227 Remove final from all getConnection() methods in EmbeddedDataSource https://issues.apache.org/jira/browse/DERBY-3227
Re: Regression Filter (was Re: Blockers and 10.4)
Rick Hillegas wrote: Kathey Marsden wrote: [EMAIL PROTECTED] wrote: Is this query saved as a public filter in Jira? I could not find it. It is the Jira filter Derby Open Product Regressions. I was wondering if a Jira admin could subscribe derby-dev to this filter to get a report once a week. Hi Kathey, I found a filter called Derby Open Regressions. I have subscribed derby-dev to receive a copy of this report every Sunday. Please let me know if that's not what you wanted. That filter does not pick up the issues that are in progress. There is another one Derby Open Product Regressions which looks ok. Derby Open Regressions then can probably be deleted. Kathey
[jira] Updated: (DERBY-3309) Minor cleanups in ClientPooledConnection40 and ClientPooledConnection
[ https://issues.apache.org/jira/browse/DERBY-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3309: --- Attachment: derby-3309-3a-cpc_documentation_changes.diff 'derby-3309-3a-cpc_documentation_changes.diff' changes and adds some documentation for ClientPooledConnection. Would be nice if someone read through it before I commit. Minor cleanups in ClientPooledConnection40 and ClientPooledConnection - Key: DERBY-3309 URL: https://issues.apache.org/jira/browse/DERBY-3309 Project: Derby Issue Type: Sub-task Components: JDBC, Network Client Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Trivial Fix For: 10.4.0.0 Attachments: derby-3309-1a-unused_imports.diff, derby-3309-2a-remove_unused_constructor.diff, derby-3309-3a-cpc_documentation_changes.diff A few minor cleanups: 1) Remove unused constructor 2) Remove unused imports 3) Various documentation/formatting fixes Other minor fixes will be done if required. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561380#action_12561380 ] djd edited comment on DERBY-2109 at 1/22/08 9:12 AM: --- So I think we can agree that a user has a unique identity, can we call this UID? This corresponds to what is stored in the system tables. An alternate way of stating this is: an user identifier has a canonical representation which defines uniqueness within Derby's authorization schemes. When storing the user identifier for a user Derby uses the canonical representation. [the canonical representation seems to be also called the common normal form or CNF in the SQL standard] was (Author: djd): So I think we can agree that a user has a unique identity, can we call this UID? This corresponds to what is stored in the system tables. An alternate way of stating this is: an authorization identifier has a canonical representation which defines uniqueness within Derby's authorization schemes. When storing the authorization identifier for a user Derby uses the canonical representation. [the canonical representation seems to be also called the common normal form or CNF in the SQL standard] System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Assignee: Martin Zaun Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561380#action_12561380 ] Daniel John Debrunner commented on DERBY-2109: -- So I think we can agree that a user has a unique identity, can we call this UID? This corresponds to what is stored in the system tables. An alternate way of stating this is: an authorization identifier has a canonical representation which defines uniqueness within Derby's authorization schemes. When storing the authorization identifier for a user Derby uses the canonical representation. [the canonical representation seems to be also called the common normal form or CNF in the SQL standard] System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Assignee: Martin Zaun Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB
[ https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561384#action_12561384 ] Kathey Marsden commented on DERBY-3257: --- Looks like there were no issues with the nightlies due to this change. I will check into 10.3 as soon as my tests complete. SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB -- Key: DERBY-3257 URL: https://issues.apache.org/jira/browse/DERBY-3257 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Stan Bradbury Assignee: Kathey Marsden Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, derby-3257_diff.txt, derby-3257_diff2.txt, derby-3257_plan_10.2.txt, derby-3257_plan_10.4.txt, derby-3257_stat.txt, TestHaving.java Attached program demonstrates the problem. Only one count is returned (matching CODE= GBR) - the count of CODE=CHA is not returned. Works fine with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 database (soft upgrade). Query: SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 GROUP BY t0.CODE HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL Incorrect results (see last line): Database product: Apache Derby Database version: 10.3.1.5 - (579866) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.3.1.5 - (579866) result: 2 Correct results: Database product: Apache Derby Database version: 10.2.2.0 - (485682) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.2.2.0 - (485682) result: 4 result: 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561383#action_12561383 ] A B commented on DERBY-3301: Even though the diff works, the condition for skipping flattening should be relaxed to only apply to EXISTS subqueries in a WHERE clause I think the condition may need to be narrowed down even further: EXISTS subqueries _are_ allowed to be flattened from a WHERE clause _if_ the WHERE clause is not itself part of another subquery. As an example, take a look at the last query on the doc page mentioned above, namely: SELECT t1.* FROM t1, t2 WHERE EXISTS (SELECT * FROM t3 WHERE t1.c1 = t3.c1) gets flattened into SELECT t1.* FROM t1, t2, t3 WHERE t1.c1 = t3.c1 If changes are made to completely avoid flattening of EXISTS subqueries in WHERE clauses, then the above query will *not* be flattened into an exists join, even though it's perfectly valid to perform flattening in that case. With the approach that you've outlined the exists join optimization as a whole will be disabled (I think?). I think that has the potential to cause a performance regression for users whose queries benefit from the EXISTS join optimization today. A similar discussion was held for DERBY-3231 and in that case a decision was made to deliberately remove an optimization for the sake of correctness. But the use cases affected by that particular optimization were (most likely) few and far between. With this issue, though, I think removing EXISTS subquery flattening across the board will affect far more users, so I worry about committing such a fix. The patch as posted does not apply to the current trunk, but from what I can tell, if you run a query like the one mentioned in the documentation, ex.: create table t1 (c1 int, c2 int, c3 int); create table t2 (i int, j int); create table t3 (c1 int, vc varchar(10)); insert into t1 values (1, -1, 1), (3, -3, 9), (2, -2, 4); insert into t2 values (2, 4); insert into t3 values (1, 'one'), (3, 'three'); select t1.* from t1, t2 where exists (select * from t3 where t1.c1 = t3.c1); I think derby-3301-1.diff will cause the SELECT to skip flattening of the EXISTS subquery. Is that correct? The core problem for this issue appears to be the specific case where we have a subquery SQ1 that appears in the whereClause of *another* subquery SQ0. In that case disabling the flattening of SQ1 would be appropriate--as the documentation states. But if subquery SQ1 appears in the whereClause of an *OUTER* query--as shown above--I don't think we should disable flattening altogether. If at all possible, I think it'd be better to fix the flattening condition for the specific situation of nested subqueries than to completely disable WHERE clause flattening for EXISTS subqueries. Or put differently: if the documentation is correct, the _intent_ is to skip flattening of an EXISTS subquery which is itself part of another subquery. But the current code does not correctly implement that intent. So I think it'd be good to figure out _why_ the current code is wrong for the case of nested subqueries, and then try to make a change that addresses that specific problem. On a slightly different note, have you had a chance to run the regression suites with this change? I'm curious to know if any of the existing tests actually test for EXISTS join flattening--and if so, do those tests still pass with the proposed change? Incorrect result from query with nested EXIST - Key: DERBY-3301 URL: https://issues.apache.org/jira/browse/DERBY-3301 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1 Reporter: Craig Russell Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301.sql Derby returns unexpected results from a query with embedded EXIST clauses. The query SQL is generated by the JPOX jdo implementation and is supposed to return all of the PERSONS and PROJECTS where there is an entry in the join table. This query works as expected when using MySQL. Here's the query: SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID FROM applicationidentity0.DEPARTMENTS THIS, applicationidentity0.PERSONS UNBOUND_E, applicationidentity0.PROJECTS UNBOUND_P WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E WHERE EXISTS ( SELECT 1 FROM applicationidentity0.PROJECT_MEMBER THIS_EMPLOYEES_E_PROJECTS_P WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_P.PROJID =
[jira] Commented: (DERBY-3304) Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable
[ https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561389#action_12561389 ] Mamta A. Satoor commented on DERBY-3304: Following seems to say that CallStatementResultSet#open makes a direct call to CallStatementResultSet#close but that is not true. When I check the code for CallStatementResultSet#open, I do not see a call to close method. The call to close from open does happen in MiscResultSet#open but that ResultSet does not come into play when dealing with CallStatementResultSet. Interestingly, CallStatementResultSet#close is called as part of CallStatementResultSet#open... Is this correct? I think it is confusing. Language result sets that do not return rows tend to do this because all of their work is performed in the open(), thus to free up any resources their open() call also calls close(). Now since the close will be called from some external source anyway, I think it would be cleaner if the open-close cycle was driven from the outside and not from within the open. * Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable -- Key: DERBY-3304 URL: https://issues.apache.org/jira/browse/DERBY-3304 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Attachments: Main.java Repro (Main.java) that shows changed behavior after svn 602991 (the patch committed for this issue). It seems a regression: (originally from Dag H. Wanvik attached to DERBY-1585) An explicit commit inside a stored procedure makes a dynamic result sets passed out unavailable, even if the commit is executed *prior* to the result set; as in the repro. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3137) SQL roles: add catalog support
[ https://issues.apache.org/jira/browse/DERBY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561395#action_12561395 ] Dag H. Wanvik commented on DERBY-3137: -- Committed DERBY-3137-uuid as svn 614273. This change will make existing trunk databases invalid, so please recreate any trunk database you might have before trying to run with 614273 or higher. SQL roles: add catalog support -- Key: DERBY-3137 URL: https://issues.apache.org/jira/browse/DERBY-3137 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Fix For: 10.4.0.0 Attachments: DERBY-3137-2.diff, DERBY-3137-2.stat, DERBY-3137-2.txt, DERBY-3137-uuid.diff, DERBY-3137-uuid.stat, DERBY-3137.diff, DERBY-3137.diff, DERBY-3137.stat, DERBY-3137.txt As a next step after adding support for the roles syntax, I intend to make a patch which implements catalog support for roles, cf. SYS.SYSROLES described in the specification (attached to DERBY-2207). Also the patch should tie this support up to the parser support, so the role statements can be executed. Any privileges granted to roles would still have no effect at run-time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[
https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-3037:
---
Attachment: DERBY3037_patch_not_ready_for_commit_v2_stat.txt
DERBY3037_patch_not_ready_for_commit_v2_diff.txt
I have a very small patch for the last item left on DERBY-3037 which is to move
close of a single use activation from BasicNoPutResultSet.finishRTS into
NoPutResultSetImpl.close. The patch is attached as
DERBY3037_patch_not_ready_for_commit_v2_diff.txt but I have included the diff
here to explain the failure caused by the patch
Index:
java/engine/org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.java
===
---
java/engine/org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.java(revision
613756)
+++
java/engine/org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.java(working
copy)
@@ -603,9 +603,6 @@
close();
finished = true;
-
- if (isTopResultSet activation.isSingleExecution())
- activation.close();
}
}
Index: java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java
===
---
java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java(revision
613756)
+++
java/engine/org/apache/derby/impl/sql/execute/NoPutResultSetImpl.java(working
copy)
@@ -183,6 +183,9 @@
isOpen = false;
+ if (isTopResultSet activation.isSingleExecution())
+ activation.close();
+
}
/** @see NoPutResultSet#setTargetResultSet */
$
This change in code causes a failure with lang/nestedCommit.sql. The specific
test case inside nestedCommit.sql has to do with a call to a Java Stored
routine (specifically, a function) which looks as follows
public static int doConnCommitInt() throws Throwable
{
Connection conn =
DriverManager.getConnection(jdbc:default:connection);
conn.commit();
return 1;
}
And the stack strace in derby.log for nestedCommit.sql looks as follows
2008-01-21 21:52:49.328 GMT Thread[main,5,main] (XID = 157), (SESSIONID = 0),
(DATABASE = wombat), (DRDAID = null), Failed Statement is: -- call
doConnStmt('call doConnStmt(''call doConnStmt(commit)'')');
values doConnCommitInt()
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED closed
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
at
org.apache.derby.impl.sql.execute.BaseActivation.setCurrentRow(BaseActivation.java:1276)
at
org.apache.derby.impl.sql.execute.NoPutResultSetImpl.setCurrentRow(NoPutResultSetImpl.java:316)
at
org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(RowResultSet.java:156)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:460)
at
org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:425)
at
org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:369)
at
org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:382)
at
org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:338)
at
org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:241)
at
org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:229)
at
org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:435)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:509)
at
org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)
at org.apache.derby.tools.ij.main(ij.java:59)
The reason for the stack failure is that the Language ResultSet associated with
the function call has been closed by the new code in NoPutResultSetImpl.close
which was invoked by the commit inside the user function doConnCommitInt.
During commit processing, we need to somehow distinguish the fact that the
Language ResultSet is still being constructed and used and hence should not be
closed. I would appreciate if anyone has any ideas on how to achieve this.
Language ResultSet.finish() is called even when the ResultSet is going to be
re-used.
-
Key: DERBY-3037
URL:
[jira] Issue Comment Edited: (DERBY-3301) Incorrect result from query with nested EXIST
[ https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561383#action_12561383 ] army edited comment on DERBY-3301 at 1/22/08 9:39 AM: - Even though the diff works, the condition for skipping flattening should be relaxed to only apply to EXISTS subqueries in a WHERE clause I think the condition may need to be narrowed down even further: EXISTS subqueries _are_ allowed to be flattened from a WHERE clause _if_ that subquery's WHERE clause does not itself contain another subquery. As an example, take a look at the last query on the doc page mentioned above, namely: SELECT t1.* FROM t1, t2 WHERE EXISTS (SELECT * FROM t3 WHERE t1.c1 = t3.c1) gets flattened into SELECT t1.* FROM t1, t2, t3 WHERE t1.c1 = t3.c1 If changes are made to completely avoid flattening of EXISTS subqueries in WHERE clauses, then the above query will *not* be flattened into an exists join, even though it's perfectly valid to perform flattening in that case. With the approach that you've outlined the exists join optimization as a whole will be disabled (I think?). I think that has the potential to cause a performance regression for users whose queries benefit from the EXISTS join optimization today. A similar discussion was held for DERBY-3231 and in that case a decision was made to deliberately remove an optimization for the sake of correctness. But the use cases affected by that particular optimization were (most likely) few and far between. With this issue, though, I think removing EXISTS subquery flattening across the board will affect far more users, so I worry about committing such a fix. The patch as posted does not apply to the current trunk, but from what I can tell, if you run a query like the one mentioned in the documentation, ex.: create table t1 (c1 int, c2 int, c3 int); create table t2 (i int, j int); create table t3 (c1 int, vc varchar(10)); insert into t1 values (1, -1, 1), (3, -3, 9), (2, -2, 4); insert into t2 values (2, 4); insert into t3 values (1, 'one'), (3, 'three'); select t1.* from t1, t2 where exists (select * from t3 where t1.c1 = t3.c1); I think derby-3301-1.diff will cause the SELECT to skip flattening of the EXISTS subquery. Is that correct? The core problem for this issue appears to be the specific case where we have a subquery SQ1 that appears in the whereClause of *another* subquery SQ0. In that case disabling the flattening of SQ0 would be appropriate--as the documentation states. But if subquery SQ1 appears in the whereClause of an *OUTER* query--as shown above--I don't think we should disable flattening altogether. If at all possible, I think it'd be better to fix the flattening condition for the specific situation of nested subqueries than to completely disable WHERE clause flattening for EXISTS subqueries. Or put differently: if the documentation is correct, the _intent_ is to skip flattening of an EXISTS subquery that has predicates which in turn contain other subqueries. But the current code does not correctly implement that intent. So I think it'd be good to figure out _why_ the current code is wrong for the case of nested subqueries, and then try to make a change that addresses that specific problem. On a slightly different note, have you had a chance to run the regression suites with this change? I'm curious to know if any of the existing tests actually test for EXISTS join flattening--and if so, do those tests still pass with the proposed change? was (Author: army): Even though the diff works, the condition for skipping flattening should be relaxed to only apply to EXISTS subqueries in a WHERE clause I think the condition may need to be narrowed down even further: EXISTS subqueries _are_ allowed to be flattened from a WHERE clause _if_ the WHERE clause is not itself part of another subquery. As an example, take a look at the last query on the doc page mentioned above, namely: SELECT t1.* FROM t1, t2 WHERE EXISTS (SELECT * FROM t3 WHERE t1.c1 = t3.c1) gets flattened into SELECT t1.* FROM t1, t2, t3 WHERE t1.c1 = t3.c1 If changes are made to completely avoid flattening of EXISTS subqueries in WHERE clauses, then the above query will *not* be flattened into an exists join, even though it's perfectly valid to perform flattening in that case. With the approach that you've outlined the exists join optimization as a whole will be disabled (I think?). I think that has the potential to cause a performance regression for users whose queries benefit from the EXISTS join optimization today. A similar discussion was held for DERBY-3231 and in that case a decision was made to deliberately remove an optimization for the sake of correctness. But the use cases affected by that particular optimization were (most likely) few and far between. With this issue, though,
Please drop old trunk databases after updating to svn 614273
A change in dictionary format (SYS.SYSROLES), cf. DERBY-3137 has been committed as svn 614273. Dag
[jira] Commented: (DERBY-3335) Allow UserAuthenticator.authenticateUser to work with authorization identifiers and not user name.
[ https://issues.apache.org/jira/browse/DERBY-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561406#action_12561406 ] Daniel John Debrunner commented on DERBY-3335: -- A better name for the property might be: user.canonical (or user.cnf). The property's name would be a public static final field in the UserAuthenticator interface. Allow UserAuthenticator.authenticateUser to work with authorization identifiers and not user name. -- Key: DERBY-3335 URL: https://issues.apache.org/jira/browse/DERBY-3335 Project: Derby Issue Type: Improvement Components: Security Reporter: Daniel John Debrunner Priority: Minor Add a new method to UserAuthenticator that allows the authentication scheme to request that the user name passed into authenticateUser is an authentication identifier. This would absolve authentication schemes from each implementing the mapping from user name to authorization identifier. Implementing the logic in each scheme is pointless and subject to errors if a different set of rules is implemented by the scheme (say by a coding bug). Signature could be /** Return true if the identifier argument to authenticateUser is to represent an authorization identifier, false if it is to represent the user name. Note the identifier argument passed into authenticateUser is provided by the database engine. @since 10.x If this method does exist then a return of false is assumed. */ public boolean authenticateUsingAuthorizationId(); The first argument to authenticateUser would change for userName to identifier with appropriate comment changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-3037: --- Attachment: DERBY_3304_Repro.java Here is a standalone reproducible test case that shows closure of resultset when code changes of the patch DERBY3037_patch_not_ready_for_commit_v2_diff.txt are applied. Language ResultSet.finish() is called even when the ResultSet is going to be re-used. - Key: DERBY-3037 URL: https://issues.apache.org/jira/browse/DERBY-3037 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Assignee: Mamta A. Satoor Fix For: 10.3.2.2, 10.4.0.0 Attachments: DERBY3037_patch_not_ready_for_commit_v2_diff.txt, DERBY3037_patch_not_ready_for_commit_v2_stat.txt, Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, Derby_3037_AlterTableConstantActionChanges_v1_stat.txt, DERBY_3304_Repro.java DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to be the lifetime of the activation, but did not fix up the correct calls to ResultSet.close() and ResultSet.finish(). A language ResultSet's lifetime should be driven by the activation, so activation.close() should call finish() on its ResultSet. EmbedResultSet should call close on its language ResultSet (theResults field) when the JDBC ResultSet is closed, it should not be calling finish() on its ResultSet. See comments in DERBY-827 for some more details and issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Issue Comment Edited: (DERBY-3301) Incorrect result from query with nested EXIST
A B (JIRA) wrote: I think the condition may need to be narrowed down even further: EXISTS subqueries _are_ allowed to be flattened from a WHERE clause _if_ that subquery's WHERE clause does not itself contain another subquery. Correct - the updated patch I'm working on attempts to skip flattening only in this scenario as per the javadoc in derby-3301-1.diff, and still flatten EXISTS subqueries without a subquery in the where clause. I didn't check patch available due to this :) I think that has the potential to cause a performance regression for users whose queries benefit from the EXISTS join optimization today. Also correct. With derby-3301-1.diff applied, the query takes noticeably more time to execute. But that is reasonable because it disables flattening of the nested exist where clause all together. The patch as posted does not apply to the current trunk, My apologies. I'll reattach it later tonight. Probably due to Katheys changes for DERBY-3257 that wasn't in my sandbox. If at all possible, I think it'd be better to fix the flattening condition for the specific situation of nested subqueries than to completely disable WHERE clause flattening for EXISTS subqueries. That is the intent of the upcoming patch. On a slightly different note, have you had a chance to run the regression suites with this change? I'm curious to know if any of the existing tests actually test for EXISTS join flattening--and if so, do those tests still pass with the proposed change? I shared your fear, but suites.All actually ran cleanly with the patch applied.
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561409#action_12561409 ] Daniel John Debrunner commented on DERBY-2109: -- Maybe we could add a userNamesAreCaseSensitive() method to UserAuthenticator or create a CaseSensitiveUserAuthenticator interface to extend UserAuthenticator? Given a case-sensitive UserAuthenticator, we would not have to throw Edward and EdWard into the same schema. The default behavior would be the current behavior. And the default behavior for SystemPrincipal would be, as Dan suggests, that usernames are case-insensitive. DERBY-3335 proposes a mechanism for an authentication implementation to get the canonical version of the provided user name without changing any api. That's not exactly what you are proposing, I think you are proposing a new way of providing a user name to Derby in Java/JDBC where the user name provided has to match the canonical representation of an authorization identifier. Obviously in SQL (e.g. GRANT) such user names would have to be delimited. Obviously such a change applies to more than authentication, connection level authorization would need to follow the same scheme, the mapping of the provided user name to the SQL user identifier etc. I have the feeling that this might confuse the user name situation more that simplify it. Now a client application needs to know how a specific database is treating user names before it can format a connection request. Currently there is a single rule of how user names in Java map to SQL user identifiers. If such a feature can be delayed until there is some actual need for it, then I think it just resolves to a simple choice: A) name for SystemPrincipal is an authentication identifier (supports regular and delimited identifiers) and thus matches all other places where a user name is specified in a Java/JDBC context. B) name for SystemPrincipal is the canonical representation of an authentication identifier, which leads to easier to read policy files but does not match existing Java/JDBC practice. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Assignee: Martin Zaun Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack
[ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561421#action_12561421 ] Dag H. Wanvik commented on DERBY-3327: -- I'll answer in two segments, the first on the specific patch comments, then on the larger issues. * Specific patch comments For the field 'callers' in GenericLanguageConnectionContext.java I think it's holding a stack of Activations. Could you state this in its javadoc. (oh for Java 5 :-) Yes, I thought I did say it (keeps track of which, if any, stored procedure activations are active), but I will make it clearer. Generics would have been nice here, yes :) In the javadoc comment for 'callers' it says: For the top level, the current role is kept here, cf. 'currentRole'. Since this is the javadoc for callers, the here applies to callers, but I think you really mean the current class. Would this be correct? You are right. I have moved this comment to where it belongs, with currentRole. In BaseActivation can the comments for the field callActivation be javadoc comments, so that IDE's will pick them up. Agree, will do. Can comments be added for nestedCurrentRole. Agree, will do. Even with the comments for BaseActivation.callActivation I became a little confused. Looking elsewhere I can see that callActivation is the activation of the enclosing CALL statement, that would have been useful in the javadoc. Adding an explicit statement about that. I'm somewhat confused by the need for BaseActivation.callActivation and the stack in the LCC. It seems that the stack of activations is being kept twice, once in LCC and once through the activations. It's probably redundant, I will try again see if I can get rid of it. I wonder about the cost of this stack maintenance, for SQL routines that are defined as NO SQL it might be a significant overhead. E.g. SIN() function. Avoiding the context manipulation for those routines could be a follow on, but I'd be interested in the overhead with this change. Right. I'll run some tests. Moving the pushing to code generation (as you also) should help us get rid of the overhead for NO SQL functions, too. np - one other item is that according to section 10.4 routine invocation the order is: GR2) Evaluate arguments GR5) Push new SQL-session context (RSC) GR7/8) Execute the routine The order in the patch is: A) Push new authorization context B) Evaluate arguments C) Execute the routine To match the order of the spec the new context would need to be part of the generated code. Not sure if it makes any difference or not, but something to consider. I think as long as we run with invoker's right it does not matter, but if/when we decide to add the ability to run with definer's rights it would, since for example an argument refering CURRENT_USER would then evaluate differently depending on whether the authorization stack was pushed or not, so it would be good to do it in the right order, I don't think the patch addresses functions, since the lcc.pushCaller() is only set from CallStatementResultSet. Yes, thanks. I had added a test (buggy!) which blind sided me there for a while. * Larger issues It seems somewhat strange that this is implemented as a stack of activations and because of that we end up needing to store role information in two different places, in the LCC if it's the top-level and the activation otherwise. Since the activation represents an individual statement is its job to hold SQL context information? It is a bit awkward, and it may be the wrong choice. I would have preferred an explicit representation of the new session context (SQL 10.4's RSC, perhaps called SQLSessionContext object, as you suggest), but I did not find one ;) I looked at ConnectionContext and StatementContext but these classes seems to be available only at the JDBC level. At execution time, it seems we have to rely on what's reachable from the activation (lcc, transaction controller, result set). Somehow, the activation needs to know its dynamic nesting so that it can access the correct dynamic context. DERBY-1331 would seem to indicate we need to go this route at some point anyway, so I'll have a go. Looking closer at the SQL standard (4.34.1.1 and 4.27.3) I'm not sure the patch is implementing exactly what is described there. One portion is the SQL-session context, that comes into being with the routine invocation. Then within the SQL-session context is an authorization stack. The patch seems to be morphing the two into one, executing a routine creates just a role stack. Right, although interpreting the standard literally (GR 5.h: copying the authorization stack) seems to be inefficient, so some morphing may be useful ;) Would it make more sense to have objects that followed the model described by the SQL specification, even if currently
[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles
[ https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561420#action_12561420 ] Daniel John Debrunner commented on DERBY-2207: -- Couple of questions about section 5.3 of the spec. Section 5.3) (Implementation restriction) Currently in Derby, user identifier can be max 30 characters long. Until this restriction is lifted, roles will have the same limit, Can this restriction be explained? Since a role is not a user identifier, why should a limit on user identifier impact role name? Section 6.1 The name authorization identifier name space issue or maybe section 5.4 When granting a privilege can you specify the behaviour for roles/users. I think it is that if the grantee exists as a role then the privilege is granted to that role, otherwise grantee is treated as a user identifier. I think this falls out of the current grant implementation, ie. the grant doesn't actually care if grantee is a role name or a user name, it just updates the catalogs. Good to be explicit here. Improve usability of Derby's client/server security by implementing ANSI Roles -- Key: DERBY-2207 URL: https://issues.apache.org/jira/browse/DERBY-2207 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, spec.html Implementing ANSI Roles will make it easier to manage security for multi-user applications with high user turnover. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561409#action_12561409 ] djd edited comment on DERBY-2109 at 1/22/08 11:07 AM: Maybe we could add a userNamesAreCaseSensitive() method to UserAuthenticator or create a CaseSensitiveUserAuthenticator interface to extend UserAuthenticator? Given a case-sensitive UserAuthenticator, we would not have to throw Edward and EdWard into the same schema. The default behavior would be the current behavior. And the default behavior for SystemPrincipal would be, as Dan suggests, that usernames are case-insensitive. DERBY-3335 proposes a mechanism for an authentication implementation to get the canonical user identifier of the provided user name without changing any api. That's not exactly what you are proposing, I think you are proposing a new way of providing a user name to Derby in Java/JDBC where the user name provided has to match the canonical representation of a user identifier. Obviously in SQL (e.g. GRANT) such user names would have to be delimited. Obviously such a change applies to more than authentication, connection level authorization would need to follow the same scheme, the mapping of the provided user name to the SQL user identifier etc. I have the feeling that this might confuse the user name situation more that simplify it. Now a client application needs to know how a specific database is treating user names before it can format a connection request. Currently there is a single rule of how user names in Java map to SQL user identifiers. If such a feature can be delayed until there is some actual need for it, then I think it just resolves to a simple choice: A) name for SystemPrincipal is a user identifier (supports regular and delimited identifiers) and thus matches all other places where a user name is specified in a Java/JDBC context. B) name for SystemPrincipal is the canonical representation of an user identifier, which leads to easier to read policy files but does not match existing Java/JDBC practice. [edit: be consistent with user identifier] was (Author: djd): Maybe we could add a userNamesAreCaseSensitive() method to UserAuthenticator or create a CaseSensitiveUserAuthenticator interface to extend UserAuthenticator? Given a case-sensitive UserAuthenticator, we would not have to throw Edward and EdWard into the same schema. The default behavior would be the current behavior. And the default behavior for SystemPrincipal would be, as Dan suggests, that usernames are case-insensitive. DERBY-3335 proposes a mechanism for an authentication implementation to get the canonical version of the provided user name without changing any api. That's not exactly what you are proposing, I think you are proposing a new way of providing a user name to Derby in Java/JDBC where the user name provided has to match the canonical representation of an authorization identifier. Obviously in SQL (e.g. GRANT) such user names would have to be delimited. Obviously such a change applies to more than authentication, connection level authorization would need to follow the same scheme, the mapping of the provided user name to the SQL user identifier etc. I have the feeling that this might confuse the user name situation more that simplify it. Now a client application needs to know how a specific database is treating user names before it can format a connection request. Currently there is a single rule of how user names in Java map to SQL user identifiers. If such a feature can be delayed until there is some actual need for it, then I think it just resolves to a simple choice: A) name for SystemPrincipal is an authentication identifier (supports regular and delimited identifiers) and thus matches all other places where a user name is specified in a Java/JDBC context. B) name for SystemPrincipal is the canonical representation of an authentication identifier, which leads to easier to read policy files but does not match existing Java/JDBC practice. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Assignee: Martin Zaun Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff,
Re: [jira] Issue Comment Edited: (DERBY-3301) Incorrect result from query with nested EXIST
Thomas Nielsen wrote: A B (JIRA) wrote: I think the condition may need to be narrowed down even further: EXISTS subqueries _are_ allowed to be flattened from a WHERE clause _if_ that subquery's WHERE clause does not itself contain another subquery. Correct - the updated patch I'm working on attempts to skip flattening only in this scenario as per the javadoc in derby-3301-1.diff, and still flatten EXISTS subqueries without a subquery in the where clause. Okay, great. I didn't quite get that from the first version of the patch/comments. Thanks for clarifying. If at all possible, I think it'd be better to fix the flattening condition for the specific situation of nested subqueries than to completely disable WHERE clause flattening for EXISTS subqueries. That is the intent of the upcoming patch. Ok, this sounds good :) I shared your fear, but suites.All actually ran cleanly with the patch applied. What about derbyall? My guess is that most tests which verify query plans currently reside in derbyall as they have not yet been converted to JUnit. If there are no tests to explicitly check for the occurrence of EXISTS subquery flattening, then that seems like an oversight in the testing for such flattening...but that would be a separate issue altogether (not something you'd have to address for DERBY-3301). Army
[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles
[ https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561425#action_12561425 ] Dag H. Wanvik commented on DERBY-2207: -- Thanks for looking at the specification again! Section 5.3) (Implementation restriction) Currently in Derby, user identifier can be max 30 characters long. Until this restriction is lifted, roles will have the same limit, Can this restriction be explained? Since a role is not a user identifier, why should a limit on user identifier impact role name? I think the only reason I inherited this restriction is that the system tables represent GRANTEE/GRANTOR as VARCHAR(30), but I could change that I guess? It may be only the documentation which says max 30, I think the actual column is SQLIdentifier (VARCHAR(255)). I'll see if I can remove this restriction from roles. Section 6.1 The name authorization identifier name space issue or maybe section 5.4 When granting a privilege can you specify the behaviour for roles/users. I think it is that if the grantee exists as a role then the privilege is granted to that role, otherwise grantee is treated as a user identifier. I think this falls out of the current grant implementation, ie. the grant doesn't actually care if grantee is a role name or a user name, it just updates the catalogs. Good to be explicit here. Yes, this is how I understand it also. Will add some explicitness here :) Improve usability of Derby's client/server security by implementing ANSI Roles -- Key: DERBY-2207 URL: https://issues.apache.org/jira/browse/DERBY-2207 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, spec.html Implementing ANSI Roles will make it easier to manage security for multi-user applications with high user turnover. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3304) Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable
[ https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561435#action_12561435 ] Mamta A. Satoor commented on DERBY-3304: I added a junit test case for the test case provided by Dag to this Jira entry. The changes went into the trunk as part of revision 614292. The commit comments were as follows Adding a junit test for the standalone test case provided by Dag for DERBY-3304. Here, we are adding a Java procedure which does a commit and then returns a resultset back to the caller. The resultset should not get closed as part of the commit. Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable -- Key: DERBY-3304 URL: https://issues.apache.org/jira/browse/DERBY-3304 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Attachments: Main.java Repro (Main.java) that shows changed behavior after svn 602991 (the patch committed for this issue). It seems a regression: (originally from Dag H. Wanvik attached to DERBY-1585) An explicit commit inside a stored procedure makes a dynamic result sets passed out unavailable, even if the commit is executed *prior* to the result set; as in the repro. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.
[ https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561442#action_12561442 ] Daniel John Debrunner commented on DERBY-3037: -- This is a similar issue to DERBY-3304 where the commit inside of a routine closes the language result set that is executing the routine. It seems that the commit() needs to be smarter about which language result sets to close. It's not just the current one that's the issue, actually any that are actively in use. E.g. If a procedure P1 calls procedure P2 which calls procedure P3 and P3 commits, then current all the language result sets will be closed (ignoring held result sets), but the language result sets (CallStatementResultSets) for P1, P2 and P3 should remain open. For functions it's a similar problem, though it's complicated by that fact that a function is called from a language result set that returns rows, whereas a procedure is not. So with a SQL select executed through a JDBC statement with close result sets on commit: SELECT f(a) FROM T if f(a) commits then is the JDBC ResultSet that is processing the query closed, meaning that its next next() call will thrown an exception? Language ResultSet.finish() is called even when the ResultSet is going to be re-used. - Key: DERBY-3037 URL: https://issues.apache.org/jira/browse/DERBY-3037 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Assignee: Mamta A. Satoor Fix For: 10.3.2.2, 10.4.0.0 Attachments: DERBY3037_patch_not_ready_for_commit_v2_diff.txt, DERBY3037_patch_not_ready_for_commit_v2_stat.txt, Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, Derby_3037_AlterTableConstantActionChanges_v1_stat.txt, DERBY_3304_Repro.java DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to be the lifetime of the activation, but did not fix up the correct calls to ResultSet.close() and ResultSet.finish(). A language ResultSet's lifetime should be driven by the activation, so activation.close() should call finish() on its ResultSet. EmbedResultSet should call close on its language ResultSet (theResults field) when the JDBC ResultSet is closed, it should not be calling finish() on its ResultSet. See comments in DERBY-827 for some more details and issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB
[ https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3257. --- Resolution: Fixed Fix Version/s: 10.4.0.0 10.3.2.2 Merged fix to 10.2 with revision 614304 SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB -- Key: DERBY-3257 URL: https://issues.apache.org/jira/browse/DERBY-3257 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Stan Bradbury Assignee: Kathey Marsden Fix For: 10.3.2.2, 10.4.0.0 Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, derby-3257_diff.txt, derby-3257_diff2.txt, derby-3257_plan_10.2.txt, derby-3257_plan_10.4.txt, derby-3257_stat.txt, TestHaving.java Attached program demonstrates the problem. Only one count is returned (matching CODE= GBR) - the count of CODE=CHA is not returned. Works fine with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 database (soft upgrade). Query: SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 GROUP BY t0.CODE HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL Incorrect results (see last line): Database product: Apache Derby Database version: 10.3.1.5 - (579866) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.3.1.5 - (579866) result: 2 Correct results: Database product: Apache Derby Database version: 10.2.2.0 - (485682) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.2.2.0 - (485682) result: 4 result: 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3336) jdbcapi/derbyStress.java no longer runs with low memory heap so does not provide testing for leak scenarios
[ https://issues.apache.org/jira/browse/DERBY-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3336: -- Affects Version/s: 10.3.2.2 jdbcapi/derbyStress.java no longer runs with low memory heap so does not provide testing for leak scenarios Key: DERBY-3336 URL: https://issues.apache.org/jira/browse/DERBY-3336 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.2.2, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden This was raised as an issue in DERBY-3316, but it seems to make most sense to raise it as a separate issue. When derbyStress ran in derbyall it ran with 64MB heap so that it could test fixes for various memory leaks. When moved to JDBCHarnessJavaTest it started running with the full 512MB heap used for suites.All so no longer tests for those leaks. There are two options presented so far 1) Move it back to derbyall 2) add it to the junit-all target For the adding it to the junit-all target option I think a few things have to happen for it to be run as part of the nightlies. 1) Convert derbyStress.java to junit. 2) create a junit-lomem target and make it part of junit-all. 3) Fix junit-all so that it can run with the nightlies. DERBY-2045 + distribute ant to the testing machines make nightly script changes etc. Myrna expressed some misgivings to relying on junit-all because ant is not available on all the platforms where she tests. I think the best course of action is to at least temporarily move the test back to derbyall and then open separate task(s) for the junit conversion effort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3336) jdbcapi/derbyStress.java no longer runs with low memory heap so does not provide testing for leak scenarios
[ https://issues.apache.org/jira/browse/DERBY-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3336: -- Affects Version/s: (was: 10.3.2.2) 10.3.2.1 Fix Version/s: 10.4.0.0 10.3.2.2 jdbcapi/derbyStress.java no longer runs with low memory heap so does not provide testing for leak scenarios Key: DERBY-3336 URL: https://issues.apache.org/jira/browse/DERBY-3336 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.2.1, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.3.2.2, 10.4.0.0 This was raised as an issue in DERBY-3316, but it seems to make most sense to raise it as a separate issue. When derbyStress ran in derbyall it ran with 64MB heap so that it could test fixes for various memory leaks. When moved to JDBCHarnessJavaTest it started running with the full 512MB heap used for suites.All so no longer tests for those leaks. There are two options presented so far 1) Move it back to derbyall 2) add it to the junit-all target For the adding it to the junit-all target option I think a few things have to happen for it to be run as part of the nightlies. 1) Convert derbyStress.java to junit. 2) create a junit-lomem target and make it part of junit-all. 3) Fix junit-all so that it can run with the nightlies. DERBY-2045 + distribute ant to the testing machines make nightly script changes etc. Myrna expressed some misgivings to relying on junit-all because ant is not available on all the platforms where she tests. I think the best course of action is to at least temporarily move the test back to derbyall and then open separate task(s) for the junit conversion effort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3068) testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure: Unexpected SQL state. exp
[ https://issues.apache.org/jira/browse/DERBY-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-3068: - Assignee: Kathey Marsden testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:38000 but was:XIE0S --- Key: DERBY-3068 URL: https://issues.apache.org/jira/browse/DERBY-3068 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.4.0.0 Environment: Windows XP IBM 1.5 Reporter: Kathey Marsden Assignee: Kathey Marsden 1) testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:38000 but was:XIE0S at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:668) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:717) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:898) at org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest.testImportExportProcedureNegative(ImportExportProcedureTest.java:1933) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: java.sql.SQLException: The export operation was not performed, because the specified output file (extinout/t1.dat) already exists. Export processing will not overwrite an existing file, even if the process has permissions to write to that file, due to security concerns, and to avoid accidental file damage. Please either change the output file name in the export procedure arguments to specify a file which does not exist, or delete the existing file, then retry the export operation. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:893) ... 45 more Caused by: org.apache.derby.client.am.SqlException: The export operation was not performed, because the specified output file (extinout/t1.dat) already exists. Export processing will not overwrite an existing file, even if the process has permissions to write to that file, due to security concerns, and to avoid accidental file damage. Please either change the output file name in the export procedure arguments to specify a file which does not exist, or delete the existing file, then retry the export operation. at org.apache.derby.client.am.Statement.completeExecute(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source) at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown Source) at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown Source) at org.apache.derby.client.am.Statement.readExecuteCall(Unknown Source) at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown Source) at
[jira] Issue Comment Edited: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB
[ https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561449#action_12561449 ] kmarsden edited comment on DERBY-3257 at 1/22/08 12:45 PM: - Merged fix to 10.3 with revision 614304 was (Author: kmarsden): Merged fix to 10.2 with revision 614304 SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB -- Key: DERBY-3257 URL: https://issues.apache.org/jira/browse/DERBY-3257 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 Reporter: Stan Bradbury Assignee: Kathey Marsden Fix For: 10.3.2.2, 10.4.0.0 Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, derby-3257_diff.txt, derby-3257_diff2.txt, derby-3257_plan_10.2.txt, derby-3257_plan_10.4.txt, derby-3257_stat.txt, TestHaving.java Attached program demonstrates the problem. Only one count is returned (matching CODE= GBR) - the count of CODE=CHA is not returned. Works fine with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 database (soft upgrade). Query: SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 GROUP BY t0.CODE HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL Incorrect results (see last line): Database product: Apache Derby Database version: 10.3.1.5 - (579866) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.3.1.5 - (579866) result: 2 Correct results: Database product: Apache Derby Database version: 10.2.2.0 - (485682) Driver name: Apache Derby Embedded JDBC Driver Driver version: 10.2.2.0 - (485682) result: 4 result: 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3192) Cache session data in the client driver
[ https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561465#action_12561465 ] Dyre Tjeldvoll commented on DERBY-3192: --- Ah, good. One less thing to worry about. I'm trying to understand how you can add 'product-specific' extensions (specifically code points) to DDM commands. I'm trying to understand the CODPNTDR section of vol3 (page 224): Codepoints consist of two values, a 1-hex index into a list of dictionaries and a 3-hex identifier unique within the referenced dictionary. The resolution of codepoints to class descriptors is illustrated in Figure 3-18 (on page 225). For Agent Level 3, the list of dictionaries is fixed, and specific index values are assigned as follows: • C-F: Reserved for product extensions (see EXTENSIONS (on page 381)) • 4-B: Reserved for DDM Architecture • 3: DDM dictionary QDDADLD • 2: DDM dictionary QDDRDBD • 1: DDM dictionary QDDBASD • 0: DDM dictionary QDDPRMD Does that mean I can use codepoints in the range [0xC000-0x] to product-unique stuff? And use them as instance variables in OPNQRYRM/QRYDTA? Cache session data in the client driver --- Key: DERBY-3192 URL: https://issues.apache.org/jira/browse/DERBY-3192 Project: Derby Issue Type: Improvement Components: JDBC, Network Client, Network Server, Performance, SQL Affects Versions: 10.3.1.4 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Attachments: derby-3192-test.fup1.diff, derby-3192-test.fup2.diff, derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff The reason for doing this is to avoid a rather substantial performance hit observed when the client driver is used together with an appserver that uses connection pooling. There are two problems: 1) The connection pool will compare the isolation level it has stored for the connection with the value returned from Connection.getTransactionIsolation() each and every time someone requests a new connection from the pool. 2) The users of the connection pool (ab)use it to avoid having to keep track of their current connection. So each time a query needs to be executed a call to the connection pool's getConnection() method is made. Getting a connection from the connection pool like this also means that a new PreparedStatement must be prepared each time. The net result is that each query results in the following sequence: getConnection() getTransactionIsolation() -- roundtrip + lookup in server's statement cache prepareStatment() -- roundtrip + lookup in server's statement cache executeQuery()-- roundtrip Arguably this is a user error but when suggesting this I'm kindly informed that this works just fine with other datbases (such as PostgreSQL and ORACLE). The reason why it works is that these databases do statement caching in the driver. I've tried to implement a very (too) simple statement cache in Derby's client driver and to re-enable caching of the isolation level (see https://issues.apache.org/jira/browse/DERBY-1148). With these changes I observe a marked performance improvement when running with appserver load. A proper statment cache cannot be implemented without knowing what the current schema is. If the current schema has changed since the statement was prepared, it is no longer valid and must be evicted from the cache. The problem with caching both the isolation level and the current schema in the driver is that both can change on the server without the client detecting it (through SQL and XA and possibly stored procedures). I think this problem can be overcome if we piggy-back the information we would like to cache on messages going back to the client. This can be done by utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume 3, page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD in the reply, I think it would be possible to cache additional session information when this becomes relevant. It would also be possible to use EXCSQLSET to batch session state changes going from the client to the server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles
[ https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561472#action_12561472 ] Daniel John Debrunner commented on DERBY-2207: -- The system columns for grantee/grantor are VARCHAR(128) - this was discussed during the grant/revoke implementation and I think the func spec was never updated which lead to the documentation being wrong. Improve usability of Derby's client/server security by implementing ANSI Roles -- Key: DERBY-2207 URL: https://issues.apache.org/jira/browse/DERBY-2207 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Rick Hillegas Assignee: Dag H. Wanvik Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, spec.html Implementing ANSI Roles will make it easier to manage security for multi-user applications with high user turnover. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack
[ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561476#action_12561476 ] Daniel John Debrunner commented on DERBY-3327: -- Thanks for the detailed reply StatementContexts are not for the JDBC layer, they are really for the SQL layer. The current statement context can be obtained using lcc.getStatementContext(). If an activation (or its result set) is being executed in any way then it is the current statement context. Derby is only actively executing a single statement at any time for a connection. Another thought is that the context manager exists to handle pushing and popping of contexts, so should this existing paradigm be used to manage new contexts such as a SQLSessionContext or authentication stack. Then error cleanup would be handled consistently, rather than introducing a new mechanism with a different paradigm. The statement context may not match the SQLSessionContext in all cases (e.g. it maybe does for a procedure call but not for a function call). SQL roles: Implement authorization stack Key: DERBY-3327 URL: https://issues.apache.org/jira/browse/DERBY-3327 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Fix For: 10.4.0.0 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat The current LanguageConnectionContext keeps the user authorization identifier for an SQL session. The lcc is shared context also for nested connections (opened from stored procedures). So far, for roles, the current role has been stored in the lcc also. However, SQL requires that authorization identifers be pushed on a authorization stack when calling a stored procedure, cf. SQL 2003, vol 2, section 4.34.1.1 and 4.27.3. This allows a caller to keep its current role after a call even if changed by the stored procedure. This issue will implement the current role name part (cell) of the authorization stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Another newbie internals question
I want to bring up a captive instance of Derby as a JDBC server. I want to do this using a front class of my own, because I want to customize the environment somewhat (set a few system properties, load and launch a few custom classes, whatever). This should all a simple thing, just wrapping the normal Derby invocation class; here's the kicker: once Derby is initialized, I want to initiate a JDBC session with it and submit a series of customizing SQL statements (CREATE FUNCTIONs for Table Functions). Modifying Derby code is OK for this, but I'd rather keep modifications to a minimum. Is there a clean way to do this other than starting a Thread which attempts JDBC connect() until Derby is ready ? Basically, I need to hook into someplace in Derby once it is enabled for JDBC in order to force-feed some commands before the real clients come along, so that the TableFunctions I'm setting up will be available for them. I don't really care if users are locked out before these things are processed; I can live with telling people just let it come up fully, but of course it would be nice to ensure availability from the get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? Thanks, Frank Griffin
[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack
[ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561507#action_12561507 ] Dag H. Wanvik commented on DERBY-3327: -- Thanks for the information, it is very useful! When you suggest the StatementContext may be sufficient to hold the SQL session context, I presume you mean the StatementContext of the calling statement? It has (about) the same lifetime as the procedure invocation - but see question below. So the activation and/or statementContext of, say, a nested VALUES CURRENT_USER would reference the parent (CALL) statement context to get at the nested SQL session context? If you meant the statement context of the VALUES CURRENT_USER, it has to get its session state from somewhere? (As I understand it, the lifetime of the statement context is limited to prepare and/or execution of a single statement.) What about the following case: I think the activations of dynamic result sets may need the dynamic context after the procedure has returned, say, if the statement yielding the result set references CURRENT_ROLE and that this is evaluated lazily only when the cursor is accessed (rs.next()). The statement context for the CALL has been popped (and reset) at that time (from GEnericPreparedStatement#execute), right? Would it be ok with the current model for it to stay live until the dynamic result set us closed? If not, perhaps a separate SQLConnectionContext (which could stay around longer) is better? Also, since the lcc.getStatementContext returns the current top context, it would not yield the right one if invoked by a dynamic result set of an activation after procedure return, I think? Sorry if I am misconstruing reality here; trying to understand more ;) SQL roles: Implement authorization stack Key: DERBY-3327 URL: https://issues.apache.org/jira/browse/DERBY-3327 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Fix For: 10.4.0.0 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat The current LanguageConnectionContext keeps the user authorization identifier for an SQL session. The lcc is shared context also for nested connections (opened from stored procedures). So far, for roles, the current role has been stored in the lcc also. However, SQL requires that authorization identifers be pushed on a authorization stack when calling a stored procedure, cf. SQL 2003, vol 2, section 4.34.1.1 and 4.27.3. This allows a caller to keep its current role after a call even if changed by the stored procedure. This issue will implement the current role name part (cell) of the authorization stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack
[ https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561513#action_12561513 ] Daniel John Debrunner commented on DERBY-3327: -- (As I understand it, the lifetime of the statement context is limited to prepare and/or execution of a single statement.) No, the statement context is set up during the ResultSet.next() or any positioning call as well. Code that is executing or fetching rows will have the most recently pushed statement context associated with it. This is so that a statement level exception error handling affects the currently executing statement. With a dynamic result I believe that when it is executing (e.g. a next() call) then the most recently pushed statement context will be associated with that result set and the activation/statement that created it. So I think I mean only that any statement would always just refer to its StatementContext, which is the most recently pushed one since the statement must be being executed. SQL roles: Implement authorization stack Key: DERBY-3327 URL: https://issues.apache.org/jira/browse/DERBY-3327 Project: Derby Issue Type: New Feature Components: Security, SQL Reporter: Dag H. Wanvik Assignee: Dag H. Wanvik Fix For: 10.4.0.0 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat The current LanguageConnectionContext keeps the user authorization identifier for an SQL session. The lcc is shared context also for nested connections (opened from stored procedures). So far, for roles, the current role has been stored in the lcc also. However, SQL requires that authorization identifers be pushed on a authorization stack when calling a stored procedure, cf. SQL 2003, vol 2, section 4.34.1.1 and 4.27.3. This allows a caller to keep its current role after a call even if changed by the stored procedure. This issue will implement the current role name part (cell) of the authorization stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.
TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR. -- Key: DERBY-3341 URL: https://issues.apache.org/jira/browse/DERBY-3341 Project: Derby Issue Type: Bug Components: SQL Reporter: Daniel John Debrunner Fix For: 10.4.0.0 Defining a column in the returned type as CHAR(10) requires that the returned value be of length 10 characters. Defining a table function with a return type of: returns TABLE column0 char( 10 ), column1 char( 10 )) seems to just return whatever the Java ResultSet implementation handed it. My guess this is true for all variable length types, no casting of the value occurs when it is returned to the SQL domain. Java single value functions and procedure out parameters do perform any required casting to ensure the value is of the declared type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3341) TABLE FUNCTION returning CHAR values does not return a correct value if the Java ResultSet class returns a value less than the length of the defined CHAR.
[
https://issues.apache.org/jira/browse/DERBY-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel John Debrunner updated DERBY-3341:
-
Attachment: derby_3341_test.txt
Quick hacked up modification to TableFunctionTest that shows the problem.
Note the change from
-else { assertTrue( expectedValue.equals( actualValue ) ); }
+else { assertEquals(expectedValue, actualValue); }
This results in the values being displayed if the test fails and there is more
useful and clearer than explicitly performing the equals().
The test itself is actually a little hard to get into, it doesn't follow the
established JUnit pattern of having fixtures being with test so it's hard to
see where the fixtures are. It also seems to duplicate existing utility methods
such as testing the contents of result sets and dropping a schema.
TABLE FUNCTION returning CHAR values does not return a correct value if the
Java ResultSet class returns a value less than the length of the defined CHAR.
--
Key: DERBY-3341
URL: https://issues.apache.org/jira/browse/DERBY-3341
Project: Derby
Issue Type: Bug
Components: SQL
Reporter: Daniel John Debrunner
Fix For: 10.4.0.0
Attachments: derby_3341_test.txt
Defining a column in the returned type as CHAR(10) requires that the returned
value be of length 10 characters.
Defining a table function with a return type of:
returns TABLE column0 char( 10 ), column1 char( 10 ))
seems to just return whatever the Java ResultSet implementation handed it.
My guess this is true for all variable length types, no casting of the value
occurs when it is returned to the SQL domain.
Java single value functions and procedure out parameters do perform any
required casting to ensure the value is of the declared type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Another newbie internals question
Hi Frank, You might be able to accomplish what you need by doing the following: 1) Bring up the server with user authentication turned on, with derby.database.defaultConnectionMode set to noAccess, and with derby.database.fullAccess set to be the name of your database owner. This should lock out everyone except for the database owner. 2) Then connect as the database owner, create your database, and initialize it with your functions, other schema objects, and data. 3) Then set derby.database.defaultConnectionMode to fullAccess and unset derby.database.fullAccess. This should allow the other users in. I say might because I haven't tried this experiment. These properties along with authentication are discussed in the Derby Developer's Guide in the sections titled User authorizations and Working with user authentication. Hope this helps, -Rick Frank Griffin wrote: I want to bring up a captive instance of Derby as a JDBC server. I want to do this using a front class of my own, because I want to customize the environment somewhat (set a few system properties, load and launch a few custom classes, whatever). This should all a simple thing, just wrapping the normal Derby invocation class; here's the kicker: once Derby is initialized, I want to initiate a JDBC session with it and submit a series of customizing SQL statements (CREATE FUNCTIONs for Table Functions). Modifying Derby code is OK for this, but I'd rather keep modifications to a minimum. Is there a clean way to do this other than starting a Thread which attempts JDBC connect() until Derby is ready ? Basically, I need to hook into someplace in Derby once it is enabled for JDBC in order to force-feed some commands before the real clients come along, so that the TableFunctions I'm setting up will be available for them. I don't really care if users are locked out before these things are processed; I can live with telling people just let it come up fully, but of course it would be nice to ensure availability from the get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? Thanks, Frank Griffin
Re: Regression Filter (was Re: Blockers and 10.4)
Kathey Marsden wrote: Rick Hillegas wrote: Kathey Marsden wrote: [EMAIL PROTECTED] wrote: Is this query saved as a public filter in Jira? I could not find it. It is the Jira filter Derby Open Product Regressions. I was wondering if a Jira admin could subscribe derby-dev to this filter to get a report once a week. Hi Kathey, I found a filter called Derby Open Regressions. I have subscribed derby-dev to receive a copy of this report every Sunday. Please let me know if that's not what you wanted. That filter does not pick up the issues that are in progress. There is another one Derby Open Product Regressions which looks ok. Derby Open Regressions then can probably be deleted. Kathey I must be going blind. I don't see a filter called Derby Open Product Regressions. Can you tell me where it lives in your list of filters? Rick
Re: Another newbie internals question
Frank Griffin wrote: get-go (of course, how you could open JDBC access without actually opening JDBC access is a bit of a conundrum). Any ideas or direction ? You could connect with the embedded driver to do your initial setup before starting network server and letting clients in. Kathey
[jira] Created: (DERBY-3342) DatabaseMetaData.getProcedureColumns() returns incorrect nullability for column 9 LENGTH
DatabaseMetaData.getProcedureColumns() returns incorrect nullability for column 9 LENGTH Key: DERBY-3342 URL: https://issues.apache.org/jira/browse/DERBY-3342 Project: Derby Issue Type: Bug Components: JDBC, SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner DatabaseMetaDataTest.testGetProceduresGetProcColumns asserts that column 9 (LENGTH) is NULLABLE. (line 4364 of the test). However the column comes directly from the internal virtual table GetProcedureColumns which has its length column as not nullable (line 327 of GetProcedureColumns.java). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Regression Filter (was Re: Blockers and 10.4)
I must be going blind. I don't see a filter called Derby Open Product Regressions. Can you tell me where it lives in your list of filters? In my list it shows up just before Derby Open Regressions. In manage filters though it shows up under Your filters with sharing: Group:derby-developers, so maybe it is only I that can see it for some reason. If you can't see it is it possible to change the Derby Open Regressions to include In Progress. That would be just as good. I couldn't seem to do it myself, but maybe with your karma ... Kathey
[jira] Commented: (DERBY-3342) DatabaseMetaData.getProcedureColumns() returns incorrect nullability for column 9 LENGTH
[ https://issues.apache.org/jira/browse/DERBY-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561533#action_12561533 ] Daniel John Debrunner commented on DERBY-3342: -- I noticed this because I was removing the last use of setNullability() for DERBY-2775. My change was in ConditionalNode and making it caused DatabaseMetaDataTest to fail and upon investigation actually make the nullability correct for column 9 LENGTH. Strange thing is that the LENGTH column 9 will not go through ConditionalNode, however columns 10 and 11 of the getProcedureColumns columns do involve a ConditionalNode, ie. a CASE expression. So this bug maybe an example of what DERBY-2775 is trying to solve, the state of one node accidentally changing another because they happen to share a reference to a mutable DataTypeDescriptor. DatabaseMetaData.getProcedureColumns() returns incorrect nullability for column 9 LENGTH Key: DERBY-3342 URL: https://issues.apache.org/jira/browse/DERBY-3342 Project: Derby Issue Type: Bug Components: JDBC, SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner DatabaseMetaDataTest.testGetProceduresGetProcColumns asserts that column 9 (LENGTH) is NULLABLE. (line 4364 of the test). However the column comes directly from the internal virtual table GetProcedureColumns which has its length column as not nullable (line 327 of GetProcedureColumns.java). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561537#action_12561537 ] Rick Hillegas commented on DERBY-2109: -- If such a feature can be delayed until there is some actual need for it, then I think it just resolves to a simple choice: A) name for SystemPrincipal is a user identifier (supports regular and delimited identifiers) and thus matches all other places where a user name is specified in a Java/JDBC context. B) name for SystemPrincipal is the canonical representation of an user identifier, which leads to easier to read policy files but does not match existing Java/JDBC practice. I'm afraid I don't understand what you are saying here. I am suggesting the following. The following policy file declarations result in the same SystemPrincipal: SystemPrincipal Edward SystemPrincipal EdWard SystemPrincipal \EDWARD\ All of the following SystemPrincipals are different: SystemPrincipal Edward SystemPrincipal \Edward\ SystemPrincipal \EdWard\ System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Assignee: Martin Zaun Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2109) System privileges
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561538#action_12561538 ] Daniel John Debrunner commented on DERBY-2109: -- That's the same as A. A) name for SystemPrincipal is a user identifier (supports regular and delimited identifiers) and thus matches all other places where a user name is specified in a Java/JDBC context. System privileges - Key: DERBY-2109 URL: https://issues.apache.org/jira/browse/DERBY-2109 Project: Derby Issue Type: New Feature Components: Security Affects Versions: 10.3.1.4 Reporter: Rick Hillegas Assignee: Martin Zaun Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html Add mechanisms for controlling system-level privileges in Derby. See the related email discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151. The 10.2 GRANT/REVOKE work was a big step forward in making Derby more secure in a client/server configuration. I'd like to plug more client/server security holes in 10.3. In particular, I'd like to focus on authorization issues which the ANSI spec doesn't address. Here are the important issues which came out of the email discussion. Missing privileges that are above the level of a single database: - Create Database - Shutdown all databases - Shutdown System Missing privileges specific to a particular database: - Shutdown that Database - Encrypt that database - Upgrade database - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs) Note that 10.2 gave us GRANT/REVOKE control over the following database-specific issues, via granting execute privilege to system procedures: Jar Handling Backup Routines Admin Routines Import/Export Property Handling Check Table In addition, since 10.0, the privilege of connecting to a database has been controlled by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode) as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3304) Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable
[ https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561565#action_12561565 ] Dag H. Wanvik commented on DERBY-3304: -- I meant only that CallStatementResultSet#close is called (indirectly) from CallStatementResultSet#open (see stack trace in https://issues.apache.org/jira/browse/DERBY-3304?focusedCommentId=12557476#action_12557476). Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable -- Key: DERBY-3304 URL: https://issues.apache.org/jira/browse/DERBY-3304 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Attachments: Main.java Repro (Main.java) that shows changed behavior after svn 602991 (the patch committed for this issue). It seems a regression: (originally from Dag H. Wanvik attached to DERBY-1585) An explicit commit inside a stored procedure makes a dynamic result sets passed out unavailable, even if the commit is executed *prior* to the result set; as in the repro. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always
Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always -- Key: DERBY-3343 URL: https://issues.apache.org/jira/browse/DERBY-3343 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.2.1 Environment: gentoo linux amd64 Reporter: William Becker The following series of statements fails: j connect 'jdbc:derby:test;create=true'; ij create table t (id int primary key generated always as identity); 0 rows inserted/updated/deleted ij prepare p as 'insert into t(id) values (default)'; ij execute p; 1 row inserted/updated/deleted ij execute p; ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL080123140906700' defined on 'T'. There is a more detailed discussion about it here: http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3304) Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable
[ https://issues.apache.org/jira/browse/DERBY-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561582#action_12561582 ] Mamta A. Satoor commented on DERBY-3304: Sorry for misinterpreting your comment, Dag. You are right, in this specific test case, where there is a commit inside the java stored procedure, close is getting called on CallStatementResultSet which is just getting opened. I think work on DERBY-3037 will help resolve this issue too. In DERBY-3037, we have an example of Java Stored routine which is a function, which also does a commit inside it. And that commit causes the resultset that will be returned by the function to close. I am hoping to get some pointers on how to recognize which resultsets should be closed and which should be left often. Explicit commit inside a java procedure makes a dynamic result sets passed out unavailable -- Key: DERBY-3304 URL: https://issues.apache.org/jira/browse/DERBY-3304 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Attachments: Main.java Repro (Main.java) that shows changed behavior after svn 602991 (the patch committed for this issue). It seems a regression: (originally from Dag H. Wanvik attached to DERBY-1585) An explicit commit inside a stored procedure makes a dynamic result sets passed out unavailable, even if the commit is executed *prior* to the result set; as in the repro. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3340) Add debug target to Netbeans 6.0 project file
[ https://issues.apache.org/jira/browse/DERBY-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-3340. Resolution: Fixed Fix Version/s: 10.4.0.0 Derby Info: (was: [Patch Available]) Committed 'd3340-1.diff' to trunk with revision 614445. Thanks for the patch, Thomas! Add debug target to Netbeans 6.0 project file - Key: DERBY-3340 URL: https://issues.apache.org/jira/browse/DERBY-3340 Project: Derby Issue Type: Improvement Components: Tools Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Trivial Fix For: 10.4.0.0 Attachments: d3340-1.diff, d3340-1.stat The project.xml file for Netbeans 6.0 is missing a debug target. Whenever 'svn revert' is executed, the debug target needs to be added again to run the NB debugger. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
