date:20080123


 [ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dyre Tjeldvoll reassigned DERBY-3343:
-

Assignee: Dyre Tjeldvoll

 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll

 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always


 [ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dyre Tjeldvoll updated DERBY-3343:
--

Derby Info: [Regression]

Marking as regression. Caused by DERBY-827

 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll

 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always


[ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561615#action_12561615
 ] 

Dyre Tjeldvoll commented on DERBY-3343:
---

Based on the comments so far, I'm guessing that the way to fix this is to 
extend HasVariantValueNodeVistor.visit(Visitable v) with special handling of 
ResultColumn objects. It doesn't seem reasonable to make all 
NumericConstantNodes be not constant, and ResultColumn appears to be where 
information about default value/auto-increment is kept. 

ResultColumn has, what appears to be, four relevant predicates:

isAutoincrement()

isAutoincrementGenerated()

isDefaultColumn()

isGenerated()

For the failing example, only isAutoincrementGenerated() returns true.
HasVariantValueNodeVistor.visit(Visitable v)  does not consider any of them.


 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll

 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3189) Replication: Add connection url command options for starting and stopping master

2008-01-23 Thread V.Narayanan (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

V.Narayanan updated DERBY-3189:
---

Attachment: StopMaster_Impl_v4.stat
StopMaster_Impl_v4.diff

This patch propagates the master database name from
EmbedConnection to RawStore where the MASTER_DB property
is initialized before the master controller service is booted.

 Replication: Add connection url command options for starting and stopping 
 master
 

 Key: DERBY-3189
 URL: https://issues.apache.org/jira/browse/DERBY-3189
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: V.Narayanan
 Attachments: derby-3189-1a.diff, derby-3189-1a.stat, 
 StopMaster_impl_3189_v1.diff, StopMaster_impl_3189_v1.stat, 
 StopMaster_impl_3189_v2.diff, StopMaster_impl_3189_v2.diff, 
 StopMaster_impl_3189_v2.stat, StopMaster_impl_3189_v2.stat, 
 StopMaster_impl_3189_v3.diff, StopMaster_impl_3189_v3.stat, 
 StopMaster_Impl_v4.diff, StopMaster_Impl_v4.stat


 Add commands to start and stop the replication master using properties or 
 connection url. Example:
 'jdbc:derby:hostmasterdb;startMaster=true';
 'jdbc:derby:hostmasterdb;stopMaster=true';
 Connection url options that must be recognized:
 startMaster=true
 stopMaster=true
 slaveHost=host (required)
 slavePort=port (optional, defaults to 8001)
 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-3189) Replication: Add connection url command options for starting and stopping master

2008-01-23 Thread V.Narayanan (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

V.Narayanan updated DERBY-3189:
---

Derby Info: [Patch Available]

 Replication: Add connection url command options for starting and stopping 
 master
 

 Key: DERBY-3189
 URL: https://issues.apache.org/jira/browse/DERBY-3189
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: V.Narayanan
 Attachments: derby-3189-1a.diff, derby-3189-1a.stat, 
 StopMaster_impl_3189_v1.diff, StopMaster_impl_3189_v1.stat, 
 StopMaster_impl_3189_v2.diff, StopMaster_impl_3189_v2.diff, 
 StopMaster_impl_3189_v2.stat, StopMaster_impl_3189_v2.stat, 
 StopMaster_impl_3189_v3.diff, StopMaster_impl_3189_v3.stat, 
 StopMaster_Impl_v4.diff, StopMaster_Impl_v4.stat


 Add commands to start and stop the replication master using properties or 
 connection url. Example:
 'jdbc:derby:hostmasterdb;startMaster=true';
 'jdbc:derby:hostmasterdb;stopMaster=true';
 Connection url options that must be recognized:
 startMaster=true
 stopMaster=true
 slaveHost=host (required)
 slavePort=port (optional, defaults to 8001)
 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-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-2.diff

Attaching updated patch 'derby-3301-2.diff'.

The condition for skipping flattening should be even more specific than what is 
implemented in 'derby-3301-2.diff' as per the discussion, so I'm still not 
marking this with patch available. This updated patch will skip flattening if 
the WHERE EXISTS subquery is a select with a where subquery. 

The issue I'm facing is that flatteing of the lower/child WHERE EXISTS removes 
it from the whereSubquerys as it's supposed to. When we later preprocess the 
upper/parent WHERE EXISTS we lack information about what the lower 
whereSubquery originally was. It seems a similar issue was once seen for a 
normal whereClause as a copy of the original clause is kept in the 
SelectNode.originalWhereClause member.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, 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

[jira] Updated: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always


 [ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-3343:
--

Attachment: d3343.diff

The logic in ResultColumn.getOrderableVariantType() looks incorrect. The 
attached patch makes it return Qualifier.VARIANT for all auto-increment 
generated columns. I haven't run any regression tests, but it makes the repro 
run without failure in my sandbox.

 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll
 Attachments: d3343.diff


 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-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=12561634#action_12561634
 ] 

Thomas Nielsen commented on DERBY-3301:
---

Running the query on a faster, dual-core machine actually produce the correct 
results *without* running down the path provided by the last patch.
The queryplan looks totally different on the faster machine. Need to verify it 
still runs the problematic path with a slower machine.
Either different statistics cause the change in queryplan, or (more likely as 
we still are in preprocessing) something else has changed on trunk as well.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Commented: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always


[ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561647#action_12561647
 ] 

Dyre Tjeldvoll commented on DERBY-3343:
---

I agree, but I'm also worried about what happens when some of the other 
predicates are true. Will that ever happen, and could it cause problems? We 
should probably have some more test cases for default values that change 
between executions, but I don't know all the different ways in which this could 
happen.


 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll
 Attachments: d3343.diff


 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3254) Implement the replication failover functionality

2008-01-23 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Øystein Grøvlen updated DERBY-3254:
---

Derby Info:   (was: [Patch Available])

Committed v6 of the patch with some minor changes to a few comments as revision 
614514.

 Implement the replication failover functionality
 

 Key: DERBY-3254
 URL: https://issues.apache.org/jira/browse/DERBY-3254
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: failover_impl_notforcommit.diff, 
 failover_impl_notforcommit.stat, failover_impl_v1.diff, 
 failover_impl_v1.stat, failover_impl_v2.diff, failover_impl_v2.stat, 
 failover_impl_v3.diff, failover_impl_v3.stat, failover_impl_v4.diff, 
 failover_impl_v4.stat, failover_impl_v5.diff, failover_impl_v5.stat, 
 failover_impl_v6.diff, failover_impl_v6.stat




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3326) Introduce a caching logical connection and logical prepared statement in the client driver


 [ 
https://issues.apache.org/jira/browse/DERBY-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan updated DERBY-3326:
---

Derby Info: [Patch Available]

 Introduce a caching logical connection and logical prepared statement in the 
 client driver
 --

 Key: DERBY-3326
 URL: https://issues.apache.org/jira/browse/DERBY-3326
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
 Fix For: 10.4.0.0

 Attachments: derby-3326-1a_cpds_testing_preparation.diff, 
 derby-3326-1a_cpds_testing_preparation.stat


 A logical connection with statement caching capabilities is required to 
 support JDBC prepared statement pooling. Further, a logical prepared 
 statement object is also needed.
 The logical prepared statements will be generated by the logical connection's 
 'prepareStatement'-method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3326) Introduce a caching logical connection and logical prepared statement in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kristian Waagan updated DERBY-3326:
---

Attachment: derby-3326-1a_cpds_testing_preparation.stat
derby-3326-1a_cpds_testing_preparation.diff

'derby-3326-1a_cpds_testing_preparation.diff' is a preparation step for reusing
existing tests with a ConnectionPoolDataSource producing connections with
statement pooling enabled.
Summary of changes:

* TestConfiguration
Added method 'connectionCPDecorator'.

* ConnectionPoolDataSourceConnector
Added new class (basically a copy of XADataSourceConnector).

Patch ready for review.

Introduce a caching logical connection and logical prepared statement in the
client driver
--

