[jira] Commented: (DERBY-2954) Add commands to NetworkServerControl for interacting with the replication functionality
[ https://issues.apache.org/jira/browse/DERBY-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563898#action_12563898 ] Jørgen Løland commented on DERBY-2954: -- As stated in the func spec on DERBY-2872, NetworkServerControl commands will not be included in the 10.4 release. For this release, we will only have connection properties. Hence, the committed patch (v5) on this issue should be reverted. v6 seems to never have been committed. I reverted the patch locally and ran all tests without errors. Add commands to NetworkServerControl for interacting with the replication functionality --- Key: DERBY-2954 URL: https://issues.apache.org/jira/browse/DERBY-2954 Project: Derby Issue Type: Sub-task Components: Miscellaneous Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: NetworkServerControlCmds_v1.diff, NetworkServerControlCmds_v1.stat, NetworkServerControlCmds_v2.diff, NetworkServerControlCmds_v2.stat, NetworkServerControlCmds_v3.diff, NetworkServerControlCmds_v3.stat, NetworkServerControlCmds_v4.diff, NetworkServerControlCmds_v4.stat, NetworkServerControlCmds_v5.diff, NetworkServerControlCmds_v5.stat, NetworkServerControlCmds_v6.diff, NetworkServerControlCmds_v6.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t
[
https://issues.apache.org/jira/browse/DERBY-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563922#action_12563922
]
Knut Anders Hatlen commented on DERBY-3243:
---
The new patch looks fine, but it still has the typos I mentioned in an earlier
comment. It should also change LOBStoredProcedure.BLOBCREATELOCATOR and
LOBStoredProcedure.CLOBCREATELOCATOR so that they use getLocator() instead of
addLOBMapping().
I think this change also means that addLOBMapping() should be removed from
EngineConnection and BrokeredConnection, and made package private in the
EmbedConnection class.
It would also be good to make the locator field in EmbedBlob/EmbedClob final,
so that we check on compile-time that it hasn't been forgotten in one of the
constructors.
(jdbc net client) exception during normal iteration through ResultSet of
select * from t
Key: DERBY-3243
URL: https://issues.apache.org/jira/browse/DERBY-3243
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.2.1
Environment: -- Java Information --
Java Version:1.4.2_03
Java Vendor: Sun Microsystems Inc.
Java home: C:\Programme\Java\j2re1.4.2_03
Java classpath: derbyclient.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: cbdqok
Java user home: C:\Dokumente und Einstellungen\cbdqok
Java user dir: D:\users\cbdqok\privat\osj\lib_derby_net\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
- Derby Information
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 -
(561794)
--
- Locale Information -
--
Reporter: Oliver Seidel
Priority: Critical
Attachments: derby-3243_fix_double_hashmap_entry_diff.txt,
derby-3243_fix_double_hashmap_entry_diff2.txt,
derby-3243_fix_double_hashmap_entry_stat.txt
Thanks again to the DERBY developers.
For my convenience I use the client/server variant of DERBY. This is where
the error occurs. I have temporarily alleviated the problem for my case by
using the embedded version.
I'm forced to use outlook and have built a program which siphons the messages
into a derby database (phase 1 -- table has two varchar fields and a clob).
When reading them back (phase 2 -- simple select of all records in no
particular order, all 3 attributes), it has developed an exception. This is
a result of data volume. I have reduced the problem to a single
demonstration program.
This behaviour, and the fact that the error is not a DERBY Exception, but a
proper exception coming back from the JDBC call, leads me to the diagnosis
that it is a derby network client jdbc problem.
The problem has been reproduced once by Bryan Pendleton:
http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
I'll try to attach the code error.java; it can also be found on:
http://www.os1.net/error.java
Please use as follows:
javac -classpath derby.jar:derbynet.jar error.java
java -cp .:derby.jar:derbynet.jar error
It will create a directory test_db and fill it with approx 120mb data.
Then you will observe the failure.
/* -*- Mode:Java; c-basic-offset:8 -*- */
//
public class error {
//
public static final int port = 1527;
public static final String host = 127.0.0.1;
//
public static void log(String x) { System.out.println(x); };
//
public static void log_stacktrace(Exception e) {
java.io.StringWriter sw = new java.io.StringWriter();
java.io.PrintWriter pw = new java.io.PrintWriter(sw);
e.printStackTrace(pw);
log(sw.toString());
};
//
public static void start_server() {
try {
org.apache.derby.drda.NetworkServerControl server =
new
org.apache.derby.drda.NetworkServerControl(java.net.InetAddress.getByName(host),port);
server.start(null);
try { java.lang.Thread.sleep(5000); } catch (Exception
e) { };
[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=12563914#action_12563914 ] Dyre Tjeldvoll commented on DERBY-3301: --- AB I was operating on the assumption that derbyall ran cleanly with the 4c patch; I hadn't run it myself. I talked to Thomas offline yesterday and he was adamant that he HAD run derbyall with 0 failed tests. Which was true, except that when he looked closer at derbyall_report.txt it turned out that an environment problem also had caused 0 tests to be run... 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 Assignee: Thomas Nielsen Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.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 INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE
[jira] Updated: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepthi Devaki A R updated DERBY-3213: -- Attachment: DERBY-3213_diff Attached file is the fix for this issue. SQLChar.trim method is unused and could be removed -- Key: DERBY-3213 URL: https://issues.apache.org/jira/browse/DERBY-3213 Project: Derby Issue Type: Improvement Components: Newcomer, SQL Reporter: Bryan Pendleton Assignee: Deepthi Devaki A R Priority: Minor Attachments: DERBY-3213_diff As part of researching DERBY-2352, I came to the conclusion that the trim() method in SQLChar.java is no longer used, and could be removed. It appears that all calls to this method have been switched to call ansiTrim() instead. Hopefully, this just requires removing the code from SQLChar.java and StringDataValue.java, and running all the tests to verify that nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2548) NullPointerException through client/am/EncryptionManager
[ https://issues.apache.org/jira/browse/DERBY-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-2548: Attachment: DERBY-1400.diff Removed all the variables and added comments Attaching a fix do evaluate and send comoments. NullPointerException through client/am/EncryptionManager Key: DERBY-2548 URL: https://issues.apache.org/jira/browse/DERBY-2548 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren Assignee: Abhilash T.G Priority: Trivial Attachments: DERBY-1400.diff Encountered a NullPointerException that doesn't make it to the enduser / application while debugging test jdbcapi/DataSourceTest in one of my eclipse workspaces: org/apache/derby/client/am/EncryptionManager; constructor: public EncryptionManager(Agent agent) : throw new SqlException(agent_.logWriter_, agent_ was null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3364) Replication failover implementation must be modified to fail at the master after slave has been stopped
Replication failover implementation must be modified to fail at the master after slave has been stopped --- Key: DERBY-3364 URL: https://issues.apache.org/jira/browse/DERBY-3364 Project: Derby Issue Type: Bug Components: Replication Reporter: V.Narayanan Jorgen says... I tried to run the failover command on the master, which seems to work fine as long as the master and slave are still connected. If the slave has been stopped for some reason, however, failover hangs on MasterController#startFailover here: ack = transmitter.readMessage(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3364) Replication failover implementation must be modified to fail at the master after slave has been stopped
[ https://issues.apache.org/jira/browse/DERBY-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-3364: -- Assignee: V.Narayanan Replication failover implementation must be modified to fail at the master after slave has been stopped --- Key: DERBY-3364 URL: https://issues.apache.org/jira/browse/DERBY-3364 Project: Derby Issue Type: Bug Components: Replication Reporter: V.Narayanan Assignee: V.Narayanan Jorgen says... I tried to run the failover command on the master, which seems to work fine as long as the master and slave are still connected. If the slave has been stopped for some reason, however, failover hangs on MasterController#startFailover here: ack = transmitter.readMessage(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepthi Devaki A R updated DERBY-3213: -- Attachment: (was: DERBY-3213_diff) SQLChar.trim method is unused and could be removed -- Key: DERBY-3213 URL: https://issues.apache.org/jira/browse/DERBY-3213 Project: Derby Issue Type: Improvement Components: Newcomer, SQL Reporter: Bryan Pendleton Assignee: Deepthi Devaki A R Priority: Minor As part of researching DERBY-2352, I came to the conclusion that the trim() method in SQLChar.java is no longer used, and could be removed. It appears that all calls to this method have been switched to call ansiTrim() instead. Hopefully, this just requires removing the code from SQLChar.java and StringDataValue.java, and running all the tests to verify that nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1400) Cleanup code in network server's DRDAStatement class
[ https://issues.apache.org/jira/browse/DERBY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhilash T.G updated DERBY-1400: Attachment: DERBY-1400.diff made tha changes Cleanup code in network server's DRDAStatement class Key: DERBY-1400 URL: https://issues.apache.org/jira/browse/DERBY-1400 Project: Derby Issue Type: Improvement Components: Network Server, Newcomer Affects Versions: 10.1.3.1, 10.2.1.6 Reporter: Deepa Remesh Assignee: Abhilash T.G Priority: Trivial Attachments: DERBY-1400.diff The following cleanup tasks were identified as part of DERBY-1002 (http://issues.apache.org/jira/browse/DERBY-1002): * pkgcnstkn, pkgid, pkgsn variables can be removed from DRDAStatement since these are derived from pkgnamcsn object. * Look into what is required by initialize() of default statement. Currently, initialize just calls setTypDefValues(). Once the purpose of this method is confirmed, we may need to modify the comments at places it is currently called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover
[ https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-3205: --- Attachment: failover_impl_3205_v2.stat failover_impl_3205_v2.diff Thank you for the review and comments on the patch Jorgen! I have fixed issues 1-6 pointed out and have raised Derby-3364 for 7. 4) There are two Attribute.java files. I'm not sure if both are in use, but previously replication attributes have been added to both files. We either need some insight on which file can be ignored or continue to add the attributes to both files. I used the following comments to in org.apache.derby.iapi.reference.Attributes to conclude that we need to place the failover attribute in both the files. At some point this class should be replaced by org.apache.derby.shared.common.reference.Attribute. The issue is that this class is used by ij to check attributes, ij uses reflection on this class to get the list of valid attributes. The expanded class in shared has the client attributes as well. Ideally ij would work of an explicit list of attributes and not infer the set from reflection. See DERBY-1151 I shall run tests on this patch and shall post results by today evening. Replication: Add connection url command options for starting, stopping slave and for failover - Key: DERBY-3205 URL: https://issues.apache.org/jira/browse/DERBY-3205 Project: Derby Issue Type: Sub-task Components: JDBC Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: derby-3205_startslave_dontcommit.diff, derby-3205_startslave_dontcommit.stat, failover_impl_3205_NotForCommit_v1.diff, failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff, failover_impl_3205_v1.stat, failover_impl_3205_v2.diff, failover_impl_3205_v2.stat, Socket_Close_Fix_v1.diff, Socket_Close_Fix_v1.stat, startSlave_1a.diff, startSlave_1a.stat, startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, StopSlave_impl_3205_NotForCommit_v1.stat, stopSlave_v1a.diff, stopSlave_v1a.stat, stopSlave_v1b.diff, stopSlave_v1b.stat Add commands to start and stop the replication slave using properties or connection url. Example: 'jdbc:derby:hostdbname;startSlave=true'; 'jdbc:derby:hostdbname;stopSlave=true'; 'jdbc:derby:hostdbname;failover=true; Connection url options that must be recognized: startSlave=true stopSlave=true failover=true slaveHost=host (optional, defaults to localhost) (only for startSlave) slavePort=port (optional, defaults to 8001) (only for startSlave) See functional specification on Derby-2872 for further details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2239: -- Derby Info: [Patch Available] Example of SelectExpression for GROUP BY clause is mistaken --- Key: DERBY-2239 URL: https://issues.apache.org/jira/browse/DERBY-2239 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html Reporter: Tomohito Nakayama Assignee: Jazarine Jamal Attachments: DERBY2239-ref.diff, newref.zip There is next example. -- List head count of each department, -- the department number (WORKDEPT), and the average departmental salary (SALARY) -- for all departments in the EMPLOYEE table. -- Arrange the result table in ascending order by average departmental salary. SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 Comment told that head count of each department is listed, but not exaxtly. I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2239: -- Attachment: newref.zip DERBY2239-ref.diff I have made changes to the file trunk/src/ref/rrefselectexpression.dita. The following lines : SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 have been replaced with: SELECT COUNT(*),WORK_DEPT,AVG(SALARY) FROM EMPLOYEE GROUP BY WORK_DEPT ORDER BY 3; I build the new file with ant html and the resulting html page: rrefselectexpression.html contains the corrected code. The file newref.zip contains the corrected page. Please have a look at it. Example of SelectExpression for GROUP BY clause is mistaken --- Key: DERBY-2239 URL: https://issues.apache.org/jira/browse/DERBY-2239 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html Reporter: Tomohito Nakayama Assignee: Jazarine Jamal Attachments: DERBY2239-ref.diff, newref.zip There is next example. -- List head count of each department, -- the department number (WORKDEPT), and the average departmental salary (SALARY) -- for all departments in the EMPLOYEE table. -- Arrange the result table in ascending order by average departmental salary. SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 Comment told that head count of each department is listed, but not exaxtly. I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepthi Devaki A R updated DERBY-3213: -- Attachment: DERBY-3213.diff I removed the code for trim() from SQLChar.java and StringDataValue.java. I rebuild everything. There was no error . SQLChar.trim method is unused and could be removed -- Key: DERBY-3213 URL: https://issues.apache.org/jira/browse/DERBY-3213 Project: Derby Issue Type: Improvement Components: Newcomer, SQL Reporter: Bryan Pendleton Assignee: Deepthi Devaki A R Priority: Minor Attachments: DERBY-3213.diff As part of researching DERBY-2352, I came to the conclusion that the trim() method in SQLChar.java is no longer used, and could be removed. It appears that all calls to this method have been switched to call ansiTrim() instead. Hopefully, this just requires removing the code from SQLChar.java and StringDataValue.java, and running all the tests to verify that nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3021) Replication: Add a ReplicationSlave controller that will manage replication on the slave side
[ https://issues.apache.org/jira/browse/DERBY-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland resolved DERBY-3021. -- Resolution: Fixed Replication: Add a ReplicationSlave controller that will manage replication on the slave side - Key: DERBY-3021 URL: https://issues.apache.org/jira/browse/DERBY-3021 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-3021-1.diff, derby-3021-1.stat, derby-3021-1b.diff, derby-3021-1b.stat, derby-3021-2a.diff, derby-3021-2a.stat, derby-3021-2b.diff, derby-3021-2b.stat, derby-3021-2c.diff The replication slave role includes many tasks: * set up a network connection with the master * receive chunks of log from the master, and parse these into individual log records * append log records to the local log file * make sure that the recovery process is not allowed to access the logfile we are currently writing to * etc This issue is for adding a controller that will start/stop/initiate all services needed for the replication slave role. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3021) Replication: Add a ReplicationSlave controller that will manage replication on the slave side
[ https://issues.apache.org/jira/browse/DERBY-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland closed DERBY-3021. Replication: Add a ReplicationSlave controller that will manage replication on the slave side - Key: DERBY-3021 URL: https://issues.apache.org/jira/browse/DERBY-3021 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-3021-1.diff, derby-3021-1.stat, derby-3021-1b.diff, derby-3021-1b.stat, derby-3021-2a.diff, derby-3021-2a.stat, derby-3021-2b.diff, derby-3021-2b.stat, derby-3021-2c.diff The replication slave role includes many tasks: * set up a network connection with the master * receive chunks of log from the master, and parse these into individual log records * append log records to the local log file * make sure that the recovery process is not allowed to access the logfile we are currently writing to * etc This issue is for adding a controller that will start/stop/initiate all services needed for the replication slave role. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland resolved DERBY-3184. -- Resolution: Fixed Fix Version/s: 10.4.0.0 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 Fix For: 10.4.0.0 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-3b.diff, 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] Closed: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland closed DERBY-3184. 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 Fix For: 10.4.0.0 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-3b.diff, 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-3361) Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode.
[ https://issues.apache.org/jira/browse/DERBY-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563992#action_12563992 ] Jørgen Løland commented on DERBY-3361: -- Working on this issue, I realize that host and port information would help debugging failed replication startups. I think we should print to derby.log which host and port the ServerSocket is listening to. I plan to add this in the same patch. Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode. - Key: DERBY-3361 URL: https://issues.apache.org/jira/browse/DERBY-3361 Project: Derby Issue Type: Bug Components: Replication Affects Versions: 10.4.0.0 Environment: Trunk (615841) + patch DERBY-3205/stopSlave_v1b Reporter: Ole Solberg Assignee: Jørgen Løland Specifying a non-existant slaveHost for startSlave seemingly succeeds in starting slave mode. --- CONNECT 'jdbc:derby://atum11:/test;startSlave=true;slaveHost=noSuchHost;slavePort=8989'; ERROR XRE08: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE08, SQLERRMC: Replication slave mode started successfully for database 'test'. Connection refused because the database is in replication slave mode. Slave derby.log shows a NPE: -- 2008-01-29 11:52:40.050 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.4.0.0 alpha - (615841M): instance c013800d-0117-c563-d051-03bf6570 on database directory /export/home/tmp/os136789/Replication_common_Trunk/slave/test Database Class Loader started - derby.database.classpath='' 2008-01-29 11:52:40.308 GMT: Shutting down instance c013800d-0117-c563-d051-03bf6570 2008-01-29 11:52:40.320 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.4.0.0 alpha - (615841M): instance a816c00e-0117-c563-d051-03bf6570 on database directory /export/home/tmp/os136789/Replication_common_Trunk/slave/test 2008-01-29 11:52:40.814 GMT Thread[DRDAConnThread_2,5,main] Cleanup action starting ERROR XRE08: Replication slave mode started successfully for database 'test'. Connection refused because the database is in replication slave mode. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423) at org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73) at org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:211) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1346) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1296) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3033) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1090) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:932) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:277) Cleanup action completed 2008-01-29 11:52:40.816 GMT Thread[DRDAConnThread_2,5,main] Cleanup action starting ERROR XRE08: Replication slave mode started successfully for database 'test'. Connection refused because the database is in replication slave mode. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:423) at org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73) at org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:211) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:234) at
[jira] Commented: (DERBY-3351) Implement a Pluggable Storage Engine Architecture in Derby
[ https://issues.apache.org/jira/browse/DERBY-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563990#action_12563990 ] Dibyendu Majumdar commented on DERBY-3351: -- Dan Jørgen, Many thanks for the info on how the monitor system works. Implement a Pluggable Storage Engine Architecture in Derby -- Key: DERBY-3351 URL: https://issues.apache.org/jira/browse/DERBY-3351 Project: Derby Issue Type: New Feature Components: Services, SQL, Store Reporter: Dibyendu Majumdar Assignee: Dibyendu Majumdar My aim is to create a pluggable storage engine architecture for Derby, so that the default store implementation can be replaced with alternative storage engines. I have created my own storage engine which I would like to use with Derby's SQL layer, so that is a motivation. But I also think that this will benefit the community, and could lead to a pluggable storage engine architecture similar to that of MySQL. I am not yet sure where the storage engine boundary should lie. I would welcome input in this area. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2954) Add commands to NetworkServerControl for interacting with the replication functionality
[ https://issues.apache.org/jira/browse/DERBY-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-2954: - Derby Info: [Patch Available] Setting patch available since patch v5 needs to be reverted for now (10.4 release) Add commands to NetworkServerControl for interacting with the replication functionality --- Key: DERBY-2954 URL: https://issues.apache.org/jira/browse/DERBY-2954 Project: Derby Issue Type: Sub-task Components: Miscellaneous Affects Versions: 10.4.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Attachments: NetworkServerControlCmds_v1.diff, NetworkServerControlCmds_v1.stat, NetworkServerControlCmds_v2.diff, NetworkServerControlCmds_v2.stat, NetworkServerControlCmds_v3.diff, NetworkServerControlCmds_v3.stat, NetworkServerControlCmds_v4.diff, NetworkServerControlCmds_v4.stat, NetworkServerControlCmds_v5.diff, NetworkServerControlCmds_v5.stat, NetworkServerControlCmds_v6.diff, NetworkServerControlCmds_v6.stat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2978) Replication: Add slave replication mode
[ https://issues.apache.org/jira/browse/DERBY-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland reassigned DERBY-2978: Assignee: Jørgen Løland Replication: Add slave replication mode --- Key: DERBY-2978 URL: https://issues.apache.org/jira/browse/DERBY-2978 Project: Derby Issue Type: New Feature Components: Replication Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland One Derby instance will have the master role and another Derby instance will have the slave role when a database is replicated. See the functional specification of DERBY-2872 for more details about the roles. This JIRA is for issues that are part of the slave role. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover
[ https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563987#action_12563987 ] Jørgen Løland commented on DERBY-3205: -- Hi Narayanan, The failover patch v2 looks good to me, although I think SQLState.REPLICATION_UNABLE_TO_STOP_MASTER would give a better error message than REPLICATION_FAILOVER_UNSUCCESSFUL in RawStore#failover if that message was slightly changed to Could not perform replication operation because... . I don't consider this a blocker for the patch. I also ran all tests without any error. +1 to commit. Replication: Add connection url command options for starting, stopping slave and for failover - Key: DERBY-3205 URL: https://issues.apache.org/jira/browse/DERBY-3205 Project: Derby Issue Type: Sub-task Components: JDBC Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: derby-3205_startslave_dontcommit.diff, derby-3205_startslave_dontcommit.stat, failover_impl_3205_NotForCommit_v1.diff, failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff, failover_impl_3205_v1.stat, failover_impl_3205_v2.diff, failover_impl_3205_v2.stat, Socket_Close_Fix_v1.diff, Socket_Close_Fix_v1.stat, startSlave_1a.diff, startSlave_1a.stat, startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, StopSlave_impl_3205_NotForCommit_v1.stat, stopSlave_v1a.diff, stopSlave_v1a.stat, stopSlave_v1b.diff, stopSlave_v1b.stat Add commands to start and stop the replication slave using properties or connection url. Example: 'jdbc:derby:hostdbname;startSlave=true'; 'jdbc:derby:hostdbname;stopSlave=true'; 'jdbc:derby:hostdbname;failover=true; Connection url options that must be recognized: startSlave=true stopSlave=true failover=true slaveHost=host (optional, defaults to localhost) (only for startSlave) slavePort=port (optional, defaults to 8001) (only for startSlave) See functional specification on Derby-2872 for further details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564012#action_12564012 ] Tomohito Nakayama commented on DERBY-2239: -- I committed. Sendingsrc/ref/rrefselectexpression.dita Transmitting file data . Committed revision 616747. Example of SelectExpression for GROUP BY clause is mistaken --- Key: DERBY-2239 URL: https://issues.apache.org/jira/browse/DERBY-2239 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html Reporter: Tomohito Nakayama Assignee: Jazarine Jamal Attachments: DERBY2239-ref.diff, newref.zip There is next example. -- List head count of each department, -- the department number (WORKDEPT), and the average departmental salary (SALARY) -- for all departments in the EMPLOYEE table. -- Arrange the result table in ascending order by average departmental salary. SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 Comment told that head count of each department is listed, but not exaxtly. I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564011#action_12564011 ] Tomohito Nakayama commented on DERBY-2239: -- I checked three kind output of singlepage,multi page and PDF. There were no problem and I will commit it. Example of SelectExpression for GROUP BY clause is mistaken --- Key: DERBY-2239 URL: https://issues.apache.org/jira/browse/DERBY-2239 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html Reporter: Tomohito Nakayama Assignee: Jazarine Jamal Attachments: DERBY2239-ref.diff, newref.zip There is next example. -- List head count of each department, -- the department number (WORKDEPT), and the average departmental salary (SALARY) -- for all departments in the EMPLOYEE table. -- Arrange the result table in ascending order by average departmental salary. SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 Comment told that head count of each department is listed, but not exaxtly. I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan reassigned DERBY-2559: -- Assignee: Kristian Waagan recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-2239. --- Resolution: Fixed Example of SelectExpression for GROUP BY clause is mistaken --- Key: DERBY-2239 URL: https://issues.apache.org/jira/browse/DERBY-2239 Project: Derby Issue Type: Bug Components: Documentation Environment: http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html Reporter: Tomohito Nakayama Assignee: Jazarine Jamal Attachments: DERBY2239-ref.diff, newref.zip There is next example. -- List head count of each department, -- the department number (WORKDEPT), and the average departmental salary (SALARY) -- for all departments in the EMPLOYEE table. -- Arrange the result table in ascending order by average departmental salary. SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 Comment told that head count of each department is listed, but not exaxtly. I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3224) Get Suites.All to run on the phoneME advanced platform
[ https://issues.apache.org/jira/browse/DERBY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vemund Østgaard updated DERBY-3224: --- Derby Info: [Patch Available] Forgot to tick the patch available box when I uploaded the latest patch. Get Suites.All to run on the phoneME advanced platform -- Key: DERBY-3224 URL: https://issues.apache.org/jira/browse/DERBY-3224 Project: Derby Issue Type: Test Components: Test Environment: Product: phoneME Advanced (phoneme_advanced_mr2-b34) Profile: Foundation Profile Specification 1.1 JVM: CVM phoneme_advanced_mr2-b34 (interpreter loop) Reporter: Vemund Østgaard Assignee: Vemund Østgaard Attachments: 3224-diff, 3224-diff.stat, 3224-diffv2, 3224-diffv2.stat, 3224-diffv3, 3224-diffv3.stat I'm trying to get suites.All to run on the phoneME advanced platform. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t
[
https://issues.apache.org/jira/browse/DERBY-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564031#action_12564031
]
Øystein Grøvlen commented on DERBY-3243:
I think part of the confusion here is that EmbedConnection#lobHashMap
is used for two separate purposes. It was first added as a mechanism
for the NetworkServer to add locators mapping for locators that were
sent to the client. This mechanism was intented to by driven by the
NetworkServer, but EmbedConnection is used for storage since it is
persistent across client requests.
Later, the same hash map was used to store references to all internal
Lobs in order to be able to do clean-up at end of transaction. (I was
wrong when I earlier wrote that this was really only needed for LOB
objects that had associated temporary files. This mechanism is used
in order to invalidate any active LOB object at the end of
transaction.)
There are other ways to achieve invalidation at end of transaction,
but as long as we are using the current mechanism, it will be
necessary to keep track of all active LOB objects of a connection.
Given that, it is not necessary for the network server to do its own
book-keeping. Instead, it could rely on the embedded driver for this.
I think Kathey's patch is a step in the right direction here, but as
Knut Anders suggest I think we should go a step further and remove all
traces of how this is currently done by the network server.
I also think that it would be better if this clean-up was tied to
DERBY-3354 which I feel is more related. Then this JIRA could focus
on the DRDA problems that causes the reported bug. (I will discuss
that issue in a separate comment.)
(jdbc net client) exception during normal iteration through ResultSet of
select * from t
Key: DERBY-3243
URL: https://issues.apache.org/jira/browse/DERBY-3243
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.2.1
Environment: -- Java Information --
Java Version:1.4.2_03
Java Vendor: Sun Microsystems Inc.
Java home: C:\Programme\Java\j2re1.4.2_03
Java classpath: derbyclient.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: cbdqok
Java user home: C:\Dokumente und Einstellungen\cbdqok
Java user dir: D:\users\cbdqok\privat\osj\lib_derby_net\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
- Derby Information
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 -
(561794)
--
- Locale Information -
--
Reporter: Oliver Seidel
Priority: Critical
Attachments: derby-3243_fix_double_hashmap_entry_diff.txt,
derby-3243_fix_double_hashmap_entry_diff2.txt,
derby-3243_fix_double_hashmap_entry_stat.txt
Thanks again to the DERBY developers.
For my convenience I use the client/server variant of DERBY. This is where
the error occurs. I have temporarily alleviated the problem for my case by
using the embedded version.
I'm forced to use outlook and have built a program which siphons the messages
into a derby database (phase 1 -- table has two varchar fields and a clob).
When reading them back (phase 2 -- simple select of all records in no
particular order, all 3 attributes), it has developed an exception. This is
a result of data volume. I have reduced the problem to a single
demonstration program.
This behaviour, and the fact that the error is not a DERBY Exception, but a
proper exception coming back from the JDBC call, leads me to the diagnosis
that it is a derby network client jdbc problem.
The problem has been reproduced once by Bryan Pendleton:
http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
I'll try to attach the code error.java; it can also be found on:
http://www.os1.net/error.java
Please use as follows:
javac -classpath derby.jar:derbynet.jar error.java
java -cp .:derby.jar:derbynet.jar error
It will create a directory test_db and fill it with approx 120mb data.
Then you will observe the failure.
/* -*- Mode:Java; c-basic-offset:8 -*- */
//
public class error {
//
public static final int port = 1527;
public static final String host = 127.0.0.1;
//
public static void log(String
[jira] Assigned: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal reassigned DERBY-1824: - Assignee: Jazarine Jamal Permission/privlege names in exceptions should be in upper case as keywords, not lower case. Key: DERBY-1824 URL: https://issues.apache.org/jira/browse/DERBY-1824 Project: Derby Issue Type: Improvement Components: SQL Reporter: Daniel John Debrunner Assignee: Jazarine Jamal Priority: Minor E.g. ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. should be ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2548) NullPointerException through client/am/EncryptionManager
[ https://issues.apache.org/jira/browse/DERBY-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-2548: -- Derby Info: [Patch Available] NullPointerException through client/am/EncryptionManager Key: DERBY-2548 URL: https://issues.apache.org/jira/browse/DERBY-2548 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren Assignee: Abhilash T.G Priority: Trivial Attachments: DERBY-1400.diff Encountered a NullPointerException that doesn't make it to the enduser / application while debugging test jdbcapi/DataSourceTest in one of my eclipse workspaces: org/apache/derby/client/am/EncryptionManager; constructor: public EncryptionManager(Agent agent) : throw new SqlException(agent_.logWriter_, agent_ was null -- 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=12564039#action_12564039 ] Dag H. Wanvik commented on DERBY-3137: -- So, to clarify further, the following would be equivalent: ps.setString(1, \ SPACEADMIN \); // Role CNF of SPACEADMIN (surrounded by spaces on each side) ps.setString(1, \ SPACEADMIN \ ); // Role CNF of SPACEADMIN (surrounded by spaces on each side). TRIMable space in value string I am OK with moving towards stricter adherence here; I'll make an update patch. Thanks for the suggestion on reserving namespace. Since Derby uses SYS as a reserved schema name, I guess the SYS- prefix is as good as any. I'll add this to the specification and make an update patch. 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-1400) Cleanup code in network server's DRDAStatement class
[ https://issues.apache.org/jira/browse/DERBY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-1400: -- Derby Info: [Patch Available] Cleanup code in network server's DRDAStatement class Key: DERBY-1400 URL: https://issues.apache.org/jira/browse/DERBY-1400 Project: Derby Issue Type: Improvement Components: Network Server, Newcomer Affects Versions: 10.1.3.1, 10.2.1.6 Reporter: Deepa Remesh Assignee: Abhilash T.G Priority: Trivial Attachments: DERBY-1400.diff The following cleanup tasks were identified as part of DERBY-1002 (http://issues.apache.org/jira/browse/DERBY-1002): * pkgcnstkn, pkgid, pkgsn variables can be removed from DRDAStatement since these are derived from pkgnamcsn object. * Look into what is required by initialize() of default statement. Currently, initialize just calls setTypDefValues(). Once the purpose of this method is confirmed, we may need to modify the comments at places it is currently called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-3213: -- Derby Info: [Patch Available] SQLChar.trim method is unused and could be removed -- Key: DERBY-3213 URL: https://issues.apache.org/jira/browse/DERBY-3213 Project: Derby Issue Type: Improvement Components: Newcomer, SQL Reporter: Bryan Pendleton Assignee: Deepthi Devaki A R Priority: Minor Attachments: DERBY-3213.diff As part of researching DERBY-2352, I came to the conclusion that the trim() method in SQLChar.java is no longer used, and could be removed. It appears that all calls to this method have been switched to call ansiTrim() instead. Hopefully, this just requires removing the code from SQLChar.java and StringDataValue.java, and running all the tests to verify that nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t
[
https://issues.apache.org/jira/browse/DERBY-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564040#action_12564040
]
Øystein Grøvlen commented on DERBY-3243:
The reasoning for the check in NetCursor#locator was to be able to
both handle pre-10.3 servers, and 10.3 servers running in soft-upgrade
mode, both which ignore requests for use of locators. I guess the
first group could be handled by recognizing that the server is
pre-10.3, and it should also be possible to come up with a separate
mechanism to handle soft upgrade. However, It would be even better if
one where able to communicate the type of each value dynamically, but
I were not able to determine how to do this with DRDA. Does anybody
know?
I think that when I added the code that checked whether a locator or
LOB had been sent, I thought that the when a LOB was sent, its column
position would contain the length of the LOB with the high-order bit
set. However, it seems that what has originally been sent is not the
length of the LOB, but the length of the length field for the LOB, and
it is not the high-order bit that is set, but the high-order bit of
byte 3. When Layer B streaming was added, it seems the length of the
length field was fixed at 4 bytes so that now the client will always
receive 0x8004 for non-zero length LOBs.
I do not know whether the above is in accordance with the DRDA spec,
and it also seems that the client expect the high-order bit to be set when
the length is unknown. From NetCursor#isNonTrivialDataLob:
// if the high-order bit is set, length is unknown - set value to x'FF..FF'
if (((dataBuffer_[position]) 0x80) == 0x80) {
length = -1;
} else {
A quick, but dirty, way to fix the reported bug would be to make the
server skip 0x8004 when allocating locators, and make the client
check for this exact value when determining whether it has received a
locator or not.
(jdbc net client) exception during normal iteration through ResultSet of
select * from t
Key: DERBY-3243
URL: https://issues.apache.org/jira/browse/DERBY-3243
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.2.1
Environment: -- Java Information --
Java Version:1.4.2_03
Java Vendor: Sun Microsystems Inc.
Java home: C:\Programme\Java\j2re1.4.2_03
Java classpath: derbyclient.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: cbdqok
Java user home: C:\Dokumente und Einstellungen\cbdqok
Java user dir: D:\users\cbdqok\privat\osj\lib_derby_net\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
- Derby Information
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 -
(561794)
--
- Locale Information -
--
Reporter: Oliver Seidel
Priority: Critical
Attachments: derby-3243_fix_double_hashmap_entry_diff.txt,
derby-3243_fix_double_hashmap_entry_diff2.txt,
derby-3243_fix_double_hashmap_entry_stat.txt
Thanks again to the DERBY developers.
For my convenience I use the client/server variant of DERBY. This is where
the error occurs. I have temporarily alleviated the problem for my case by
using the embedded version.
I'm forced to use outlook and have built a program which siphons the messages
into a derby database (phase 1 -- table has two varchar fields and a clob).
When reading them back (phase 2 -- simple select of all records in no
particular order, all 3 attributes), it has developed an exception. This is
a result of data volume. I have reduced the problem to a single
demonstration program.
This behaviour, and the fact that the error is not a DERBY Exception, but a
proper exception coming back from the JDBC call, leads me to the diagnosis
that it is a derby network client jdbc problem.
The problem has been reproduced once by Bryan Pendleton:
http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
I'll try to attach the code error.java; it can also be found on:
http://www.os1.net/error.java
Please use as follows:
javac -classpath derby.jar:derbynet.jar error.java
java -cp .:derby.jar:derbynet.jar error
It will create a directory test_db and fill it with approx 120mb data.
Then you will observe the failure.
/* -*- Mode:Java; c-basic-offset:8 -*- */
//
public class error {
//
[jira] Updated: (DERBY-2760) Clean-up issues for UTF8Util.java
[ https://issues.apache.org/jira/browse/DERBY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2760: --- Derby Info: (was: [Patch Available]) Committed 'derby-2760-3a-extra_tests.diff' to trunk with revision 616786. Clean-up issues for UTF8Util.java - Key: DERBY-2760 URL: https://issues.apache.org/jira/browse/DERBY-2760 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4 Reporter: Knut Anders Hatlen Assignee: Kristian Waagan Priority: Trivial Fix For: 10.4.0.0 Attachments: derby-2760-1a-remove_unused_method.diff, derby-2760-2a-inner_class.diff, derby-2760-2b-inner_class.diff, derby-2760-3a-extra_tests.diff In DERBY-2646, some improvements to org.apache.derby.iapi.util.UTF8Util were suggested: - remove unused private method isDerbyEOFMarker(), or possibly rewrite it to fit into skipInternal() - skipInternal() should return an instance of a private inner class instead of an array -- 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: DataSourceReferenceTest.diff DataSourceReferenceTest.java When investigating the issue around introducing maxStatements into the client side data source(s), I ended up basically rewriting jdbcapi.DataSourceReferenceTest. The reason was that I had some trouble understanding it at first, and also that I needed more flexibility now that the three data source types (basic, connection pool and XA) are not equal any more. Does anyone have feedback on the (early) new version? Is it bad to rewrite it that heavily? (I recommend looking at the class itself, rather than the diff) If no one looks at it, I will commit it soon (after doing some more experiments running the new and old test to confirm that the errors the old uncovered are still uncovered in the new test). I have also attached a fix to DERBY-2559, which caused the test to be disabled for client data sources when running Java SE 6. Regarding solving the maxStatement issue, the method in ClientBaseDataSource cannot be named getMaxStatements if we do not add a setter as well. Having only the setter breaks the JavaBean / Reference contract and the JVM code fails with an NPE when it tries to create a new instance of the data source (using Reference). I solved this by giving the method another name. It will always return 0 in CBCP, whereas it will be overridden to return maxStatements in CPDS (and eventually XADS). This method will be used to obtain a value for maxStatements in the PooledConnection constructor to determine if statement caching shall be enabled or not. There are also alternative solutions by changing the method signatures. I will go for the former approach unless anyone clearly state their misapproval of it, or later testing reveals problems with the approach. 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: DataSourceReferenceTest.diff, DataSourceReferenceTest.java, 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-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2559: --- Attachment: derby-2559-1a.diff 'derby-2559-1a.diff' is a patch that fixes the reported problem, where attempts to (re)create a data source through Reference returned null. The cause was an if with entries for the pre-JDBC 4.0 classes (like ClientDataSource), but no entries for the JDBC 4.0 classes. I changed the factory class to use the same approach as the embedded driver, as it seemed to be easier to use reflection because of the mix between pre-JDBC 4.0 classes and JDBC 4.0 classes. The patch also removes the workaround (disabling) in DataSourceReferenceTest. I am not sure if the method behaves as documented. I don't think it will ever return null, but either succeed or throw an exception. I will look at the documentation in a separate patch. I'm running tests and will post the results later. Patch ready for review. recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Fix For: 10.4.0.0 Attachments: derby-2559-1a.diff Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2760) Clean-up issues for UTF8Util.java
[ https://issues.apache.org/jira/browse/DERBY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-2760. Resolution: Fixed I committed some trivial changes to trunk with revision 616788 (added 4 lines of comments). This concludes my work on this issue, and I believe it can be closed. Clean-up issues for UTF8Util.java - Key: DERBY-2760 URL: https://issues.apache.org/jira/browse/DERBY-2760 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4 Reporter: Knut Anders Hatlen Assignee: Kristian Waagan Priority: Trivial Fix For: 10.4.0.0 Attachments: derby-2760-1a-remove_unused_method.diff, derby-2760-2a-inner_class.diff, derby-2760-2b-inner_class.diff, derby-2760-3a-extra_tests.diff In DERBY-2646, some improvements to org.apache.derby.iapi.util.UTF8Util were suggested: - remove unused private method isDerbyEOFMarker(), or possibly rewrite it to fit into skipInternal() - skipInternal() should return an instance of a private inner class instead of an array -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2760) Clean-up issues for UTF8Util.java
[ https://issues.apache.org/jira/browse/DERBY-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-2760. - Thanks for fixing these issues, Kristian. Clean-up issues for UTF8Util.java - Key: DERBY-2760 URL: https://issues.apache.org/jira/browse/DERBY-2760 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4 Reporter: Knut Anders Hatlen Assignee: Kristian Waagan Priority: Trivial Fix For: 10.4.0.0 Attachments: derby-2760-1a-remove_unused_method.diff, derby-2760-2a-inner_class.diff, derby-2760-2b-inner_class.diff, derby-2760-3a-extra_tests.diff In DERBY-2646, some improvements to org.apache.derby.iapi.util.UTF8Util were suggested: - remove unused private method isDerbyEOFMarker(), or possibly rewrite it to fit into skipInternal() - skipInternal() should return an instance of a private inner class instead of an array -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2559) recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails
[ https://issues.apache.org/jira/browse/DERBY-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2559: --- Derby Info: [Patch Available] Fix Version/s: 10.4.0.0 recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails Key: DERBY-2559 URL: https://issues.apache.org/jira/browse/DERBY-2559 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.3.1.4 Reporter: Myrna van Lunteren Assignee: Kristian Waagan Fix For: 10.4.0.0 Attachments: derby-2559-1a.diff Consider the following code snippet from test DataSourceReferenceTest: Referenceable refDS = (Referenceable) ds; Reference dsAsReference = refDS.getReference(); String factoryClassName = dsAsReference.getFactoryClassName(); ObjectFactory factory = (ObjectFactory) Class.forName(factoryClassName).newInstance(); Object recreatedDS = factory.getObjectInstance(dsAsReference, null, null, null); - When ds is a ClientDataSource40 (i.e. when running with jdk16), recreatedDS is null. Note, that this showed up only after converting the test to junit, because the original test hardcoded the ds to be a ClientDataSource. I confirmed this not to be related to my changes for DERBY-2296 (which prompted me to convert the test), by backing out my changes to ClientBaseDataSource and client/am/Connection and rerunning the test (needed some minor adjustments of expected values table/array). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (23 issues) Subscriber: derby-dev Key Summary DERBY-3325 Add 'maxStatements' property to ClientConnectionPoolDataSource https://issues.apache.org/jira/browse/DERBY-3325 DERBY-2559 recreating a datasource using javax.naming.Reference from a ClientDataSource40 fails https://issues.apache.org/jira/browse/DERBY-2559 DERBY-3243 (jdbc net client) exception during normal iteration through ResultSet of select * from t https://issues.apache.org/jira/browse/DERBY-3243 DERBY-3213 SQLChar.trim method is unused and could be removed https://issues.apache.org/jira/browse/DERBY-3213 DERBY-1400 Cleanup code in network server's DRDAStatement class https://issues.apache.org/jira/browse/DERBY-1400 DERBY-3137 SQL roles: add catalog support https://issues.apache.org/jira/browse/DERBY-3137 DERBY-2548 NullPointerException through client/am/EncryptionManager https://issues.apache.org/jira/browse/DERBY-2548 DERBY-3224 Get Suites.All to run on the phoneME advanced platform https://issues.apache.org/jira/browse/DERBY-3224 DERBY-2954 Add commands to NetworkServerControl for interacting with the replication functionality https://issues.apache.org/jira/browse/DERBY-2954 DERBY-3205 Replication: Add connection url command options for starting, stopping slave and for failover https://issues.apache.org/jira/browse/DERBY-3205 DERBY-3301 Incorrect result from query with nested EXIST https://issues.apache.org/jira/browse/DERBY-3301 DERBY-3288 wrong query result in presence of a unique index https://issues.apache.org/jira/browse/DERBY-3288 DERBY-2592 Wrong description of IndexName field in public JavaDoc for LockTable https://issues.apache.org/jira/browse/DERBY-2592 DERBY-3355 Alter Column ... NULL ignores double quotes around column name https://issues.apache.org/jira/browse/DERBY-3355 DERBY-2683 tools and utilities guide: ij.URLCheck's list of checked attributes is not correct https://issues.apache.org/jira/browse/DERBY-2683 DERBY-3088 convert to junit, or otherwise eliminate version in tests which require an update of the master in the release management process https://issues.apache.org/jira/browse/DERBY-3088 DERBY-3189 Replication: Add connection url command options for starting and stopping master https://issues.apache.org/jira/browse/DERBY-3189 DERBY-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
Regression Test Report - Daily 616446 - Sun DBTG
[Auto-generated mail] *Daily* 616446/2008-01-29 18:01:08 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0273273 072.61% derbyall 01017310173 0 1440.79% suitesAll linN+1 0273273 098.95% derbyall 01017310173 0 118.77% suitesAll sles 0273273 071.49% derbyall 01017310173 0 957.79% suitesAll sol 0273273 075.89% derbyall 01017310173 0 1512.35% suitesAll solN+1 0273273 096.92% derbyall 01017310173 0 183.50% suitesAll sparc 0273273 065.66% derbyall 01017310173 0 360.57% suitesAll vista 0273273 0 132.91% derbyall NA NA NANA suitesAll w2003 0273273 096.70% derbyall 091519151 0 132.63% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-616446.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/616446_bySig.html *Jvm: 1.5* lin 0274274 071.21% derbyall 084558455 0 878.70% suitesAll linN+1 0274274 098.96% derbyall 084558455 0 116.21% suitesAll sles 0274274 070.42% derbyall 084558455 0 565.98% suitesAll sol 0274274 079.29% derbyall 084558455 0 837.95% suitesAll solN+1 0274274 088.53% derbyall 084558455 0 796.23% suitesAll sparc 0274274 066.97% derbyall 084558455 0 701.19% suitesAll vista NA NA NANA derbyall 074337433 0 488.83% suitesAll w2003 0274274 074.24% derbyall 074337433 0 258.42% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-616446.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/616446_bySig.html *Jvm: 1.4* lin 0271271 272.73% derbyall 084038403 0 795.24% suitesAll linN+1 0271271 299.03% derbyall 084038403 0 115.84% suitesAll sles 0271271 270.65% derbyall 084038403 0 526.47% suitesAll sol 0271271 278.28% derbyall 084038403 0 673.06% suitesAll solN+1 0271271 288.87% derbyall 084038403 0 744.75% suitesAll sparc 0271271 267.18% derbyall 084038403 0 694.78% suitesAll vista NA NA NANA derbyall NA NA NANA suitesAll w2003 0271271 275.20% derbyall 073827382 0 250.12% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-616446.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/616446_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/616446.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Created: (DERBY-3365) Network Server stores a dupliacate entry in the lob hash map for every lob
Network Server stores a dupliacate entry in the lob hash map for every lob -- Key: DERBY-3365 URL: https://issues.apache.org/jira/browse/DERBY-3365 Project: Derby Issue Type: Bug Components: Network Server Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Per discussion in DERBY-3243, Network Server stores a duplicate entry in the lob hashmap for every lob. I posted a preliminary patch to DERBY-3243 and received comments on the patch in that issue, but it makes more sense to separate the issue out from DERBY-3243. So opening up this new issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3366) Various formatting erros in L10N property files
Various formatting erros in L10N property files --- Key: DERBY-3366 URL: https://issues.apache.org/jira/browse/DERBY-3366 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.3.2.1 Reporter: Dyre Tjeldvoll Priority: Minor Fix For: 10.4.0.0 There are a number of formatting errors in the localization property files: - DRDA_InvalidValue.U appears twice in the drda property files (english and translations) - Spurious linefeed for XCL21.S in messages_zh_TW.properties - Quadruple single quote rather than double single quote for contraction apostrophes in messages_it.properties -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3366) Various formatting erros in L10N property files
[ https://issues.apache.org/jira/browse/DERBY-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll reassigned DERBY-3366: - Assignee: Dyre Tjeldvoll Various formatting erros in L10N property files --- Key: DERBY-3366 URL: https://issues.apache.org/jira/browse/DERBY-3366 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.3.2.1 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.4.0.0 Original Estimate: 72h Remaining Estimate: 72h There are a number of formatting errors in the localization property files: - DRDA_InvalidValue.U appears twice in the drda property files (english and translations) - Spurious linefeed for XCL21.S in messages_zh_TW.properties - Quadruple single quote rather than double single quote for contraction apostrophes in messages_it.properties -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3366) Various formatting erros in L10N property files
[ https://issues.apache.org/jira/browse/DERBY-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dyre Tjeldvoll updated DERBY-3366: -- Attachment: trunk.status mess.sql Attaching Rick's excellent table function script for finding such errors (thanks Rick!), and the result from running it on trunk. Various formatting erros in L10N property files --- Key: DERBY-3366 URL: https://issues.apache.org/jira/browse/DERBY-3366 Project: Derby Issue Type: Bug Components: Localization Affects Versions: 10.3.2.1 Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.4.0.0 Attachments: mess.sql, trunk.status Original Estimate: 72h Remaining Estimate: 72h There are a number of formatting errors in the localization property files: - DRDA_InvalidValue.U appears twice in the drda property files (english and translations) - Spurious linefeed for XCL21.S in messages_zh_TW.properties - Quadruple single quote rather than double single quote for contraction apostrophes in messages_it.properties -- 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=12564101#action_12564101 ] Daniel John Debrunner commented on DERBY-3137: -- SYS- (with the hyphen) means the reserved system roles would be delimited identifiers, would it not be simpler to have ones that can be described using regular identifiers? 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] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564102#action_12564102
]
A B commented on DERBY-3355:
Hi Bryan,
I reviewed at the patch and it looks good to me. The new test cases fail
without the change and pass with it, as expected.
Two very minor things that occurred to me while reading the patch:
1. Might be nice (though not by any means necessary) to include a comment in
AlterTableConstantAction
that explicitly mentions the motivation for double-quoting the column
name. On the other hand, maybe
the presence of the double quotes is itself enough to make that clear?
Not a big deal either way.
2. I instinctively found myself wondering if column names which had double
quotes in them would work
correctly. I ran some tests and the answer is Yes, they do work
correctly. Do you think it might be useful
to add a few test cases for that, just for completeness? The quick tests
that I ran were simply:
ij create table t1 (c2 int, C3 int);
0 rows inserted/updated/deleted
ij select * from t1;
c2 |C3
---
0 rows selected
ij alter table t1 alter column c2 not null;
0 rows inserted/updated/deleted
ij insert into t1 values (null, 2);
ERROR 23502: Column 'c2' cannot accept a NULL value.
ij alter table t1 alter column C3 not null;
0 rows inserted/updated/deleted
ij insert into t1 values (1, null);
ERROR 23502: Column 'C3' cannot accept a NULL value.
ij alter table t1 alter column c3 not null;
ERROR 42X14: 'c3' is not a column in table or VTI 'T1'.
ij alter table t1 alter column c3 not null;
ERROR 42X14: 'c3' is not a column in table or VTI 'T1'.
ij alter table t1 alter column c2 not null;
ERROR 42X14: 'c2' is not a column in table or VTI 'T1'.
ij alter table t1 alter column C3 not null;
ERROR 42X14: 'C3' is not a column in table or VTI 'T1'.
Neither of these nits should block the patch, though. As the regression tests
ran cleanly and I can see no other problems with the changes, I'm +1 to commit.
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to
[jira] Commented: (DERBY-3325) Add 'maxStatements' property to ClientConnectionPoolDataSource
[ https://issues.apache.org/jira/browse/DERBY-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564106#action_12564106 ] Myrna van Lunteren commented on DERBY-3325: --- Regarding rewriting the test - I think if the rewrite makes the test easier to understand, and still tests the same, it's fine. At a superficial glance your rewrite accomplishes those two things. 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: DataSourceReferenceTest.diff, DataSourceReferenceTest.java, 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-3083) Network server demands a file called derbynet.jar in classpath
[ https://issues.apache.org/jira/browse/DERBY-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-3083: -- Derby Info: [Regression] (was: [Patch Available, Regression]) I'm removing patch available flag; it appears from the discussions the patch wasn't fully approved. Network server demands a file called derbynet.jar in classpath Key: DERBY-3083 URL: https://issues.apache.org/jira/browse/DERBY-3083 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.3.1.4 Reporter: Aaron Digulla Attachments: derby-3083-01-requireDerbynet-aa.diff, derby-3083-01-requireDerbynet-ab.diff, derby-716-10-datatypesCollation-aa.diff The network server will not start if the derbynet jar is added under a different name than derbynet.jar to the classpath. This makes it impossible to use it in maven projects where the jar is renamed to derbynet-10.3.1.4.jar. This did work with 10.2.2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby
[ https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren updated DERBY-3117: -- Derby Info: (was: [Patch Available]) Adjust master build script to require the Java 5 compiler to build Derby Key: DERBY-3117 URL: https://issues.apache.org/jira/browse/DERBY-3117 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.4.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: BuildDefaults.txt, d3117-solaris.diff, derby-3117-01-enforceJava5-aa.diff, derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, derby-3117-02-website-aa.diff, derby-3117-03-junit-aa.diff, derby-3117-04-propertySetter-aa.diff, derby-3117-04-propertySetter-ab.diff, derby-3117-04-propertySetter-ac.diff, derby-3117-04-propertySetter-ad.diff, derby-3117-04-propertySetter-ae.diff, derby-3117-04-propertySetter-af.diff, derby-3117-04-propertySetter-ag.diff, derby-3117-04-propertySetter-ah.diff, derby-3117-05-setterCleanup-aa.diff, derby-3117-06-setterDefault-aa.diff, derby-3117-07-buildInstructions-aa.diff, derby-3117-08a-j15libBuildingInstr.diff, derby_source.html Require the Java 5 compiler in order to build Derby as approved by the community recently: http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564114#action_12564114
]
Daniel John Debrunner commented on DERBY-3355:
--
I'm not sure those quote examples prove anything, not a single one is executed
after the table has rows in it, which is where the bug originally was.
My guess is that is does not work. The column name in the alter table is
c2, which will be converted to c2 internally (as a Java string),
then the SELECT to check the constraint will use c2 which will cause a
syntax error.
When writing an identifier as an input for a SQL statement as well as making it
delimited value needs to have its double quotes escaped (by using two double
quotes). Either no Derby code does this or there is a utility somewhere to
output the CNF of an identifier in a form acceptable to a SQL statement.
Good thinking to raise the issue though.
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to upper case, and gets the no-such-column error.
Can you open a problem report in Jira so that we can track this down
and get it fixed?
http://db.apache.org/derby/DerbyBugGuidelines.html
thanks,
bryan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564117#action_12564117 ] Daniel John Debrunner commented on DERBY-3213: -- Did you run any tests with this patch? Derby generates Java byte code to execute SQL statements and therefore the only path to some methods is through the generated code. Thus Derby might build successfully but fail at runtime. SQLChar.trim method is unused and could be removed -- Key: DERBY-3213 URL: https://issues.apache.org/jira/browse/DERBY-3213 Project: Derby Issue Type: Improvement Components: Newcomer, SQL Reporter: Bryan Pendleton Assignee: Deepthi Devaki A R Priority: Minor Attachments: DERBY-3213.diff As part of researching DERBY-2352, I came to the conclusion that the trim() method in SQLChar.java is no longer used, and could be removed. It appears that all calls to this method have been switched to call ansiTrim() instead. Hopefully, this just requires removing the code from SQLChar.java and StringDataValue.java, and running all the tests to verify that nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3203) Convert jdbcapi/statementJdbc20.java to JUnit
[ https://issues.apache.org/jira/browse/DERBY-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564118#action_12564118 ] Bryan Pendleton commented on DERBY-3203: Committed the two deletes to the trunk as revision 616834. Convert jdbcapi/statementJdbc20.java to JUnit - Key: DERBY-3203 URL: https://issues.apache.org/jira/browse/DERBY-3203 Project: Derby Issue Type: Test Components: Test Reporter: Ramin Moazeni Assignee: Ramin Moazeni Fix For: 10.4.0.0 Attachments: DERBY-3203v0.diff, DERBY-3203v0.stat, DERBY-3203v2.diff, DERBY-3203v3.diff This issue is creates for converting jdbcapi/statementJdbc20.java to JUnit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3362) ControlRow NPE
[ https://issues.apache.org/jira/browse/DERBY-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3362: -- if possible could you post the whole derby.log. I am trying to figure out what in the transaction may be causing the null pointer. Kinds of things I am looking for is huge numbers of deletes in the transaction, ddl in the transaction like alter table, compress table, drop/create index. All of these are of course supposed to be supported but just trying to guess at how to reproduce this. Maybe you could try with JIT disabled to try and get a line number for the Nullpointer? of course if you could post a standalone repro that would be most help. ControlRow NPE -- Key: DERBY-3362 URL: https://issues.apache.org/jira/browse/DERBY-3362 Project: Derby Issue Type: Bug Affects Versions: 10.3.2.1 Reporter: James Alan Shepherd I have a NPE in Derby 10.3.2.1 (10.3.1.4 does not show this behaviour) that is probably the same one discussed in DERBY-3216 FATAL 38406 [Main] (Start.java:153) - Start FAILED org.springframework.transaction.TransactionSystemException: Could not commit JDBC transaction; nested exception is java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199) at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146) at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324) at com.aaa.eee.fff.ggg.reload(ggg.java:44) at com.aaa.eee.fff.ggg.startup(ggg.java:57) at com.aaa.eee.fff.Start.startupEee(Start.java:170) at com.aaa.eee.fff.Start.startup(Start.java:146) at com.aaa.start.Starter.startup(Starter.java:264) at com.aaa.start.Main.startup(Main.java:270) at com.aaa.start.Main.main(Main.java:199) Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 21 more Caused by: java.lang.NullPointerException at org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown Source) ... 15 more and derby.log: 2008-01-28 08:26:36.148 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2),
[jira] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564119#action_12564119
]
A B commented on DERBY-3355:
I'm not sure those quote examples prove anything, not a single one is
executed after the table has rows in it
Good catch! Sorry for missing that. Building on the example I mentioned above:
ij insert into t1 values (1, 2);
1 row inserted/updated/deleted
ij alter table t1 alter column C3 null;
0 rows inserted/updated/deleted
ij alter table t1 alter column C3 not null;
ERROR 42X01: Syntax error: Encountered \ at line 1, column 43.
So it looks like you're right, the quotes will lead to a syntax error. Though
the specific error in this case seems a tad odd...where'd the slash (\) come
from?
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to upper case, and gets the no-such-column error.
Can you open a problem report in Jira so that we can track this down
and get it fixed?
http://db.apache.org/derby/DerbyBugGuidelines.html
thanks,
bryan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Pendleton updated DERBY-3355:
---
Derby Info: (was: [Patch Available])
Thanks Dan and Army for the suggestions and fiendishly good tests!
I cleared the patch available flag; I've got more work to do here.
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to upper case, and gets the no-such-column error.
Can you open a problem report in Jira so that we can track this down
and get it fixed?
http://db.apache.org/derby/DerbyBugGuidelines.html
thanks,
bryan
--
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=12564133#action_12564133 ] Daniel John Debrunner commented on DERBY-3137: -- I'm still struggling with the SQL Standard here for SET ROLE (and identifiers in general): 3a) Let S be value specification and let V be the character string that is the value of TRIM ( BOTH ' ' FROM S ) 3b) If V does not conform to the Format and Syntax Rules of a role name, then an exception condition is raised: invalid role specification. DERBY-2109 discussion implied that this means the format of V needs to be that of a SQL identifier (regular or delimited). Now CURRENT_ROLE is a valid value specification, does this mean CURRENT_ROLE needs to return the role name as SQL identifier, instead of the CNF of the role name? The spec says value of the current role. I'm not convinced that the conclusion in DERBY-2109 is correct, seems more logical to me that V here should be the CNF of the role name. Section 5.2 SR 24) says the CNF of a regular identifier is used in the system catalogs, thus if CURRENT_ROLE is to be used in queries against the catalogs it has to return the CNF of the role name. Which then contradicts SET ROLE and value specification. I can't see any explicit statement about what the value of the current role means, or the more general value of an identifier. 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] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564140#action_12564140
]
Daniel John Debrunner commented on DERBY-3355:
--
or in the spirit of open source and incremental development commit the patch
and address the quote issues in a follow up patch.
The current patch improves the situation and makes most cases work.
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to upper case, and gets the no-such-column error.
Can you open a problem report in Jira so that we can track this down
and get it fixed?
http://db.apache.org/derby/DerbyBugGuidelines.html
thanks,
bryan
--
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-3346) DatabaseMetaData.getIndexInfo returns the wrong nullabilty for column 4 NON_UNIQUE
[ https://issues.apache.org/jira/browse/DERBY-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564148#action_12564148 ] djd edited comment on DERBY-3346 at 1/30/08 11:40 AM: Fixed by Revision: 616853 for DERBY-2775 was (Author: djd): Fixed by Revision: 616853 for DERBY-2275 DatabaseMetaData.getIndexInfo returns the wrong nullabilty for column 4 NON_UNIQUE -- Key: DERBY-3346 URL: https://issues.apache.org/jira/browse/DERBY-3346 Project: Derby Issue Type: Bug Components: JDBC, SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner Priority: Minor Fix For: 10.4.0.0 Derby's implementation of the NON_UNIQUE column for getIndexInfo() resolves to this expression: (CASE WHEN CONGLOMS.DESCRIPTOR.isUnique() THEN FALSE ELSE TRUE END) AS NON_UNIQUE The possible return values for this are TRUE or FALSE (this is internal SQL), which are both non-null constants, thus its type should be not nullable. A similar external SQL expression by itself does return the correct nullability, thus it seems to be a possible case where one node's nullability is affecting another. See DERBY-2775 and DERBY-3342. This like DERBY-3342 was found while fixing DERBY-2775. Working SQL with correct nullability: VALUES CASE WHEN 3=? THEN 1 ELSE 2 END -- 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-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=12564149#action_12564149 ] djd edited comment on DERBY-3342 at 1/30/08 11:39 AM: Fixed by Revision: 616853 for DERBY-2775 was (Author: djd): Fixed by Revision: 616853 for DERBY-2275 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 Assignee: Daniel John Debrunner Priority: Minor Fix For: 10.4.0.0 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] 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-extra.sql derby-3301-5.diff Very sorry for the derbyall hickup :| Attaching - updated patch 'derby-3301-5.diff' which uses a CollectNodesVisitor to find all lower SubqueryNodes as pointed out by Army. - extra sql script in 'derby-3301-extra.sql' containig Craigs additional queries modified to work with the original repro script schema sql'. With the 5 patch applied both the original query and the additional queries Craig posted return as expected. See output below. I still need to - have another look at Armys latest variant, as it doesn't seem to end up with a similar querytree to the others (i.e no SubqueryNodes in the WHERE clause). - modify the master output for lang/subqueryFlattening.sql. ij 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 --- Craigs additional queries: ij SELECT UNBOUND_E.empid FROM DEPARTMENTS THIS , employees UNBOUND_E WHERE EXISTS ( SELECT 1 FROM employees THIS_EMPLOYEES_E WHERE THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_E.empid = THIS_EMPLOYEES_E.empid AND THIS.ID = 2); EMPID --- 14 15 2 rows selected ij SELECT THIS.ID,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 UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_E.empid = THIS_EMPLOYEES_E.empid )); ID |EMPID |PROJID --- 1 |11 |101 1 |12 |101 1 |13 |101 1 |12 |102 1 |13 |102 2 |14 |103 2 |15 |103 7 rows selected ij 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 UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_E.empid = THIS_EMPLOYEES_E.empid AND THIS.ID = 1)); EMPID |PROJID --- 11 |101 12 |101 13 |101 12 |102 13 |102 5 rows selected ij 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 UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID AND UNBOUND_E.empid = THIS_EMPLOYEES_E.empid AND THIS.COMPANYID = 1)); EMPID |PROJID --- 11 |101 12 |101 13 |101 12 |102 13 |102 14 |103 15 |103 7 rows selected ij 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 Assignee: Thomas Nielsen Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff,
[jira] Closed: (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:all-tabpanel ] Daniel John Debrunner closed DERBY-3342. Resolution: Fixed Fix Version/s: 10.4.0.0 Fixed by Revision: 616853 for DERBY-2275 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 Assignee: Daniel John Debrunner Priority: Minor Fix For: 10.4.0.0 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] Closed: (DERBY-3346) DatabaseMetaData.getIndexInfo returns the wrong nullabilty for column 4 NON_UNIQUE
[ https://issues.apache.org/jira/browse/DERBY-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel John Debrunner closed DERBY-3346. Resolution: Fixed Fix Version/s: 10.4.0.0 Fixed by Revision: 616853 for DERBY-2275 DatabaseMetaData.getIndexInfo returns the wrong nullabilty for column 4 NON_UNIQUE -- Key: DERBY-3346 URL: https://issues.apache.org/jira/browse/DERBY-3346 Project: Derby Issue Type: Bug Components: JDBC, SQL Affects Versions: 10.4.0.0 Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner Priority: Minor Fix For: 10.4.0.0 Derby's implementation of the NON_UNIQUE column for getIndexInfo() resolves to this expression: (CASE WHEN CONGLOMS.DESCRIPTOR.isUnique() THEN FALSE ELSE TRUE END) AS NON_UNIQUE The possible return values for this are TRUE or FALSE (this is internal SQL), which are both non-null constants, thus its type should be not nullable. A similar external SQL expression by itself does return the correct nullability, thus it seems to be a possible case where one node's nullability is affecting another. See DERBY-2775 and DERBY-3342. This like DERBY-3342 was found while fixing DERBY-2775. Working SQL with correct nullability: VALUES CASE WHEN 3=? THEN 1 ELSE 2 END -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3349) Nested WHERE EXISTS queries need improved testing
[ https://issues.apache.org/jira/browse/DERBY-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564159#action_12564159 ] Thomas Nielsen commented on DERBY-3349: --- There are 4 more variations of problematic queries in the 'derby-3301-extra.sql' script attached to DERBY-3301. Nested WHERE EXISTS queries need improved testing - Key: DERBY-3349 URL: https://issues.apache.org/jira/browse/DERBY-3349 Project: Derby Issue Type: Improvement Components: Test Reporter: Thomas Nielsen DERBY-3301 reported an error in subquery flattening of nested WHERE EXISTS clauses, or WHERE EXISTS subqueries. The query returned the wrong number of rows. There is currently some tests for WHERE EXISTS, but none for nested WHERE EXISTS clauses. See DERBY-3301 for a full sql 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-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
[ https://issues.apache.org/jira/browse/DERBY-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Thalamati updated DERBY-3367: Attachment: derby.log Derby log with the query plans. Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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-test-master.stat derby-3301-test-master.diff Attaching updated master file for lang/subqueryFlattening. Diffs only in qyeryplans, so the changes in patch 5 produce identical results for the tested queries. When run standalone the updated lang/subqueryFlattening test pass. 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 Assignee: Thomas Nielsen Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master.diff, derby-3301-test-master.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 INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE
[jira] Updated: (DERBY-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.
[
https://issues.apache.org/jira/browse/DERBY-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-3279:
---
Attachment: d3279_ix2brnode_v1.patch
Attaching a follow-up patch, d3279_ix2brnode_v1.patch, that fixes the case for
IndexToBaseRowNodes which appear above the base table. I didn't see any other
cases where similar changes were necessary (or rather, all other cases were
handled by the _v1 patch).
This patch also adds some more test cases to InListMultiProbeTest, esp. to 1)
test the case where the index has fewer columns than the base table, and 2)
test queries that have multiple IN lists in them. I decided to add the latter
set of tests since Bryan asked about a similar query in an earlier comment, and
since cheese2.sql also includes a couple of queries with multiple IN lists in
the where clause (indirectly).
I ran derbyall and suites.All with ibm142 and saw no failures.
Derby 10.3.X ignores ORDER BY DESC when target column has an index and is
used in an OR clause or an IN list.
-
Key: DERBY-3279
URL: https://issues.apache.org/jira/browse/DERBY-3279
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2),
J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
Fix For: 10.4.0.0
Attachments: cheese2.sql, d3279_ix2brnode_v1.patch, d3279_v1.patch
Running the following produces the error seen in Derby 10.3.X but not in
10.2.X nor in 10.1.X.
Don't know if this related to DERBY-3231.
First query is incorrectly sorted whereas the second one is okay when there
is an index on the table.
If the table is not indexed, the sort works correctly in DESC order.
--
create table CHEESE (
CHEESE_CODE VARCHAR(5),
CHEESE_NAME VARCHAR(20),
CHEESE_COST DECIMAL(7,4)
);
create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC,
CHEESE_COST DESC);
INSERT INTO CHEESE (
CHEESE_CODE,
CHEESE_NAME,
CHEESE_COST)
VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
SELECT * FROM CHEESE
WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
SELECT * FROM CHEESE
WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3279) Derby 10.3.X ignores ORDER BY DESC when target column has an index and is used in an OR clause or an IN list.
[
https://issues.apache.org/jira/browse/DERBY-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-3279:
---
Derby Info: [Patch Available, Regression] (was: [Regression])
Derby 10.3.X ignores ORDER BY DESC when target column has an index and is
used in an OR clause or an IN list.
-
Key: DERBY-3279
URL: https://issues.apache.org/jira/browse/DERBY-3279
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1
Environment: Rational Application Developer 7.0.0.2 (Eclipse 3.2.2),
J2RE 1.5.0 IBM J9 2.3 Windows XP
Reporter: Ajay Bhala
Assignee: A B
Fix For: 10.4.0.0
Attachments: cheese2.sql, d3279_ix2brnode_v1.patch, d3279_v1.patch
Running the following produces the error seen in Derby 10.3.X but not in
10.2.X nor in 10.1.X.
Don't know if this related to DERBY-3231.
First query is incorrectly sorted whereas the second one is okay when there
is an index on the table.
If the table is not indexed, the sort works correctly in DESC order.
--
create table CHEESE (
CHEESE_CODE VARCHAR(5),
CHEESE_NAME VARCHAR(20),
CHEESE_COST DECIMAL(7,4)
);
create index cheese_index on CHEESE (CHEESE_CODE DESC, CHEESE_NAME DESC,
CHEESE_COST DESC);
INSERT INTO CHEESE (
CHEESE_CODE,
CHEESE_NAME,
CHEESE_COST)
VALUES ('0', 'GOUDA', 001.1234),
('0', 'EDAM', 002.),
('54321', 'EDAM', 008.5646),
('12345', 'GORGONZOLA', 888.2309),
('A', 'EDAM', 999.),
('54321', 'MUENSTER', 077.9545);
SELECT * FROM CHEESE
WHERE (CHEESE_CODE='0' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
SELECT * FROM CHEESE
WHERE (CHEESE_CODE='A' OR CHEESE_CODE='54321') AND CHEESE_NAME='EDAM'
ORDER BY CHEESE_CODE DESC, CHEESE_NAME DESC, CHEESE_COST DESC;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3243) (jdbc net client) exception during normal iteration through ResultSet of select * from t
[
https://issues.apache.org/jira/browse/DERBY-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564181#action_12564181
]
Kathey Marsden commented on DERBY-3243:
---
Oystein asked:
However, It would be even better if
one where able to communicate the type of each value dynamically, but
I were not able to determine how to do this with DRDA. Does anybody
know?
I think that the sqlType that we send with the SQLDAGRP should be set to one of
the following when we send by locator.
public static final int DB2_SQLTYPE_BLOB_LOCATOR = 960;// BLOB locator
public static final int DB2_SQLTYPE_NBLOB_LOCATOR = 961;
public static final int DB2_SQLTYPE_CLOB_LOCATOR = 964;// CLOB
locator
public static final int DB2_SQLTYPE_NCLOB_LOCATOR = 965;
Right now we always send one of these whether it is by locator or value.
public static final int DB2_SQLTYPE_BLOB = 404;// BLOB
public static final int DB2_SQLTYPE_NBLOB = 405;
public static final int DB2_SQLTYPE_CLOB = 408;// CLOB
public static final int DB2_SQLTYPE_NCLOB = 409;
If we send the specific SQL Type then the client should be able to branch its
logic based on that. There are issues of backward compatibility which would
have to be dealt with, but it seems a better way for the client to figure out
whether it is dealing with a locator or a value.
(jdbc net client) exception during normal iteration through ResultSet of
select * from t
Key: DERBY-3243
URL: https://issues.apache.org/jira/browse/DERBY-3243
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.2.1
Environment: -- Java Information --
Java Version:1.4.2_03
Java Vendor: Sun Microsystems Inc.
Java home: C:\Programme\Java\j2re1.4.2_03
Java classpath: derbyclient.jar
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: cbdqok
Java user home: C:\Dokumente und Einstellungen\cbdqok
Java user dir: D:\users\cbdqok\privat\osj\lib_derby_net\lib
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
- Derby Information
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[D:\users\cbdqok\privat\osj\lib_derby_net\lib\derbyclient.jar] 10.3.1.4 -
(561794)
--
- Locale Information -
--
Reporter: Oliver Seidel
Priority: Critical
Attachments: derby-3243_fix_double_hashmap_entry_diff.txt,
derby-3243_fix_double_hashmap_entry_diff2.txt,
derby-3243_fix_double_hashmap_entry_stat.txt
Thanks again to the DERBY developers.
For my convenience I use the client/server variant of DERBY. This is where
the error occurs. I have temporarily alleviated the problem for my case by
using the embedded version.
I'm forced to use outlook and have built a program which siphons the messages
into a derby database (phase 1 -- table has two varchar fields and a clob).
When reading them back (phase 2 -- simple select of all records in no
particular order, all 3 attributes), it has developed an exception. This is
a result of data volume. I have reduced the problem to a single
demonstration program.
This behaviour, and the fact that the error is not a DERBY Exception, but a
proper exception coming back from the JDBC call, leads me to the diagnosis
that it is a derby network client jdbc problem.
The problem has been reproduced once by Bryan Pendleton:
http://www.nabble.com/IndexOutOfBoundsException-t4926228.html
I'll try to attach the code error.java; it can also be found on:
http://www.os1.net/error.java
Please use as follows:
javac -classpath derby.jar:derbynet.jar error.java
java -cp .:derby.jar:derbynet.jar error
It will create a directory test_db and fill it with approx 120mb data.
Then you will observe the failure.
/* -*- Mode:Java; c-basic-offset:8 -*- */
//
public class error {
//
public static final int port = 1527;
public static final String host = 127.0.0.1;
//
public static void log(String x) { System.out.println(x); };
//
public static void log_stacktrace(Exception e) {
java.io.StringWriter sw = new java.io.StringWriter();
[jira] Updated: (DERBY-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
[ https://issues.apache.org/jira/browse/DERBY-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-3367: -- Are you looking for Derby to optimize time to first row returned? Does your app really only want the first row? Doing this kind of costing would be interesting but not sure how we would decide which is better. Maybe the row_number project will get into costing associated with only needing to produce a subset of the rows of the query. Derby definitely currently tries to cost out getting all the rows, not just the first one. For these kinds of reports it would be interesting to report total time of the 2 different plans while getting all the rows. I would also not be surprised if current costing should be updated to reflect current software costs of the plans, we have not updated the base costs for many years now. It is surprising that the one without the qualifier goes through the index. I would have thought that would be the worst case cost for the index probes. I think Derby will only consider a full index scan for this query with != -1 added as a qualifier - though logically it could be done as 2 index scans (ie. -1 and then -1). Even so the cost of going through all the rows and the cost of going through all the rows and applying != -1 to the index key seems like it should be about the same. I would have guessed that both might not use the index if costing for the sort came out smaller than Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3367) Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate.
[ https://issues.apache.org/jira/browse/DERBY-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564205#action_12564205 ] Suresh Thalamati commented on DERBY-3367: - Thanks for your comments, Mike. I am not looking for Derby to optimize time to return the first row, The application needs all the rows , returned by the query. But it process the rows as it gets and shows results iteratively to the user. Because of sorting, it takes time to get the first row also , which makes it look as of the application is hung. My observation was, even in IJ , selecting all the rows without the != -1 qualifier was faster than with the qualifier. I was also surprised it used index without the qualifier., but not with the qualifier. It turns out to be good decision by the optimizer , if the sorting is external and spilling to disk, when data size is large. Sort is not avoided even when the has an index on a the column being ordered, for a query with id != -1 predicate. --- Key: DERBY-3367 URL: https://issues.apache.org/jira/browse/DERBY-3367 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.3.2.1 Reporter: Suresh Thalamati Attachments: derby.log Sort is not avoided even when the has an index on a the column being ordered, Repro: go.ddl: --- connect 'jdbc:derby:testdb;create=true'; create table t1 (i int, j int, vc varchar(30)); insert into t1 values (1, -1, 'minus one'); insert into t1 values (2, 2, 'two'), (3, 3, 'trois'), (3, -3, 'minus three'), (4, 4, 'four'); insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; insert into t1 select * from t1 where j 0; create index ix on t1 (j); disconnect all; exit; go.sql: --- connect 'jdbc:derby:testdb'; get cursor c1 as 'select j, vc from t1 order by j asc'; next c1; close c1; get cursor c1 as 'select j, vc from t1 where j != -1 order by j asc'; next c1; close c1; -- After running go.sql, if you look at the derby.log file you'll see that the query with no predicate does an index scan and only has to read 1 row from disk before the cursor is closed. But the query _with_ a predicate does a table scan an has to read 3074 rows from disk, and sort them, just to return the first one in the result set. In the repro, it looks fast. But If the data is large, which was the case in my application. The table was: create table t2 (i int, j int, vc varchar(15000)); and loaded with 13000 rows. It takes almost minute to get the first row , for the query select j, vc from t1 where j != -1 order by j asc' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3365) Network Server stores a dupliacate entry in the lob hash map for every lob
[ https://issues.apache.org/jira/browse/DERBY-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3365: -- Attachment: derby-3365_stat.txt derby-3365_diff.txt Attached is a follow-up patch derby-3365_diff.txt incorporating review comments from my patch attached to DERBY-3243 (derby-3243_fix_double_hashmap_entry_diff.txt) I'm sorry Knut I missed your original post about the patch. Hopefully all the changes are in this time. For this revision I fixed the typos and changed the lob create stored procedures to use getLocator(). I did not move the addlobLocator call to getLocator() because it would cause a regression for the DERBY-2787 fix. I will leave any optimization in this area to the DERBY-3354 fix. Network Server stores a dupliacate entry in the lob hash map for every lob -- Key: DERBY-3365 URL: https://issues.apache.org/jira/browse/DERBY-3365 Project: Derby Issue Type: Bug Components: Network Server Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-3365_diff.txt, derby-3365_stat.txt Per discussion in DERBY-3243, Network Server stores a duplicate entry in the lob hashmap for every lob. I posted a preliminary patch to DERBY-3243 and received comments on the patch in that issue, but it makes more sense to separate the issue out from DERBY-3243. So opening up this new 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-3365) Network Server stores a duplicate entry in the lob hash map for every lob
[ https://issues.apache.org/jira/browse/DERBY-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3365: -- Summary: Network Server stores a duplicate entry in the lob hash map for every lob (was: Network Server stores a dupliacate entry in the lob hash map for every lob) Network Server stores a duplicate entry in the lob hash map for every lob - Key: DERBY-3365 URL: https://issues.apache.org/jira/browse/DERBY-3365 Project: Derby Issue Type: Bug Components: Network Server Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-3365_diff.txt, derby-3365_stat.txt Per discussion in DERBY-3243, Network Server stores a duplicate entry in the lob hashmap for every lob. I posted a preliminary patch to DERBY-3243 and received comments on the patch in that issue, but it makes more sense to separate the issue out from DERBY-3243. So opening up this new issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3362) ControlRow NPE
[ https://issues.apache.org/jira/browse/DERBY-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564216#action_12564216 ] James Alan Shepherd commented on DERBY-3362: Can't publish the derby log I'm afraid. Only a few deletes in the transaction, it's a data import script. Almost all of the deletes are in stored procs/ triggers that will delete no rows. No ddl/indexes changed. I tried -Djava.compiler=NONE but I still didn't get any line numbers. Is there another/better way to disable JIT? I tried the 32bit HotSpot instead of 64bit same thing happened. Increasing the heap doesn't seem to make any difference. Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) I'll try to test on a 1.5 JVM later in the week, just in case. ControlRow NPE -- Key: DERBY-3362 URL: https://issues.apache.org/jira/browse/DERBY-3362 Project: Derby Issue Type: Bug Affects Versions: 10.3.2.1 Reporter: James Alan Shepherd I have a NPE in Derby 10.3.2.1 (10.3.1.4 does not show this behaviour) that is probably the same one discussed in DERBY-3216 FATAL 38406 [Main] (Start.java:153) - Start FAILED org.springframework.transaction.TransactionSystemException: Could not commit JDBC transaction; nested exception is java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199) at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146) at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324) at com.aaa.eee.fff.ggg.reload(ggg.java:44) at com.aaa.eee.fff.ggg.startup(ggg.java:57) at com.aaa.eee.fff.Start.startupEee(Start.java:170) at com.aaa.eee.fff.Start.startup(Start.java:146) at com.aaa.start.Starter.startup(Starter.java:264) at com.aaa.start.Main.startup(Main.java:270) at com.aaa.start.Main.main(Main.java:199) Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 21 more Caused by: java.lang.NullPointerException at org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown Source) at
[jira] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564223#action_12564223
]
Bryan Pendleton commented on DERBY-3355:
I tried running dblook against a database with Army's fiendish T1 table in it,
and dblook politely produced:
-- --
-- DDL Statements for tables
-- --
CREATE TABLE APP.T1 (c2 INTEGER, C3 INTEGER);
So it seems that somewhere within the Derby source tree there is some code that
understands how to take table and column names and properly enquote them.
Hopefully I can track that code down, and have a look to see if it can be easily
repurposed for use by the ALTER TABLE execution.
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to upper case, and gets the no-such-column error.
Can you open a problem report in Jira so that we can track this down
and get it fixed?
http://db.apache.org/derby/DerbyBugGuidelines.html
thanks,
bryan
--
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=12564224#action_12564224
]
A B commented on DERBY-3301:
I still need to have another look at Armys latest variant, as it doesn't seem
to end
up with a similar querytree to the others
Actually, I think the query does fit the general shape. In your v5 patch you
iterate through each of
the SubqueryNode's that are found by CollectNodesVisitor and check to see if
any of them was
marked as a whereSubquery(). For some reason that check fails in the query
that I posted--i.e.
the one where I include the 1 = 1 predicate. While I don't know why the call
to whereSubquery()
returns false, I also don't think that it's necessary at this particular point.
The code that calls CollectNodesVisitor is this line:
sn.originalWhereClause.accept(cnv);
Since we're visiting the original WHERE clause, any SubqueryNodes that we find
are necessarily
going to be WHERE subqueries because we found them in a WHERE clause. So it
seems like
we shouldn't have to call isWhereSubquery() on any of them--we just need to
check to see if the
CollectNodesVisitor found at least one, and if so, we're done. I changed your
version 5 patch to
look like this:
if (sn.originalWhereClause != null)
{
/* Second instance of SubqueryNode.class effectively means
don't bother
* searching beneath SubqueryNodes since if we found one,
we're done.
*/
CollectNodesVisitor cnv =
new CollectNodesVisitor(
SubqueryNode.class, SubqueryNode.class);
sn.originalWhereClause.accept(cnv);
return cnv.getList().isEmpty();
}
and with that change (everything else the same), the query with 1 = 1 returns
7 rows, as it should. The
other queries mentioned by Craig also return the correct results (assuming the
first one is supposed to
return 2 rows, which I assume it is...?)
So it looks like the use of CollectNodesVisitor does help. As for the issue of
why the SubqueryNode's
found in originalWhereClause return false for isWhereSubquery(), I haven't
looked at that.
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
Assignee: Thomas Nielsen
Attachments: d3301-queryplan.log, derby-3301-1.diff,
derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff,
derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat,
derby-3301-4c.diff, derby-3301-5.diff, derby-3301-extra.sql,
derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff,
derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master.diff,
derby-3301-test-master.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,
[jira] Commented: (DERBY-3355) Alter Column ... NULL ignores double quotes around column name
[
https://issues.apache.org/jira/browse/DERBY-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564226#action_12564226
]
Daniel John Debrunner commented on DERBY-3355:
--
Within the engine I think this will work:
org.apache.derby.iapi.util.IdUtil.normalToDelimited
Alter Column ... NULL ignores double quotes around column name
--
Key: DERBY-3355
URL: https://issues.apache.org/jira/browse/DERBY-3355
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.1.4
Environment: mac 0s x
Reporter: geoff hendrey
Assignee: Bryan Pendleton
Attachments: patch.diff
' is not a column in the target table., SQL State: 42X04, Error Code: -1
Hi:
I think I have isolated a bug involving the use of double quotes to define a
column name. Here s the SQL to reproduce the bug, followed by the error
message generated by the final SQL statement. In order to make the bug go
away, eliminate all use of double quotes in the SQL statements below. Note
that the identical alter statement succeeds before the insert, and fail
after. I have spent a long time trying to isolate this problem, so please
take a look.
CREATE TABLE Table2
(
c VARCHAR(32672)
);
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
INSERT INTO Table2(c) VALUES('yo');
alter table Table2 ALTER COLUMN c NULL;
alter table Table2 ALTER COLUMN c NOT NULL;
Query 1 of 6 elapsed time (seconds) - Total: 0.012, SQL query: 0.012,
Building output: 0
Query 2 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Query 3 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
1 Row(s) Inserted
Query 4 of 6 elapsed time (seconds) - Total: 0.009, SQL query: 0.009,
Building output: 0
Query 5 of 6 elapsed time (seconds) - Total: 0.003, SQL query: 0.003,
Building output: 0
Error: java.sql.SQLException: Column 'C' is either not in any table in the
FROM list or appears within a join specification and is outside the scope of
the join specification or appears in a HAVING clause and is not in the GROUP
BY list. If this is a CREATE or ALTER TABLE statement then 'C' is not a
column in the target table., SQL State: 42X04, Error Code: -1
-Inline Message Follows-
Geoff hendrey wrote:
I think I have isolated a bug involving the use of double quotes to
define a column name.
Hi Geoff, I agree, that is definitely a bug. Your script reproduces
the problem for me, on the current Derby trunk.
It appears that AlterTableConstantAction.validateNotNullConstraint
is internally generating and executing a statement of the form:
select count(*) from tab where not (col is not null)
The code which generates this SQL staement is not properly enclosing
the column name in double quotes, as you noticed, so the compiler
converts the column name to upper case, and gets the no-such-column error.
Can you open a problem report in Jira so that we can track this down
and get it fixed?
http://db.apache.org/derby/DerbyBugGuidelines.html
thanks,
bryan
--
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=12564225#action_12564225 ] A B commented on DERBY-3301: On a complete unrelated note, I think the preference for Derby codeline is to keep lines shorter than 80 characters (where possible). Some of the lines in the latest patch look to exceed that. Not a big deal, but thought I'd mention it. 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 Assignee: Thomas Nielsen Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master.diff, derby-3301-test-master.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 INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY |STA|ZIPC|COUNTRY |HIREDATE |WEEKLYHOURS |DEPARTMENT
[jira] Commented: (DERBY-3362) ControlRow NPE
[ https://issues.apache.org/jira/browse/DERBY-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564236#action_12564236 ] Kathey Marsden commented on DERBY-3362: --- To get the line numbers you should run with a debug build. Download db-derby-10.3.2.1-lib-debug.zip from http://db.apache.org/derby/releases/release-10.3.2.1.cgi ControlRow NPE -- Key: DERBY-3362 URL: https://issues.apache.org/jira/browse/DERBY-3362 Project: Derby Issue Type: Bug Affects Versions: 10.3.2.1 Reporter: James Alan Shepherd I have a NPE in Derby 10.3.2.1 (10.3.1.4 does not show this behaviour) that is probably the same one discussed in DERBY-3216 FATAL 38406 [Main] (Start.java:153) - Start FAILED org.springframework.transaction.TransactionSystemException: Could not commit JDBC transaction; nested exception is java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:238) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:199) at org.springframework.jdbc.datasource.DataSourceTransactionManager.doCommit(DataSourceTransactionManager.java:245) at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:651) at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:621) at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:146) at com.aaa.bbb.cccFactory$ddd.add(cccFactory.java:324) at com.aaa.eee.fff.ggg.reload(ggg.java:44) at com.aaa.eee.fff.ggg.startup(ggg.java:57) at com.aaa.eee.fff.Start.startupEee(Start.java:170) at com.aaa.eee.fff.Start.startup(Start.java:146) at com.aaa.start.Starter.startup(Starter.java:264) at com.aaa.start.Main.startup(Main.java:270) at com.aaa.start.Main.main(Main.java:199) Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 21 more Caused by: java.lang.NullPointerException at org.apache.derby.impl.store.access.btree.ControlRow.getControlRowForPage(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.ControlRow.get(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.purgeRowLevelCommittedDeletes(Unknown Source) at org.apache.derby.impl.store.access.btree.BTreePostCommit.performWork(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.postTermination(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.completeCommit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.commit(Unknown Source) at org.apache.derby.impl.store.access.RAMTransaction.commit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCommit(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userCommit(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.commit(Unknown Source) ... 15 more and derby.log: 2008-01-28 08:26:36.148 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE = directory:myDB), (DRDAID = null), Executing prepared statement: SELECT COUNT(*) FROM ZZZ WHERE nID IS NULL :End prepared statement 2008-01-28 08:26:36.150 GMT Thread[Main,5,main] (XID = 1888), (SESSIONID = 2), (DATABASE = directory:myDB), (DRDAID = null), Committing 2008-01-28 08:26:36.188 GMT Thread[Main,5,main] (XID =
[jira] Created: (DERBY-3368) Threading issue with DependencyManager may cause in-memory dependencies to be lost.
Threading issue with DependencyManager may cause in-memory dependencies to be
lost.
---
Key: DERBY-3368
URL: https://issues.apache.org/jira/browse/DERBY-3368
Project: Derby
Issue Type: Bug
Components: Services
Reporter: Daniel John Debrunner
Priority: Minor
When a thread compiles a language prepared statement P a set of in-memory
Dependency objects is created, e.g. if P accesses table A
Dependency {P depends on A}
When this Dependency is added to the dependency manager if an equivalent one
(same provider and dependent) exists then the duplicate will not be added.
The StatementContext keeps track of these added Dependency so that if the
compilation fails the Dependency will be removed, comparing by the exact same
Dependency object (not by equivalence).
If a thread T1 compiling P fails, then another thread may try to compile P
(same object). If this second thread T2 compiles successfully the following
could happen:
1) T1 compiles P creates Dependency {P depends on A} in dependency manager
2) T1 fails to compile, but does not yet execute its cleanup
3) T2 compiles P successfully, attempts to add Dependency {P depends on A} to
the manager but it is a duplicate so T1's version is left and T2's is not added.
4) T1 completes its cleanup and removes Dependency {P depends on A}
5) P no longer depends on A
Concern is that the security system GRANT/REVOKE is based upon the dependency
manager as well as correctness for indexes (e.g. this could cause a recompile
to be missed for an INSERT table when an index is added).
For this to actually happen there has to be a situation where one thread
(connection) can compile a statement that another one fails on (and be
compiling at near identical times). I haven't got a reproducible case yet, but
I can get two statements to be compiling the same statement plan (P).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3368) Threading issue with DependencyManager may cause in-memory dependencies to be lost.
[
https://issues.apache.org/jira/browse/DERBY-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564240#action_12564240
]
Daniel John Debrunner commented on DERBY-3368:
--
As an aside one strange aspect is that if the Dependency is not added to the
manager due to an existing duplicate then it is still added to the list in the
StatementContext. This is pointless as the Dependency will not exist in the
manager and the purpose of the list in the statement context is to remove
dependencies on error.
Threading issue with DependencyManager may cause in-memory dependencies to be
lost.
---
Key: DERBY-3368
URL: https://issues.apache.org/jira/browse/DERBY-3368
Project: Derby
Issue Type: Bug
Components: Services
Reporter: Daniel John Debrunner
Priority: Minor
When a thread compiles a language prepared statement P a set of in-memory
Dependency objects is created, e.g. if P accesses table A
Dependency {P depends on A}
When this Dependency is added to the dependency manager if an equivalent one
(same provider and dependent) exists then the duplicate will not be added.
The StatementContext keeps track of these added Dependency so that if the
compilation fails the Dependency will be removed, comparing by the exact same
Dependency object (not by equivalence).
If a thread T1 compiling P fails, then another thread may try to compile P
(same object). If this second thread T2 compiles successfully the following
could happen:
1) T1 compiles P creates Dependency {P depends on A} in dependency manager
2) T1 fails to compile, but does not yet execute its cleanup
3) T2 compiles P successfully, attempts to add Dependency {P depends on A} to
the manager but it is a duplicate so T1's version is left and T2's is not
added.
4) T1 completes its cleanup and removes Dependency {P depends on A}
5) P no longer depends on A
Concern is that the security system GRANT/REVOKE is based upon the dependency
manager as well as correctness for indexes (e.g. this could cause a recompile
to be missed for an INSERT table when an index is added).
For this to actually happen there has to be a situation where one thread
(connection) can compile a statement that another one fails on (and be
compiling at near identical times). I haven't got a reproducible case yet,
but I can get two statements to be compiling the same statement plan (P).
--
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 ] Mike Matrigali updated DERBY-3330: -- At this point you should somehow document the implementation that you are planning to support the functional spec. That way I can comment on whether or not I think it should work. It is hard just going from your patch with almost no comments. I suggested the approach, and am having a hard time remembering at this point - imagine what other reviewers are going through. With regard to this specific question, it depends on what rows you are going to support in the new tree. To make it easier to talk about let's just consider the simplest case of a single key index. Then with respect to deleted rows will you ever support duplicate entries in the tree, as below: deleted bit key rowlocation --- --- --- false null1,7 false null1,8 truea 1,9 false a 1,10 I think the algorithms and edge cases are probably easier if you keep the rule that disregarding the deleted bit, there can never be a duplicate non-null key in the tree. This makes it easier to deal with uncommitted transactions and duplicates and deleted rows. If you pick this rule then you should read and understand the code in BTreeController that deals with this case in the old indexes. This code starts with the comment: // If the row is there already, simply undelete it. // The rationale for this is, since the index does // not support duplicates, the only way we could ... Remember that getting a lock on a deleted row does not mean it is a committed deleted row, it may have been deleted by the current transaction. Probably the most straightforward is to follow what we do currently for unique indexes, but apply it to this new index which allows duplicate null's but non duplicate non-null. I don't know the exact answer on locking, it is complicated as we have never locked rows to the right of a row during an insert before. This can have some negative concurrency aspects. 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-testcase.diff, derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff, FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html 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-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=12564256#action_12564256 ] Craig Russell commented on DERBY-3301: -- and with that change (everything else the same), the query with 1 = 1 returns 7 rows, as it should. The other queries mentioned by Craig also return the correct results (assuming the first one is supposed to return 2 rows, which I assume it is...?) Yes, it is supposed to return 2 rows. It's not a particularly interesting query since it works with or without the patch, but I included it because it also uses the EXISTS pattern. And let me say again I appreciate all the effort you all are putting into this. Craig 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 Assignee: Thomas Nielsen Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master.diff, derby-3301-test-master.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 INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE
[jira] Commented: (DERBY-3368) Threading issue with DependencyManager may cause in-memory dependencies to be lost.
[
https://issues.apache.org/jira/browse/DERBY-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564255#action_12564255
]
Daniel John Debrunner commented on DERBY-3368:
--
Another find is that CompileContextImpl also has code to clear the dependencies
on a language prepared statement when a compile fails, though it will not
always be executed due to the inconsistent popping pushing of compiler
contexts.
The role of clearing in-memory dependencies for a failed compile seems more
suited to the compiler context than the statement context, at least not both
should be trying to do it.
Threading issue with DependencyManager may cause in-memory dependencies to be
lost.
---
Key: DERBY-3368
URL: https://issues.apache.org/jira/browse/DERBY-3368
Project: Derby
Issue Type: Bug
Components: Services
Reporter: Daniel John Debrunner
Priority: Minor
When a thread compiles a language prepared statement P a set of in-memory
Dependency objects is created, e.g. if P accesses table A
Dependency {P depends on A}
When this Dependency is added to the dependency manager if an equivalent one
(same provider and dependent) exists then the duplicate will not be added.
The StatementContext keeps track of these added Dependency so that if the
compilation fails the Dependency will be removed, comparing by the exact same
Dependency object (not by equivalence).
If a thread T1 compiling P fails, then another thread may try to compile P
(same object). If this second thread T2 compiles successfully the following
could happen:
1) T1 compiles P creates Dependency {P depends on A} in dependency manager
2) T1 fails to compile, but does not yet execute its cleanup
3) T2 compiles P successfully, attempts to add Dependency {P depends on A} to
the manager but it is a duplicate so T1's version is left and T2's is not
added.
4) T1 completes its cleanup and removes Dependency {P depends on A}
5) P no longer depends on A
Concern is that the security system GRANT/REVOKE is based upon the dependency
manager as well as correctness for indexes (e.g. this could cause a recompile
to be missed for an INSERT table when an index is added).
For this to actually happen there has to be a situation where one thread
(connection) can compile a statement that another one fails on (and be
compiling at near identical times). I haven't got a reproducible case yet,
but I can get two statements to be compiling the same statement plan (P).
--
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=12564259#action_12564259 ] Dag H. Wanvik commented on DERBY-3137: -- SYS- (with the hyphen) means the reserved system roles would be delimited identifiers, would it not be simpler to have ones that can be described using regular identifiers? Sorry for the confusion, thats what I meant: SYS. No hyphen. 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] 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=12564270#action_12564270 ] Dag H. Wanvik commented on DERBY-3137: -- Re: identifiers vs CNF: Indeed confusing. I think I was under the impression the values specification would yield a CNF value, which is why I added the extra syntax for using identifers also, like SET SCHEMA does. This is why I was wary of the TRIM I think; a CNF value would not have any protective text quotes around it. One interpretation of 5.2 SR 24 could be that CNF values is only ever available as a string value in queries against the system tables? It would then behoove the app to take into account when comparing, but perhaps it would simplify things on the whole? Or maybe the standard intends for a comparison of CURRENT_ROLE against information schemas to be an identifer comparison, not a string comparison.. in which case the standard is inconsistent I think. 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.
Re: Are SimpleApp.java and SimpleMobileApp.java missing package statements?
John Embretsen wrote:
There was consensus to keep SimpleApp in the default package, see
comments to DERBY-223 [1], but this can of course be changed if so desired.
Hi John, thanks for the follow-up.
What do you think about the following build.xml tweak? In my
environment, it fixes things so that SimpleApp.java and SimpleMobileApp.java
are no longer routinely re-compiled.
Index: java/demo/build.xml
===
--- java/demo/build.xml (revision 616784)
+++ java/demo/build.xml (working copy)
@@ -86,9 +86,8 @@
optimize=${optimize}
proceed=${proceed}
verbose=${verbose}
- srcdir=${derby.demo.src.dir}
- destdir=${out.dir}
- includes=simple/**,simplemobile/**
+ srcdir=${derby.demo.src.dir}/simple:${derby.demo.src.dir}/simplemobile
+ destdir=${out.dir}
classpath
pathelement location=${javasrc.dir};${jcc}/
pathelement path=${java14compile.classpath};${jcc}/
Do you think this would be a reasonable improvement to the build.xml?
thanks,
bryan
[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=12564312#action_12564312 ] Craig Russell commented on DERBY-3301: -- I've applied the patch derby-3301-5.diff and rebuilt the derby and derbytools jars. The JDO TCK tests that fail on the released jars now pass with the patch applied. Thanks so much for getting this bug resolved to this point. This is no longer a blocker for me, assuming that the changes can be committed to the code line and a patch release made in due course. Craig 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 Assignee: Thomas Nielsen Attachments: d3301-queryplan.log, derby-3301-1.diff, derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, derby-3301-4c.diff, derby-3301-5.diff, derby-3301-extra.sql, derby-3301-test-1.diff, derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, derby-3301-test-3.stat, derby-3301-test-master.diff, derby-3301-test-master.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 INTEGER REFERENCES persons NOT NULL ); ij connect 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb'; ij set schema applicationidentity0; 0 rows inserted/updated/deleted ij select * from persons; PERSONID |FIRSTNAME |LASTNAME |MIDDLENAME |BIRTHDATE |ADDRID |STREET |CITY
[jira] Assigned: (DERBY-3014) Make SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username') return NULL instead of the hash value of the password
[
https://issues.apache.org/jira/browse/DERBY-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
R VIDYA LAKSHMI reassigned DERBY-3014:
--
Assignee: R VIDYA LAKSHMI
Make SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.username') return
NULL instead of the hash value of the password
---
Key: DERBY-3014
URL: https://issues.apache.org/jira/browse/DERBY-3014
Project: Derby
Issue Type: Improvement
Components: Security
Reporter: Daniel John Debrunner
Assignee: R VIDYA LAKSHMI
Increases security by providing less information to any attacker. The current
returned hash value could be used in an off-line dictionary based attack to
find a valid password.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