Key: DERBY-3326
URL: https://issues.apache.org/jira/browse/DERBY-3326
Project: Derby
Issue Type: Sub-task
Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Fix For: 10.4.0.0

Attachments: derby-3326-1a_cpds_testing_preparation.diff,
derby-3326-1a_cpds_testing_preparation.stat

A logical connection with statement caching capabilities is required to
support JDBC prepared statement pooling. Further, a logical prepared
statement object is also needed.
The logical prepared statements will be generated by the logical connection's
'prepareStatement'-method.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3308) Broken synchronization for event handling in ClientPooledConnection40


 [ 
https://issues.apache.org/jira/browse/DERBY-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan updated DERBY-3308:
---

   Derby Info: [Patch Available]
Fix Version/s: 10.4.0.0

 Broken synchronization for event handling in ClientPooledConnection40
 -

 Key: DERBY-3308
 URL: https://issues.apache.org/jira/browse/DERBY-3308
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby-3308-1a-eventlisteners_synchronization.diff


 Access to the the list of event listeners is not synchronized properly.
 Taken the rather infrequent use of the relevant methods and the small 
 critical sections, I mean it is sufficient to add synchronization to all the 
 methods that access it at the method level. The same approach is taken in 
 ClientPooledConnection (although not followed through consistently, some of 
 the methods are unsynchronized).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3308) Broken synchronization for event handling in ClientPooledConnection40


 [ 
https://issues.apache.org/jira/browse/DERBY-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan updated DERBY-3308:
---

Attachment: derby-3308-1a-eventlisteners_synchronization.diff

'derby-3308-1a-eventlisteners_synchronization.diff' synchronizes all methods 
accessing the list (a java.util.Vector) of statement event listeners.

I ran derbyall/suites.All without errors. Patch ready for review.

 Broken synchronization for event handling in ClientPooledConnection40
 -

 Key: DERBY-3308
 URL: https://issues.apache.org/jira/browse/DERBY-3308
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby-3308-1a-eventlisteners_synchronization.diff


 Access to the the list of event listeners is not synchronized properly.
 Taken the rather infrequent use of the relevant methods and the small 
 critical sections, I mean it is sufficient to add synchronization to all the 
 methods that access it at the method level. The same approach is taken in 
 ClientPooledConnection (although not followed through consistently, some of 
 the methods are unsynchronized).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail

2008-01-23 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jørgen Løland updated DERBY-3184:
-

Attachment: derby-3184-3b.diff

Hi Øystein,

Thanks for reviewing the patch. v3b addresses your comments. All tests pass - 
the patch is ready for review.

 Replication: Connection attempts to a database in slave mode must fail
 --

 Key: DERBY-3184
 URL: https://issues.apache.org/jira/browse/DERBY-3184
 Project: Derby
  Issue Type: Sub-task
  Components: Services
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: Jørgen Løland
 Attachments: derby-3184-1.diff, derby-3184-1.stat, 
 derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, 
 derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, 
 derby-3184-3a.stat, derby-3184-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-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561663#action_12561663
]

Knut Anders Hatlen commented on DERBY-3192:
---

Does that mean I can use codepoints in the range [0xC000-0x] to
product-unique stuff?

Yes, that's how I interpret it.

And use them as instance variables in OPNQRYRM/QRYDTA?

I think so. EXTENSIONS on page 381 says:

In both cases, the framework of existing DDM classes are used as the basis
for extensions to
DDM architecture. DDM allows the following open architecture enhancements:
• Whole new classes of objects (such as libraries or mailboxes) can be
defined, either with
new commands and replies unique to the class, or with existing DDM commands
and
replies as appropriate.
• Defining new commands for class can enhance the function of DDM classes.
• New parameters can be added to existing DDM commands.
• New values can be defined as valid for existing DDM parameters.

Strictly speaking, OPNQRYRM and QRYDTA are replies, not commands. I don't see
why we should be allowed to add parameters to existing DDM commands, but not to
existing replies. If we want to follow the spec's letter, we may need to invent
a new codepoint for the reply messages too, not only for the added instance
variables. I may be missing something, though...

Cache session data in the client driver
---

Key: DERBY-3192
URL: https://issues.apache.org/jira/browse/DERBY-3192
Project: Derby
Issue Type: Improvement
Components: JDBC, Network Client, Network Server, Performance, SQL
Affects Versions: 10.3.1.4
Reporter: Dyre Tjeldvoll
Assignee: Dyre Tjeldvoll
Attachments: derby-3192-test.fup1.diff, derby-3192-test.fup2.diff,
derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff

The reason for doing this is to avoid a rather
substantial performance hit observed when the client driver is used
together with an appserver that uses connection pooling. There are two
problems:
1) The connection pool will compare the isolation level it has
stored for the connection with the value returned from
Connection.getTransactionIsolation() each and every time someone
requests a new connection from the pool.
2) The users of the connection pool (ab)use it to avoid having to keep
track of their current connection. So each time a query needs to be
executed a call to the connection pool's getConnection() method is
made. Getting a connection from the connection pool like this also
means that a new PreparedStatement must be prepared each time.
The net result is that each query results in the following sequence:
getConnection()
getTransactionIsolation() -- roundtrip + lookup in server's statement cache
prepareStatment() -- roundtrip + lookup in server's statement cache
executeQuery()-- roundtrip
Arguably this is a user error but when suggesting this I'm kindly
informed that this works just fine with other datbases (such as
PostgreSQL and ORACLE).
The reason why it works is that these databases do statement caching
in the driver. I've tried to implement a very (too) simple statement
cache in Derby's client driver and to re-enable caching of the
isolation level (see
https://issues.apache.org/jira/browse/DERBY-1148). With these changes
I observe a marked performance improvement when running with appserver
load.
A proper statment cache cannot be implemented without knowing what the
current schema is. If the current schema has changed since the
statement was prepared, it is no longer valid and must be evicted from
the cache.
The problem with caching both the isolation level and the current schema in
the driver is that both can change on the server without the client
detecting it (through SQL and XA and possibly stored procedures).
I think this problem can be overcome if we piggy-back the information we
would
like to cache on messages going back to the client. This can be done by
utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume
3,
page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD
in the reply,
I think it would be possible to cache additional session information when
this becomes relevant. It
would also be possible to use EXCSQLSET to batch session state changes
going from the client to the server.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3260) NullPointerException caused by race condition in GenericActivationHolder


 [ 
https://issues.apache.org/jira/browse/DERBY-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen resolved DERBY-3260.
---

   Resolution: Fixed
Fix Version/s: 10.3.2.2

Merged to 10.3 (revision 614530)

 NullPointerException caused by race condition in GenericActivationHolder
 

 Key: DERBY-3260
 URL: https://issues.apache.org/jira/browse/DERBY-3260
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 
 10.2.2.0, 10.3.1.4
Reporter: Robert Yokota
Assignee: Knut Anders Hatlen
Priority: Blocker
 Fix For: 10.3.2.2, 10.4.0.0

 Attachments: d3260.diff, GenericActivationHolder.java.diff


 I have a stress test using Derby 10.3.1.4 which is executing the same 
 PreparedStatement using multiple threads concurrently and I consistently get 
 the following NPE after several hours of running:
 2007-12-07 00:48:10.914 GMT Thread[pool-5-thread-25,5,main] (XID = 1219661), 
 (SESSIONID = 377), (DATABASE = /usr/ironhide/var/db/opera/derby), (DRDAID = 
 null), Failed Statement is: select rdbmsvaria0_.GUID_AND_INDEX as GUID1_3_0_, 
 rdbmsvaria0_.VALUE2 as VALUE2_3_0_, rdbmsvaria0_.HOLDER_GUID as HOLDER3_3_0_, 
 rdbmsvaria0_.VALUE_TYPE as VALUE4_3_0_, rdbmsvaria0_.VALUE_GUID as 
 VALUE5_3_0_, rdbmsvaria0_.DELETED as DELETED3_0_ from VARIABLE rdbmsvaria0_ 
 where rdbmsvaria0_.GUID_AND_INDEX=? with 1 parameters begin parameter #1: 
 9C202AB9E8356288A9320C9C383A4D2F-11 :end parameter
 java.lang.NullPointerException
 at 
 org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:271)
 at 
 org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:275)
 at 
 org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
 at org.hibernate.loader.Loader.getResultSet(Loader.java:1787)
 at org.hibernate.loader.Loader.doQuery(Loader.java:674)
 at 
 org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
 at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
 at 
 org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
 at 
 org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
 at 
 org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
 at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
 at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
 at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
 at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301)
 at $Proxy41.get(Unknown Source)
 at 
 com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getRdbmsVariable(RdbmsContextHolder.java:108)
 at 
 com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getVariable(RdbmsContextHolder.java:94)
 at com.approuter.maestro.vm.Frame.getParameter(Frame.java:218)
 at com.approuter.maestro.vm.Task.getParameter(Task.java:1267)
 at 
 com.approuter.maestro.vm.CallContextImpl.setOutputParameter(CallContextImpl.java:195)
 at 
 com.approuter.maestro.vm.CallContextImpl.getOutputParameterWriter(CallContextImpl.java:264)
 at 
 com.approuter.maestro.sdk.mpi.DynamicExecutableActivity$3$1.getWriter(DynamicExecutableActivity.java:249)
 at 
 com.approuter.module.xml.XmlSerializeTextActivity$XmlSerializeTextActivityInstance.serialize(XmlSerializeTextActivity.java:43)

[jira] Commented: (DERBY-3308) Broken synchronization for event handling in ClientPooledConnection40


[ 
https://issues.apache.org/jira/browse/DERBY-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561670#action_12561670
 ] 

Knut Anders Hatlen commented on DERBY-3308:
---

The patch looks fine to me.

Since the list is now guarded by synchronization on the pooled connection, 
couldn't it be changed from Vector to ArrayList? (Should be safe to do with 
listeners_ in the parent class as well.)

 Broken synchronization for event handling in ClientPooledConnection40
 -

 Key: DERBY-3308
 URL: https://issues.apache.org/jira/browse/DERBY-3308
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby-3308-1a-eventlisteners_synchronization.diff


 Access to the the list of event listeners is not synchronized properly.
 Taken the rather infrequent use of the relevant methods and the small 
 critical sections, I mean it is sufficient to add synchronization to all the 
 methods that access it at the method level. The same approach is taken in 
 ClientPooledConnection (although not followed through consistently, some of 
 the methods are unsynchronized).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

2008-01-23 Thread John H. Embretsen (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561683#action_12561683
]

John H. Embretsen commented on DERBY-1387:
--

I finally got this patch to build without requiring extra jar files. I have
tested that the Network Server runs fine with jdk1.4 if jmx is not enabled, and
that basic JMX management works fine when using JDK 6, but I have not run other
tests so far. (Trying to run using jdk1.4 with jmx enabled currently results in
a fatal error, which is something I hope to improve eventually by providing a
more helpful error message)

I would however appreciate some input on whether my solution so far is
something we can live with or if it needs refinements. This is what I did to
make it build:

- Made org.apache.derby.iapi.services.mbeans.ManagementService independent
of JMX / jdk1.5:

This was necessary because ManagementService is an interface
representing the (JMX) module that is referenced elsewhere in
the Derby code, regardless of the availability of JMX support.

The implementation(s) of this interface may (must) refer to the JMX
API, but the interface itself may not. Otherwise, all code referencing
this interface must also be compiled with JMX support in the
classpath, which is not the default on jdk1.4. Care should be taken not
to call methods of this interface if JMX support is not available.

Changes were:

- Removed getMBeanServer() method (was not used), which returned a
JMX object (MBeanServer). Callers (e.g. NetworkServerControlImpl) can
access (create, destroy, register) MBeans through this interface, but may
no longer get direct access to the MBean server unless they call the
implementing class (BasicManagementService) directly.
- Changed second parameter of registerMBean() method to take a String
representing a JMX ObjectName instead of the ObjectName itself. It
is then up to the implementing class to create the actual ObjectName
object based on that String.

- NetworkServerControlImpl now calls the ManagementService interface
without having to refer to the JMX API (e.g. ObjectName), which means it
may be compiled with jdk1.4 and be runnable without JMX support.

- Changed build scripts so that org.apache.derby.iapi.services.mbeans is
compiled with ${compile.classpath} (jdk1.4 / jsr169).

- Added missing class o.a.d.impl.services.MDatabase.java.

My JMX experience may be limited, but not more so than my knowledge of Derby
code internals ;) I'll continue to work on an updated patch, but any comments
or advice will be appreciated in the mean time.

Add JMX extensions to Derby
---

Key: DERBY-1387
URL: https://issues.apache.org/jira/browse/DERBY-1387
Project: Derby
Issue Type: New Feature
Components: Services
Reporter: Sanket Sharma
Assignee: John H. Embretsen
Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff,
DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff,
DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip,
DERBY-1387-7.zip, DERBY-1387-8.zip, derbyjmx.patch, jmx.diff, jmx.stat,
jmxFuncspec.html, Requirements for JMX Updated.html, Requirements for
JMX.html, Requirements for JMX.zip

This is a draft requirement specification for adding monitoring and
management extensions to Apache Derby using JMX. The requirements document
has been uploaded on JIRA as well as the Derby Wiki page at
http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
Developers and Users are requested to please look at the document (feature
list in particular) and add their own rating to features by adding a coloumn
to the table.
Comments are welcome.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3308) Broken synchronization for event handling in ClientPooledConnection40

[
https://issues.apache.org/jira/browse/DERBY-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kristian Waagan updated DERBY-3308:
---

Attachment: derby-3308-1b-eventlisteners_synchronization.diff

Thanks for commenting on the patch Knut Anders.

I have incorporated you suggestion about replacing Vector with ArrayList in
revision 1b.

Regarding the suggested changes in the parent class, there are some methods
that are synchronized and some that are not. A patch could be attached to the
subtask of this issue. Feel free to add it, or maybe I will if I get around to
it.

Broken synchronization for event handling in ClientPooledConnection40
-

Key: DERBY-3308
URL: https://issues.apache.org/jira/browse/DERBY-3308
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
Fix For: 10.4.0.0

Attachments: derby-3308-1a-eventlisteners_synchronization.diff,
derby-3308-1b-eventlisteners_synchronization.diff

Access to the the list of event listeners is not synchronized properly.
Taken the rather infrequent use of the relevant methods and the small
critical sections, I mean it is sufficient to add synchronization to all the
methods that access it at the method level. The same approach is taken in
ClientPooledConnection (although not followed through consistently, some of
the methods are unsynchronized).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3308) Broken synchronization for event handling in ClientPooledConnection40


 [ 
https://issues.apache.org/jira/browse/DERBY-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan resolved DERBY-3308.


Resolution: Fixed
Derby Info:   (was: [Patch Available])

Committed 'derby-3308-1a-eventlisteners_synchronization.diff' to trunk with 
revision 614536.

I don't expect there will be more work on this issue, will close in a few days.

 Broken synchronization for event handling in ClientPooledConnection40
 -

 Key: DERBY-3308
 URL: https://issues.apache.org/jira/browse/DERBY-3308
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.2.2.0, 10.3.2.1, 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby-3308-1a-eventlisteners_synchronization.diff, 
 derby-3308-1b-eventlisteners_synchronization.diff


 Access to the the list of event listeners is not synchronized properly.
 Taken the rather infrequent use of the relevant methods and the small 
 critical sections, I mean it is sufficient to add synchronization to all the 
 methods that access it at the method level. The same approach is taken in 
 ClientPooledConnection (although not followed through consistently, some of 
 the methods are unsynchronized).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[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=12561691#action_12561691
]

Knut Anders Hatlen commented on DERBY-3325:
---

I think your approach is fine. One variant that you may consider, is to move
the getter and the field to ClientConnectionPoolDataSource and make the field
private, and write a new getter in ClientBaseDataSource that just returns 0.
Then you state more explicitly that the field is only used by CCPDS, and that
DataSource classes that don't override getMaxStatement() never cache
statements. Not that there's much difference between the variants, so feel free
to choose whichever you want...

I noticed that testGetConnectionWithStatemenPooling() (whose name misses a 't'
in 'Statement', btw, as does its sibling s/With/Without/) was disabled, but
after a brief inspection I couldn't see that anything would fail even before
statement pooling is implemented. Perhaps it could be enabled right away?

Could you log an issue for the bug you found in the test framework? It seems
unnecessary that every test that uses DataSources needs to have a workaround
for the 08004 error when running standalone. It would at least be good to track
it.

Test code that looks like this:

+rs = ps1.executeQuery();
+assertTrue(rs.next());
+assertEquals(31, rs.getInt(1));

would be simpler (and have rs closed automatically) if written like this:

JDBC.assertSingleValueResultSet(ps1.executeQuery(), 31);

Add 'maxStatements' property to ClientConnectionPoolDataSource
--

Key: DERBY-3325
URL: https://issues.apache.org/jira/browse/DERBY-3325
Project: Derby
Issue Type: Sub-task
Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
Fix For: 10.4.0.0

Attachments: derby-3325-1a-maxStatements.diff,
derby-3325-1a-maxStatements.stat

The classes in Derby implementing javax.sql.ConnectionPoolDataSource must
provide setter and getter methods for the property 'maxStatements'.
This property is used to control the whether the data source should produce
pooled connections with statement cache capabilities or not, and how big the
statement cache is allowed to be.
This issue only deals with the client JDBC driver.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail

2008-01-23 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Øystein Grøvlen updated DERBY-3184:
---

Derby Info:   (was: [Patch Available])

Patch 3b committed as revision 614549.

 Replication: Connection attempts to a database in slave mode must fail
 --

 Key: DERBY-3184
 URL: https://issues.apache.org/jira/browse/DERBY-3184
 Project: Derby
  Issue Type: Sub-task
  Components: Services
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: Jørgen Løland
 Attachments: derby-3184-1.diff, derby-3184-1.stat, 
 derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, 
 derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, 
 derby-3184-3a.stat, derby-3184-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-3324) JDBC statement cache implementation


[ 
https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561721#action_12561721
 ] 

Knut Anders Hatlen commented on DERBY-3324:
---

The code looks correct to me, and the unit tests seem to cover the code well. 
Some comments/suggestions follow below (mostly stylistic, feel free to ignore).

If the cache always creates physical CallableStatement objects internally 
(except for prepared statements with auto-generated keys, which aren't 
supported by CallableStatement), and creates logical prepared/call wrappers 
around them, it doesn't need different keys for prepared and call statements, 
so the class hierarchy could be simplified (no need for CallKey). Just a 
thought...

I'm not sure I see the value of such a complex class hierarchy for the 
statement keys. First there is a StatementKey interface which is essentially 
empty (only contains methods already in java.lang.Object). Then there's an 
AbstractStatementKey class which contains some basic information about the 
statement. And then finally three different sub-classes BasicKey (for prepared 
statements without generated keys), AutoGeneratedKeysKey (for prepared 
statements with generated keys) and CallKey (for callable statements), all of 
which only override equals() and hashCode() so that they consider the sub-type.

I feel that the separation into different classes makes it harder to read the 
code. Also, it feels a bit arbitrary whether a property is represented in a 
field or as a sub-class. Wouldn't it be simpler just to add two fields to 
AbstractStatementKey
  - callable (which could also be skipped, see above)
  - autoGeneratedKeys
and merge the five classes/interfaces into a single class StatementKey?

Other comments:

BasicKey and AutoGeneratedKeysKey have identical hashCode() methods (31 * 
super.hashCode()). Although it's not a bug, it's probably better to use 
different numbers.

AbstractStatementKey and subclasses:
+ * @throws IllegalArgumentException if codesql/code and/or
+ *  codeschema/code is codenull/code
I think it is more common (at least in the standard Java API) to throw 
NullPointerException instead of IllegalArgumentException when an argument is 
(illegally) null.

JDBCStatementCache.cacheStatement:
+ * @param ps prepared statment to cache
typo: statment - statement

 JDBC statement cache implementation
 ---

 Key: DERBY-3324
 URL: https://issues.apache.org/jira/browse/DERBY-3324
 Project: Derby
  Issue Type: Sub-task
  Components: Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: derby-3324-1a-jdbc_statementcache.diff, 
 derby-3324-1a-jdbc_statementcache.stat, 
 derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat


 Implement a cache for storing JDBC prepared statement objects.
 The cache will be responsible for holding free prepared statement objects 
 that can be reused, and also to throw away objects if the cache grows too big.
 All objects in the cache must belong to the same physical connection, but 
 they can be reused across logical connections obtained from a single physical 
 connection in a connection pool.
 This component is probably a candidate for code sharing between the client 
 and the embedded driver. Sharing will not  be part of this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] 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=12561719#action_12561719
]

Daniel John Debrunner commented on DERBY-3325:
--

+throw new IllegalArgumentException(Negative values for max +
+statements are not allowed: + maxStatements);

There seems to be a worrying trend of adding English only, non-localized
messages. Derby has always used localization for almost all error messages,
ClientBaseDataSource already has a couple of localized exceptions, any reason
not to use the mechanism here?

Not sure I understand the comment avoid avoiding casts in the factory methods.
Why would the factory methods care about max statements, won't the logic of
statement pooling be self-contained in either the pooling data source or
pooling connection? Is there another patch that shows this?

Since we are adding a field to a serializable class are there any issues around
that? Ie. 10.0 data sources serialized need to be unserialized correctly with
10.4 code.

XA can support statement pooling, XAConnection extends PooledConnection,
therefore it inherits all the behaviour of PooledConnection and thus section
11.6 of JDBC 4 spec applies to XA. If your own itch is just non-XA data sources
then that's fine.

Add 'maxStatements' property to ClientConnectionPoolDataSource
--

Attachments: derby-3325-1a-maxStatements.diff,
derby-3325-1a-maxStatements.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always


 [ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dyre Tjeldvoll updated DERBY-3343:
--

Attachment: defaults.sql

Attaching an ij script (defaults.sql) which tests most of the legal 
default/autogen cases, (did not try to modify user between executions and did 
not test current time and current date). The error appears for all GENERATED AS 
IDENTITY columns when the default is specified explicitly, e.g. INSERT INTO 
T(I) VALUES(default) fails, but INSERT INTO T(X) VALUES(something) works 
correctly. INT, SMALLINT and BIGINT all have the same problem.

Knut's patch appears to fix all these cases.

 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll
 Attachments: d3343.diff, defaults.sql


 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3279) Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and VARCHAR column contains a value of '00000'

2008-01-23 Thread Ajay Bhala (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561729#action_12561729
 ] 

Ajay Bhala commented on DERBY-3279:
---

AB, just wondering if you can provide me with an update on the fix you have 
available.

Thanks,

Ajay

 Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and 
 VARCHAR column contains a value of '0'
 --

 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

 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] Subscription: Derby: JIRA issues with patch available

2008-01-23 Thread jira

Issue Subscription
Filter: Derby: JIRA issues with patch available (14 issues)
Subscriber: derby-dev


Key Summary
DERBY-3324  JDBC statement cache implementation
https://issues.apache.org/jira/browse/DERBY-3324
DERBY-3325  Add 'maxStatements' property to ClientConnectionPoolDataSource
https://issues.apache.org/jira/browse/DERBY-3325
DERBY-3326  Introduce a caching logical connection and logical prepared 
statement in the client driver
https://issues.apache.org/jira/browse/DERBY-3326
DERBY-3189  Replication: Add connection url command options for starting and 
stopping master
https://issues.apache.org/jira/browse/DERBY-3189
DERBY-3137  SQL roles: add catalog support
https://issues.apache.org/jira/browse/DERBY-3137
DERBY-3050  Convert groupBy.sql tests to JUnit and include them in 
GroupByTest.java
https://issues.apache.org/jira/browse/DERBY-3050
DERBY-3205  Replication: Add connection url command options for starting, 
stopping slave and for failover
https://issues.apache.org/jira/browse/DERBY-3205
DERBY-3088  convert to junit, or otherwise eliminate version in tests which 
require an update of the master in the release management process
https://issues.apache.org/jira/browse/DERBY-3088
DERBY-3169  Add documentation for replication
https://issues.apache.org/jira/browse/DERBY-3169
DERBY-2871  XATransactionTest gets XaException: Error executing a 
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3117  Adjust master build script to require the Java 5 compiler to build 
Derby
https://issues.apache.org/jira/browse/DERBY-3117
DERBY-2953  Dump the information about rollbacks of the global transaction 
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-3083  Network server demands a file called derbynet.jar in classpath
https://issues.apache.org/jira/browse/DERBY-3083
DERBY-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

[jira] Commented: (DERBY-3279) Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and VARCHAR column contains a value of '00000'


[ 
https://issues.apache.org/jira/browse/DERBY-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561732#action_12561732
 ] 

A B commented on DERBY-3279:


Hi Ajay,

Sorry for the delay, I've had other things on my plate.  But as it turns out, I 
was working with this yesterday and just a few minutes ago I kicked off the 
nightly regression tests with what I _think_ is an acceptable patch for this 
issue.  I still need to clean up the changes/comments a bit, but if the tests 
all pass I hope to post something by the end of the day today (PST).

 Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and 
 VARCHAR column contains a value of '0'
 --

 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

 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] Assigned: (DERBY-3279) Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and VARCHAR column contains a value of '00000'


 [ 
https://issues.apache.org/jira/browse/DERBY-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A B reassigned DERBY-3279:
--

Assignee: A B

 Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and 
 VARCHAR column contains a value of '0'
 --

 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

 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.

Regression Test Report - Daily 614260 - Sun DBTG

2008-01-23 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 614260/2008-01-22 18:01:05 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0273273 071.60% derbyall
01015810158 0   1422.72% suitesAll
 linN+1
0273273 0   103.87% derbyall
01015810158 0   119.54% suitesAll
 sles
0273273 071.03% derbyall
01015810158 0   906.30% suitesAll
 sol
0273273 075.97% derbyall
01015810158 0   1651.22% suitesAll
 solN+1
0273273 096.76% derbyall
01015810158 0   188.77% suitesAll
 sparc
0273273 065.79% derbyall
01015810158 0   355.40% suitesAll
 vista
0273273 094.25% derbyall
091369136 074.05% suitesAll
 w2003
0273273 095.65% derbyall
091369136 0   133.01% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-614260.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/614260_bySig.html 

*Jvm: 1.5*
 lin
0274274 071.73% derbyall
084408440 0   876.23% suitesAll
 linN+1
0274274 098.21% derbyall
084408440 0   116.02% suitesAll
 sles
1274273 070.58% derbyall
084408440 0   565.57% suitesAll
 sol
0274274 078.08% derbyall
084408440 0   838.15% suitesAll
 solN+1
0274274 088.53% derbyall
084408440 0   796.93% suitesAll
 sparc
0274274 066.59% derbyall
084408440 0   693.24% suitesAll
 vista
0274274 097.87% derbyall
074187418 0   495.24% suitesAll
 w2003
0274274 074.34% derbyall
074187418 0   258.16% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-614260.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/614260_bySig.html 

*Jvm: 1.4*
 lin
0271271 272.76% derbyall
083888388 0   791.80% suitesAll
 linN+1
0271271 299.62% derbyall
083888388 0   115.69% suitesAll
 sles
0271271 270.64% derbyall
083888388 0   527.38% suitesAll
 sol
0271271 278.26% derbyall
083888388 0   676.47% suitesAll
 solN+1
0271271 289.00% derbyall
083888388 0   756.63% suitesAll
 sparc
0271271 267.09% derbyall
083888388 0   696.44% suitesAll
 vista
0271271 296.24% derbyall
073667366 0   465.74% suitesAll
 w2003
0271271 275.32% derbyall
073677367 0   247.46% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-614260.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/614260_bySig.html 

---

Changes in  http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/614260.txt 

( All results in http://dbtg.thresher.com/derby/test/ )

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

2008-01-23 Thread Dag H. Wanvik (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561741#action_12561741
]

Dag H. Wanvik commented on DERBY-3327:
--

Thanks for helping me understand this better!.

So, I can trust the correct statement context to be available at
execution time. But it still seems not to be sufficient? The
statement context is initialized when pushed on the basis of read-only
information from EmbedStatement (which is a JDBC level object if I am
not mistaken again ;) whenever we are preparing/executing/using the
result set of a statement, but it does not have the lifetime of the
procedure so it can't hold the mutable state of current user, role and
schema?

Those would have to be stored in a data structure that would persist
throughout the lifetime of the procedure, I think. First I looked the
statement context of the caller. But using the debugger I see that the
statement context of the call of not pushed back when the a next() is
performed outside the caller on the returned dynamic result set, so
even the statement context of the caller seems to have too short a
lifetime to hold the dynamic state of the nested scope.

So unless I am still missing something here, I will try to work
towards a new context object to hold the nested SQL session state.

SQL roles: Implement authorization stack

Key: DERBY-3327
URL: https://issues.apache.org/jira/browse/DERBY-3327
Project: Derby
Issue Type: New Feature
Components: Security, SQL
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
Fix For: 10.4.0.0

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

The current LanguageConnectionContext keeps the user authorization identifier
for an SQL session.
The lcc is shared context also for nested connections (opened from stored
procedures).
So far, for roles, the current role has been stored in the lcc also. However,
SQL requires that
authorization identifers be pushed on a authorization stack when calling a
stored procedure, cf.
SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
This allows a caller to keep its current role after a call even if changed by
the stored procedure.
This issue will implement the current role name part (cell) of the
authorization stack.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561747#action_12561747
]

Daniel John Debrunner commented on DERBY-3327:
--

Just to be clear, I'm not recommending the StatementContext, just trying to
ensure that some understanding of it exists before another context is added.
The wrong approach would be to blindly add a new context just because
StatementContext is not understood. I think there is probably some overlap
between the StatementContext and a SQLSessionContext, but maybe
StatementContext does not quite match the role of SQLSessionContext, but then
what role is StatementContext implementing in the model defined by the SQL
standard? Discussion like this is good to get an understanding.

Maybe Activation is acting as the SQLSession context, as in your first patch?

I think in the last comment you raise an interesting point: For a procedure
that sets a role R and returns dynamic result sets, the role in force during
the processing of those dynamic result sets needs to be R, even though the
execute of the CALL returned (and thus R was popped from some stack).

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3050) Convert groupBy.sql tests to JUnit and include them in GroupByTest.java

2008-01-23 Thread Bryan Pendleton (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Pendleton resolved DERBY-3050.


   Resolution: Fixed
Fix Version/s: 10.4.0.0
   Derby Info:   (was: [Patch Available])

Committed to the trunk as revision 614596.


 Convert groupBy.sql tests to JUnit and include them in GroupByTest.java
 ---

 Key: DERBY-3050
 URL: https://issues.apache.org/jira/browse/DERBY-3050
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Affects Versions: 10.4.0.0
Reporter: Bryan Pendleton
Assignee: Bryan Pendleton
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: afterMergeWith3257.diff, convertToJunit.diff, 
 convertToJunit.diff, convertToJUnit.diff, convertToJUnit.stat


 There are currently 3 sets of GROUP BY tests:
  - GroupByExpressionTest.java
  - GroupByTest.java
  - groupBy.sql
 The first two tests are JUnit tests; the groupBy.sql tests are old-style 
 harness tests,
 although they are now run in the JUnit framework using the LangScripts 
 technique.
 This sub-task proposes to convert the groupBy.sql tests to JUnit tests, and 
 to include
 them directly into GroupByTest.java.
 The DERBY-2151 conversion tool can be used to assist in the conversion 
 process.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561751#action_12561751
]

Daniel John Debrunner commented on DERBY-3327:
--

I see the point about dynamic result sets was already noted in the functional
spec.

Looking closely at SET ROLE I see it doesn't require a authorization stack
(within a SQLSessionContext) because it only modifies the current role, it
never pushes a new cell onto the authorization stack.

So I'm coming to thinking that the initial patch is basically correct, with the
exception that there is no need to have a stack of activations or to link an
activation to its caller. It seems to me the current stacking of
StatementContexts has the required information already, upon execution the role
of the activation needs to be taken from the role of the activation of
currently executing statement (the most recently pushed StatementContext) or
the lcc if there is no currently statement being executed.

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

2008-01-23 Thread Dag H. Wanvik (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561754#action_12561754
]

Dag H. Wanvik commented on DERBY-3327:
--

The wrong approach would be to blindly add a new
context just because StatementContext is not understood. I think there
is probably some overlap between the StatementContext and a
SQLSessionContext, but maybe StatementContext does not quite match the
role of SQLSessionContext, but then what role is StatementContext
implementing in the model defined by the SQL standard? Discussion like
this is good to get an understanding.

I absolutely agree, I am happy to get your feedback on this, Dan!
I will try to find out where Statement context fits in by reading up
a bit in the standard.

Maybe Activation is acting as the SQLSession context, as in your first
patch?
I think in the last comment you raise an interesting point: For a
procedure that sets a role R and returns dynamic result sets, the role
in force during the processing of those dynamic result sets needs to
be R, even though the execute of the CALL returned (and thus R was
popped from some stack).

I don't really grasp fully the design rationales involved in the
existing code here, I readily admit that. I used the activation of the
caller because it seems to have the correct lifetime to handle also
the dynamic result case (making R available after the call has
returned).

What I don't like about that solution is that the asymmetry (lcc for
outer, caller activation for inner scopes); it would be nice to have a
SQLSessionContext uniformly available somehow from both the root
connection scope and inside the procedures...

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
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

2008-01-23 Thread Anurag Shekhar (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Anurag Shekhar updated DERBY-3330:
--

Attachment: derby-3330v3.diff

This patches fixes all the failures in test suite cased by this
work except for upgrades tests. I am still having failures and
errors in upgrade tests because this patch introduces extra
attribute in BTree and IndexRowGenerator.

II am also seeing one failure in
org.apache.derbyTesting.functionTests.tests.lang.PrimaryKeyTest.testKeyConstraintsImpliesNotNull
but I am getting this error in fresh checkout too.

I have made changes nist.dml019.out in group by tests.
Currently Unique constraint is backed by unique index
and group by clause on unique index internally uses distinct
scan resulting in sorted results. After changing backing
index from unique index to almost unique index distinct
index wasn't used and results appear in random order (similar
to group by clause on non unique indexes). I have modified the
out file to match the output of select with group by clause.

This results in deviation from current behavior but group by
without order by clause need not be sorted so portable
application will not be using this behavior or derby. Derby
manuals also don't promise this behavior.

This change in behavior doesn't mean that nist test is failing
as the test iis supposed to be checking only for the number
of rows and not their order.

provide support for unique constraint over nullable columns
---

Key: DERBY-3330
URL: https://issues.apache.org/jira/browse/DERBY-3330
Project: Derby
Issue Type: New Feature
Components: Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: derby-3330.diff, derby-3330v2.diff, derby-3330v3.diff

Allow unique constraint over nullable field. Right now derby support unique
constraint only over not null columns.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

2008-01-23 Thread Dag H. Wanvik (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561772#action_12561772
]

Dag H. Wanvik commented on DERBY-3327:
--

Looking closely at SET ROLE I see it doesn't require a authorization
stack (within a SQLSessionContext) because it only modifies the
current role, it never pushes a new cell onto the authorization stack.

Yes, thats how I understand it also, it just needs access to the top element
somehow, but does not need to see a stack.

So I'm coming to thinking that the initial patch is basically correct,
with the exception that there is no need to have a stack of
activations or to link an activation to its caller. It seems to me the
current stacking of StatementContexts has the required information
already, upon execution the role of the activation needs to be taken
from the role of the activation of currently executing statement (the
most recently pushed StatementContext) or the lcc if there is no
currently statement being executed.

Thanks, I will investigate this.

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3068) testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure: Unexpected SQL state. expe

2008-01-23 Thread Kathey Marsden (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-3068:
--

Attachment: derby-3068_stat.txt
derby-3068_diff.txt

I made the import changes recommended by Dan and saw the failure in an IBM 1.5 
run after making those changes.  In order to track down further I changed the 
test to delete the files immediately after the test which creates them rather 
than before the test which recreates them and changed deleteFile()  to fail if 
it cannot delete the file.  After this change I can't get the test to fail.  I 
think the changes are an improvement except that somehow they may be making the 
file deletion problem more intermittent.  There may still be an issue with 
import or export.  I'd like to commit my changes as an incremental improvement 
and monitor this issue further.  Patch is derby-3068_diff.txt.  I ran on IBM 
1.5 but will run on jdk 1.6 as well before checking in.




 testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure:
  Unexpected SQL state. expected:38000 but was:XIE0S
 ---

 Key: DERBY-3068
 URL: https://issues.apache.org/jira/browse/DERBY-3068
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: Windows XP IBM 1.5
Reporter: Kathey Marsden
Assignee: Kathey Marsden
 Attachments: derby-3068_diff.txt, derby-3068_stat.txt


 1) 
 testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure:
  Unexpected SQL state. expected:38000 but was:XIE0S
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:668)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:717)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:898)
   at 
 org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest.testImportExportProcedureNegative(ImportExportProcedureTest.java:1933)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
 Caused by: java.sql.SQLException: The export operation was not performed, 
 because the specified output file (extinout/t1.dat) already exists. Export 
 processing will not overwrite an existing file, even if the process has 
 permissions to write to that file, due to security concerns, and to avoid 
 accidental file damage. Please either change the output file name in the 
 export procedure arguments to specify a file which does not exist, or delete 
 the existing file, then retry the export operation.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:893)
   ... 45 more
 Caused by: org.apache.derby.client.am.SqlException: The export operation was 
 not performed, because the specified output file (extinout/t1.dat) already 
 exists. Export processing will not overwrite an existing file, even if the 
 process has permissions to write to

[jira] Created: (DERBY-3344) Error in testNegValueSupportedLogRecord in ugrade test - caused by EOF Exception in store in 10.3

2008-01-23 Thread Myrna van Lunteren (JIRA)

Error in testNegValueSupportedLogRecord in ugrade test - caused by EOF 
Exception in store in 10.3
-

 Key: DERBY-3344
 URL: https://issues.apache.org/jira/browse/DERBY-3344
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.2.2
 Environment: Windows XP - ibm 15 jvm (build pwi32devifx-20070725 
(SR5a))
Reporter: Myrna van Lunteren


I saw this failure first with 10.3 built to revision 613346, then with revision 
614104 ran fine, but then I saw this again with revision 614411.

Historic data shows 3 more failures with this test, but in those cases more 
upgrade tests failed and it appeared there were disk full problems.

The full stack trace from the suites.All for the test is:
testNegValueSupportedLogRecord(org.apache.derbyTesting.functionTests.tests.upgradeTests.Changes10_3)java.sql.SQLException:
 Log Record has been sent to the stream, but it cannot be applied to the store 
(Object null).  This may cause recovery problems also.
at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
Source)
at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
Source)
at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown 
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown 
Source)
at 
org.apache.derbyTesting.functionTests.tests.upgradeTests.Changes10_3.checkDataToCase606(Changes10_3.java:256)
at 
org.apache.derbyTesting.functionTests.tests.upgradeTests.Changes10_3.testNegValueSupportedLogRecord(Changes10_3.java:217)
at sun.reflect.GeneratedMethodAccessor3210.invoke(Unknown Source)
at unknown class.unknown method(Unknown Source)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at

[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:
--

Derby Info: [Patch Available, Existing Application Impact]  (was: [Existing 
Application Impact])
  Assignee: Thomas Nielsen

 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.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] 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-3.diff

Attaching updated patch with correct condition checks for skipping flattening 
of WHERE EXISTS subquerys with nested WHERE EXISTS subqueries.
'derby-3301-3.diff' also takes SubqueryNodes in the where clause, not only 
where subqueries into consideration.

Will run derbyAll and suites.All on this patch and report the results.

Checking patch available, and assigning it to me.


 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Commented: (DERBY-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=12561813#action_12561813
 ] 

Thomas Nielsen commented on DERBY-3301:
---

I should probably add that I got it reproduced on the faster box as well. 
Environmental issue caused breakpoints to not trigger.

 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.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Created: (DERBY-3345) RolesTest fails with weme6.1 in the nightly test run

2008-01-23 Thread Manjula Kutty (JIRA)

RolesTest fails with weme6.1 in the nightly test run


 Key: DERBY-3345
 URL: https://issues.apache.org/jira/browse/DERBY-3345
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.4.0.0
 Environment: OS name: Windows XP
OS architecture: x86
OS version:  5.1 build 2600 Service Pack 2
java.specification.name: J2ME Foundation Specification
java.specification.version: 1.1
- Derby Information 
JRE - JDBC: J2SE 5.0 - JDBC 3.0
[C:\jartest\classes\derby.jar] 10.4.0.0 alpha - (614099)
[C:\jartest\classes\derbytools.jar] 10.4.0.0 alpha - (614099)
[C:\jartest\classes\derbynet.jar] 10.4.0.0 alpha - (614099)
[C:\jartest\classes\derbyclient.jar] 10.4.0.0 alpha - (614099)
Reporter: Manjula Kutty


testPositive(org.apache.derbyTesting.functionTests.tests.lang.RolesTest)junit.framework.AssertionFailedError:
 stmt call p2('FOO') failed with exception 38000
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doStmtWithWarnings(RolesTest.java:704)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doStmt(RolesTest.java:634)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doStmt(RolesTest.java:615)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doSetRoleInsideStoredProcedures(RolesTest.java:809)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.testPositive(RolesTest.java:407)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
at unknown class.unknown method(Unknown Source)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
2) 
testPositive(org.apache.derbyTesting.functionTests.tests.lang.RolesTest)junit.framework.ComparisonFailure:
 Stmt grant admin to authid expected:0P000 but was:4251A
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:687)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doStmtWithWarnings(RolesTest.java:714)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doStmt(RolesTest.java:634)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.doStmt(RolesTest.java:615)
at 
org.apache.derbyTesting.functionTests.tests.lang.RolesTest.testPositive(RolesTest.java:377)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
at unknown class.unknown method(Unknown Source)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at

[jira] Commented: (DERBY-3343) Subsequent calls to PreparedStatement cause SQLIntegrityConstraintViolationException on column that is Generated always


[ 
https://issues.apache.org/jira/browse/DERBY-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561821#action_12561821
 ] 

Dyre Tjeldvoll commented on DERBY-3343:
---

I just realized that the behavior I described in my previous comment matches 
perfectly with the problem pointed out by Knut. Presumably 
ResultColumn.expression is non-null exactly when there is no VALUES(default) 
clause. Which, in turn,  explains why the isAutoincrementGenerated() predicate 
only gets evaluated when there is no explicit VALUES(default) clause. 

 Subsequent calls to PreparedStatement cause 
 SQLIntegrityConstraintViolationException on column that is  Generated always
 --

 Key: DERBY-3343
 URL: https://issues.apache.org/jira/browse/DERBY-3343
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.2.1
 Environment: gentoo linux amd64
Reporter: William Becker
Assignee: Dyre Tjeldvoll
 Attachments: d3343.diff, defaults.sql


 The following series of statements fails:
 j connect 'jdbc:derby:test;create=true';
 ij create table t (id int primary key generated always as identity);
 0 rows inserted/updated/deleted
 ij prepare p as 'insert into t(id) values (default)';
 ij execute p;
 1 row inserted/updated/deleted
 ij execute p;
 ERROR 23505: The statement was aborted because it would have caused a 
 duplicate key value in a unique or primary key constraint or unique index 
 identified by 'SQL080123140906700' defined on 'T'.
 There is a more detailed discussion about it here: 
 http://www.nabble.com/Generate-Always-and-SQLIntegrityConstraintViolationException-td15012038.html#a15018054

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3068) testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure: Unexpected SQL state. expe

2008-01-23 Thread Kathey Marsden (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-3068:
--

Derby Info: [Patch Available]

 testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure:
  Unexpected SQL state. expected:38000 but was:XIE0S
 ---

 Key: DERBY-3068
 URL: https://issues.apache.org/jira/browse/DERBY-3068
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: Windows XP IBM 1.5
Reporter: Kathey Marsden
Assignee: Kathey Marsden
 Attachments: derby-3068_diff.txt, derby-3068_stat.txt


 1) 
 testImportExportProcedureNegative(org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest)junit.framework.ComparisonFailure:
  Unexpected SQL state. expected:38000 but was:XIE0S
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:668)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:717)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:898)
   at 
 org.apache.derbyTesting.functionTests.tests.tools.ImportExportProcedureTest.testImportExportProcedureNegative(ImportExportProcedureTest.java:1933)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
   at junit.extensions.TestSetup.run(TestSetup.java:23)
 Caused by: java.sql.SQLException: The export operation was not performed, 
 because the specified output file (extinout/t1.dat) already exists. Export 
 processing will not overwrite an existing file, even if the process has 
 permissions to write to that file, due to security concerns, and to avoid 
 accidental file damage. Please either change the output file name in the 
 export procedure arguments to specify a file which does not exist, or delete 
 the existing file, then retry the export operation.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.client.am.PreparedStatement.execute(Unknown Source)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:893)
   ... 45 more
 Caused by: org.apache.derby.client.am.SqlException: The export operation was 
 not performed, because the specified output file (extinout/t1.dat) already 
 exists. Export processing will not overwrite an existing file, even if the 
 process has permissions to write to that file, due to security concerns, and 
 to avoid accidental file damage. Please either change the output file name in 
 the export procedure arguments to specify a file which does not exist, or 
 delete the existing file, then retry the export operation.
   at org.apache.derby.client.am.Statement.completeExecute(Unknown Source)
   at 
 org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
   at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown 
 Source)
   at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown 
 Source)
   at org.apache.derby.client.am.Statement.readExecuteCall(Unknown Source)
   at

[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-3b.diff

'derby-3301-3b.diff' fixes NPE seen in suites.All with the last patch.

 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.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Updated: (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 updated DERBY-3342:
-

Priority: Minor  (was: Major)
Assignee: Daniel John Debrunner

 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

 DatabaseMetaDataTest.testGetProceduresGetProcColumns asserts that column 9 
 (LENGTH) is NULLABLE. (line 4364 of the test).
 However the column comes directly from the internal virtual table 
 GetProcedureColumns which has its length column as not nullable (line 327 of 
 GetProcedureColumns.java).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3037) Language ResultSet.finish() is called even when the ResultSet is going to be re-used.


[ 
https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561831#action_12561831
 ] 

Daniel John Debrunner commented on DERBY-3037:
--

Two thoughts:

  - What is the purpose of commit() closing the language result sets? If it's 
to close JDBC ResultSets that are marked close at commit then a possibility is 
to only close language result sets that return rows (returnRows() returns 
true). That would leave language result sets that do not return rows open, but 
by definition (I think) those are the ones that are actively executing and the 
very ones we don't want to close. :-)

 - Should commit() be allowed in all routines? I can see a commit makes sense 
in a procedure, to allow a section of logic to be encapsulated in a procedure 
with transaction semantics.  But a commit() in a function seems dubious, what 
should happen when a function performs a commit (or rollback) in the middle of 
a SELECT statement or even worse a DML statement like an INSERT?

 Language ResultSet.finish() is called even when the ResultSet is going to be 
 re-used.
 -

 Key: DERBY-3037
 URL: https://issues.apache.org/jira/browse/DERBY-3037
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.4.0.0
Reporter: Daniel John Debrunner
Assignee: Mamta A. Satoor
 Fix For: 10.3.2.2, 10.4.0.0

 Attachments: DERBY3037_patch_not_ready_for_commit_v2_diff.txt, 
 DERBY3037_patch_not_ready_for_commit_v2_stat.txt, 
 Derby_3037_AlterTableConstantActionChanges_v1_diff.txt, 
 Derby_3037_AlterTableConstantActionChanges_v1_stat.txt, DERBY_3304_Repro.java


 DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to 
 be the lifetime of the activation, but did not fix up the correct calls to 
 ResultSet.close() and ResultSet.finish().
 A language ResultSet's lifetime should be driven by the activation, so 
 activation.close() should call finish() on its ResultSet.
 EmbedResultSet should call close on its language ResultSet (theResults field) 
 when the JDBC ResultSet is closed, it should not be calling finish() on its 
 ResultSet.
 See comments in DERBY-827 for some more details and issues.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3279) Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and VARCHAR column contains a value of '00000'


 [ 
https://issues.apache.org/jira/browse/DERBY-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A B updated DERBY-3279:
---

Attachment: d3279_v1.patch

Attaching a first attempt at resolving this issue.

The problem as described above only occurs in situations where 
preprocessing/optimization eliminates a sort.  There is already a method called 
adjustForSortElimination() defined in ResultSetNode, so this patch creates an 
alternate signature that takes an OrderByList as an argument.  Then, in the 
case where sort elimination occurs, we will search a table's predicates to see 
if any of them is a multi-probing predicate.  If so, we check to see if the 
ORDER BY that was eliminated required a DESCENDING sort on the multi-probe 
column, and we adjust for that (if needed) by sorting the IN list values into 
descending order at execution time.  See code comments for details.

I ran derbyall and suites.All with this patch applied and saw no failures.  
Review comments are appreciated.

 Derby 10.3.X sorts VARCHAR column incorrectly when table is indexed and 
 VARCHAR column contains a value of '0'
 --

 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
 Attachments: 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:
---

Summary: 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.  (was: Derby 10.3.X sorts VARCHAR 
column incorrectly when table is indexed and VARCHAR column contains a value of 
'0')

Changing summary to more closely describe  the problem.

 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
 Attachments: 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
 Attachments: 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] Created: (DERBY-3346) DatabaseMetaData.getIndexInfo returns the wrong nullabilty for column 4 NON_UNIQUE

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


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] Created: (DERBY-3347) ERROR XSDB3: Container information cannot change once written

2008-01-23 Thread Bogdan Calmac (JIRA)

ERROR XSDB3: Container information cannot change once written
-

 Key: DERBY-3347
 URL: https://issues.apache.org/jira/browse/DERBY-3347
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.2.1
 Environment: Windows 2003 Server
Sun Java 1.6.0_03
Reporter: Bogdan Calmac
Priority: Critical


We are using derby as an embedded DB for our data collection server. During an 
endurance test when we do around 270 inserts and 9 updates per second, for 
about a week, I ocasionally see the error below in the deby log (and nothing 
else beside this).

This is a vanilla installation, we run derby embedded with no extra 
configuration.  I can confirm that there is no memory problem, the heap usage 
seems constant over time.

Can somebody provide some more information regarding the effects of this error? 
By looking at the stacktrace, it looks like a checkpoint operation is aborted 
due to some inconsistency in the internal data structure. If the error does not 
repeat immediately, does it mean that the next checkpoint is successful and 
there is no data loss? 

I can't provide a test case for that, the error happens after about 1-2 day of 
running our software. I will rerun the test with the debug jars to capture the 
line numbers in the stacktrace.  Also, I'm starting another test with 10.2.2.0, 
to see if this problem was introduced in the latest version.

There are another two bugs referring to this error, 
(https://issues.apache.org/jira/browse/DERBY-2284 and 
https://issues.apache.org/jira/browse/DERBY-3087) but they seem to happen in 
response to some client action. This use case is a bit different, the client 
keeps inserting and updating records for several days in a steady manner and at 
some point the error pops up.


And lastly, here is the exception:


Checkpoint Daemon caught standard exception

  BEGIN ERROR STACK -

ERROR XSDB3: Container information cannot change once written: was 0, now 80
at org.apache.derby.iapi.error.StandardException.newException(Unknown 
Source)
at 
org.apache.derby.impl.store.raw.data.AllocPage.WriteContainerInfo(Unknown 
Source)
at 
org.apache.derby.impl.store.raw.data.FileContainer.writeHeader(Unknown Source)
at 
org.apache.derby.impl.store.raw.data.RAFContainer.writeRAFHeader(Unknown Source)
at org.apache.derby.impl.store.raw.data.RAFContainer.clean(Unknown 
Source)
at org.apache.derby.impl.services.cache.CachedItem.clean(Unknown Source)
at org.apache.derby.impl.services.cache.Clock.cleanCache(Unknown Source)
at org.apache.derby.impl.services.cache.Clock.cleanAll(Unknown Source)
at 
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.checkpoint(Unknown 
Source)
at 
org.apache.derby.impl.store.raw.log.LogToFile.checkpointWithTran(Unknown Source)
at org.apache.derby.impl.store.raw.log.LogToFile.checkpoint(Unknown 
Source)
at org.apache.derby.impl.store.raw.RawStore.checkpoint(Unknown Source)
at org.apache.derby.impl.store.raw.log.LogToFile.performWork(Unknown 
Source)
at 
org.apache.derby.impl.services.daemon.BasicDaemon.serviceClient(Unknown Source)
at org.apache.derby.impl.services.daemon.BasicDaemon.work(Unknown 
Source)
at org.apache.derby.impl.services.daemon.BasicDaemon.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)


  END ERROR STACK -



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DERBY-3348) Small typo in table functions documentation. Should have EmployeeTable not EmployeesTable

2008-01-23 Thread Kathey Marsden (JIRA)

Small typo in table functions documentation. Should have EmployeeTable not 
EmployeesTable 
--

 Key: DERBY-3348
 URL: https://issues.apache.org/jira/browse/DERBY-3348
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.4.0.0
Reporter: Kathey Marsden
Priority: Trivial


I tried the table function example at:
http://db.apache.org/derby/docs/dev/devguide/cdevspecialtfbasic.html

There is small typo that the create function example. It uses EmployeesTable 
instead of EmployeeTable to match the code example.  I also am not sure if 
using com.acme is ok.

CREATE FUNCTION externalEmployees
()
RETURNS TABLE
(
  employeeIdINT,
  lastName  VARCHAR( 50 ),
  firstName VARCHAR( 50 ),
  birthday  DATE
)
LANGUAGE JAVA
PARAMETER STYLE DERBY_JDBC_RESULT_SET
NO SQL
EXTERNAL NAME 'com.acme.hrSchema.EmployeesTable.read'

Should be 
EXTERNAL NAME 'com.acme.hrSchema.EmployeeTable.read'

to match code example at
http://db.apache.org/derby/docs/dev/devguide/cdevspecialtfexample.html


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

New java doc warnings

2008-01-23 Thread Manjula Kutty

I'm getting these new jabva doc warnings continuously for 2 days. Can any
one please have a look?


Docs:

Failed with following errors. Check details in docs.txt

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\sql\conn\LanguageConnectionContext.java:1058:
warning - @param argument activation is not a parameter name.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\sql\conn\LanguageConnectionContext.java:1067:
warning - @param argument activation is not a parameter name.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\sql\Activation.java:596:
warning - @arg is an unknown tag.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\iapi\sql\Activation.java:613:
warning - @arg is an unknown tag.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\impl\sql\conn\GenericLanguageConnectionContext.java:3113:
warning - @param argument activation is not a parameter name.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\impl\sql\conn\GenericLanguageConnectionContext.java:3133:
warning - @param argument activation is not a parameter name.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\impl\sql\execute\BaseActivation.java:1349:
warning - @arg is an unknown tag.

[javadoc]
C:\nightlies\main\src\opensource\java\engine\org\apache\derby\impl\sql\execute\BaseActivation.java:1370:
warning - @arg is an unknown tag.

-- 
Thanks,
Manjula.

[jira] Commented: (DERBY-3346) DatabaseMetaData.getIndexInfo returns the wrong nullabilty for column 4 NON_UNIQUE