date:20080318


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

V.Narayanan commented on DERBY-3533:


Thank you Jorgen, for summarizing the issue, suggesting a crisp explanation of 
the possible solution,
code pointers to places from were code can be reused for this issue and issues 
that you think would 
form a highlight in this implementation.

The series of steps (outlined above in the comments by Jorgen) if followed 
before replication startup 
on the master (done as a system procedure) will help to take care of the all 
the logged operations except 
jar file operations. 

I believe there is no issue with the index and the import operations, and that 
enabling logging
for the unlogged operations will solve the problem encountered in these cases. 
* I however did not
find much literature on the nature of the logs for these operations and would 
appreciate any inputs
from the community here.*


Jar Files
-

With regards to Jar files

* The installed jar files are not logged but system catalog updates are logged
  when jar files are added/deleted.
* This would mean that allowing jar file operations during deletion would result
  in the system catalog table on the slave having a reference to the jar file 
that
  does not exist in the backup database

solution


* Block jar file operations when backup is in progress
* write clear documentation stating that the jar files will have to be
  manually copied to the slave.

I intend to bifurcate this issue into two JIRA's

1) Handle logging of unlogged operations
2) Handle installed jar files during replication

 Replication fails when unlogged operations are used
 ---

 Key: DERBY-3533
 URL: https://issues.apache.org/jira/browse/DERBY-3533
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: Øystein Grøvlen
Assignee: V.Narayanan

 I created an index while replication was running, and the slave seems to have 
 failed at that time.  Below is excerpts from derby.log on the slave.  The 
 container id referred to, matches the id of the index on the master.
   BEGIN SHUTDOWN ERROR STACK -
   BEGIN REPLICATION ERROR MESSAGE (3/11/08 2:32 PM) 
 ERROR XSLA7: Cannot redo operation Page Operation: Page(349,Container(0, 
 1041)) pageVersion 180 : Insert :  Slot=177 recordId=183 in the log.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
   at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
   at 
 org.apache.derby.impl.store.access.RAMAccessManager.boot(RAMAccessManager.java:1019)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
   at 
 org.apache.derby.impl.db.BasicDatabase.bootStore(BasicDatabase.java:789)
   at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:205)
   at 
 org.apache.derby.impl.db.SlaveDatabase.bootBasicDatabase(SlaveDatabase.java:421)
   at 
 org.apache.derby.impl.db.SlaveDatabase.access$000(SlaveDatabase.java:70)
   at 
 org.apache.derby.impl.db.SlaveDatabase$SlaveDatabaseBootThread.run(SlaveDatabase.java:308)
   at java.lang.Thread.run(Thread.java:619)
 Caused by: ERROR XSDG0: Page Page(349,Container(0, 1041)) could not be read 
 from disk.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:336)
   at 
 org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:688)
   at 
 org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190)
   at 
 org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:288)
   at 
 org.apache.derby.impl.store.raw.data.FileContainer.getAnyPage(FileContainer.java:2493)
   at 
 org.apache.derby.impl.store.raw.data.BaseContainer.getAnyPage(BaseContainer.java:496)

[jira] Issue Comment Edited: (DERBY-3533) Replication fails when unlogged operations are used


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

narayanan edited comment on DERBY-3533 at 3/18/08 3:23 AM:
-

Thank you Jorgen, for summarizing the issue, suggesting a crisp explanation of 
the possible solution,
code pointers to places from were code can be reused for this issue and issues 
that you think would 
form a highlight in this implementation.

The series of steps (outlined above in the comments by Jorgen) if followed 
before replication startup 
on the master (done as a system procedure) will help to take care of the all 
the logged operations except 
jar file operations. 

I believe there is no issue with the index and the import operations, and that 
enabling logging
for the unlogged operations will solve the problem encountered in these cases. 
* I however did not
find much literature on the nature of the logs for these operations and would 
appreciate any inputs
from the community here.*


Jar Files
-

With regards to Jar files

* The installed jar files are not logged but system catalog updates are logged
  when jar files are added/deleted.
* This would mean that allowing jar file operations during deletion would result
  in the system catalog table on the slave having a reference to the jar file 
that
  does not exist in the backup database

solution


* Block jar file operations when backup is in progress
* write clear documentation stating that the jar files will have to be
  manually copied to the slave.

I intend to bifurcate this issue into two JIRA's

1) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION() 
2) Handle installed jar files during replication

  was (Author: narayanan):
Thank you Jorgen, for summarizing the issue, suggesting a crisp explanation 
of the possible solution,
code pointers to places from were code can be reused for this issue and issues 
that you think would 
form a highlight in this implementation.

The series of steps (outlined above in the comments by Jorgen) if followed 
before replication startup 
on the master (done as a system procedure) will help to take care of the all 
the logged operations except 
jar file operations. 

I believe there is no issue with the index and the import operations, and that 
enabling logging
for the unlogged operations will solve the problem encountered in these cases. 
* I however did not
find much literature on the nature of the logs for these operations and would 
appreciate any inputs
from the community here.*


Jar Files
-

With regards to Jar files

* The installed jar files are not logged but system catalog updates are logged
  when jar files are added/deleted.
* This would mean that allowing jar file operations during deletion would result
  in the system catalog table on the slave having a reference to the jar file 
that
  does not exist in the backup database

solution


* Block jar file operations when backup is in progress
* write clear documentation stating that the jar files will have to be
  manually copied to the slave.

I intend to bifurcate this issue into two JIRA's

1) Handle logging of unlogged operations
2) Handle installed jar files during replication
  
 Replication fails when unlogged operations are used
 ---

 Key: DERBY-3533
 URL: https://issues.apache.org/jira/browse/DERBY-3533
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: Øystein Grøvlen
Assignee: V.Narayanan

 I created an index while replication was running, and the slave seems to have 
 failed at that time.  Below is excerpts from derby.log on the slave.  The 
 container id referred to, matches the id of the index on the master.
   BEGIN SHUTDOWN ERROR STACK -
   BEGIN REPLICATION ERROR MESSAGE (3/11/08 2:32 PM) 
 ERROR XSLA7: Cannot redo operation Page Operation: Page(349,Container(0, 
 1041)) pageVersion 180 : Insert :  Slot=177 recordId=183 in the log.
   at 
 org.apache.derby.iapi.error.StandardException.newException(StandardException.java:296)
   at 
 org.apache.derby.impl.store.raw.log.FileLogger.redo(FileLogger.java:1525)
   at 
 org.apache.derby.impl.store.raw.log.LogToFile.recover(LogToFile.java:920)
   at org.apache.derby.impl.store.raw.RawStore.boot(RawStore.java:334)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1999)
   at 
 org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:553)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
   at

[jira] Created: (DERBY-3551) Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()

Implement procedure SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()
--

 Key: DERBY-3551
 URL: https://issues.apache.org/jira/browse/DERBY-3551
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: V.Narayanan


Jorgen says-

I suggest that the replication step in which the master database is frozen is 
replaced by a new system procedure to solve index and import:

Old: SYSCS_UTIL.SYSCS_FREEZE_DATABASE()
New: SYSCS_UTIL.SYSCS_PREPARE_REPLICATION()

The new system procedure should:
1) Freeze the database
2) Check if there are any ongoing transactions with unlogged operations. If so 
- unfreeze and abort. Otherwise:
3) Enable logging of unlogged operations 

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

[jira] Created: (DERBY-3552) Handle jar files that are installed when replication is enabled

Handle jar files that are installed when replication is enabled
---

 Key: DERBY-3552
 URL: https://issues.apache.org/jira/browse/DERBY-3552
 Project: Derby
  Issue Type: Sub-task
Reporter: V.Narayanan




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

[jira] Updated: (DERBY-3552) Handle jar files that are installed when replication is enabled


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

V.Narayanan updated DERBY-3552:
---

  Component/s: Replication
Affects Version/s: 10.5.0.0
   10.4.0.0

 Handle jar files that are installed when replication is enabled
 ---

 Key: DERBY-3552
 URL: https://issues.apache.org/jira/browse/DERBY-3552
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: V.Narayanan



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

[jira] Commented: (DERBY-3552) Handle jar files that are installed when replication is enabled


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

V.Narayanan commented on DERBY-3552:


Jar Files
-

With regards to Jar files

* The installed jar files are not logged but system catalog updates are logged
  when jar files are added/deleted.
* This would mean that allowing jar file operations during deletion would result
  in the system catalog table on the slave having a reference to the jar file 
that
  does not exist in the backup database

Possible solution


* Block jar file operations when backup is in progress
* write clear documentation stating that the jar files will have to be
  manually copied to the slave.

 Handle jar files that are installed when replication is enabled
 ---

 Key: DERBY-3552
 URL: https://issues.apache.org/jira/browse/DERBY-3552
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: V.Narayanan



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

[jira] Updated: (DERBY-3162) Create a framework for replication tests


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

Ole Solberg updated DERBY-3162:
---

Derby Info: [Patch Available]

 Create a framework for replication tests
 

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

 Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, 
 derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, 
 derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, 
 derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, 
 derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, 
 derby-3162.3-v4d.stat.txt, derby-3162.4-v3.diff.txt, 
 derby-3162.4-v3.stat.txt, derby-3162.5-v1.diff.txt, derby-3162.5-v1.stat.txt, 
 derby-3162.6_v1.diff.txt, derby-3162.6_v1.stat.txt


 Handle
  - starting and stopping Derby servers to have the master and slave 
 replication roles,
  - doing administrative commands like startreplication, startslave, 
 stopreplication, failover,
  - performing consistency checks on the slave vs. the master,
  - running load clients against master and slave in the various states of 
 replication,
  - provoking error situations on master and slave, and network,
  - ... 

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

[jira] Updated: (DERBY-3162) Create a framework for replication tests


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

Ole Solberg updated DERBY-3162:
---

Attachment: derby-3162.6_v1.stat.txt
derby-3162.6_v1.diff.txt

Patch 3162.6-v1 for replicationtests:

Fix to allow ReplicationSuite to run on JVM 1.4 and 1.5:

The replicationTest framework (ReplicationRun) used 
Drivermanager.getConnection() 
to do startMaster=true and startSlave=true concurrently.
On 1.5 (and 1.4), but not on 1.6, it turned out that this caused a deadlock (on 
DriverManager.class?).

Using DataSource instead of DriverManager solved the problem.

Big thanks to Kristian Waagan who helped analyzing this!



The patch has been tested on
Linux:   jars: 1.4, 1.5, 1.6. classes: 1.4, 1.5, 1.6
Solaris: jars: 1.4, 1.5, 1.6
Windows: jars: 1.4, 1.5, 1.6


 Create a framework for replication tests
 

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

 Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, 
 derby-3162.2-v2.stat.txt, derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, 
 derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt, derby-3162.3-v3.diff.txt, 
 derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, 
 derby-3162.3-v4c.stat.txt, derby-3162.3-v4d.diff.txt, 
 derby-3162.3-v4d.stat.txt, derby-3162.4-v3.diff.txt, 
 derby-3162.4-v3.stat.txt, derby-3162.5-v1.diff.txt, derby-3162.5-v1.stat.txt, 
 derby-3162.6_v1.diff.txt, derby-3162.6_v1.stat.txt


 Handle
  - starting and stopping Derby servers to have the master and slave 
 replication roles,
  - doing administrative commands like startreplication, startslave, 
 stopreplication, failover,
  - performing consistency checks on the slave vs. the master,
  - running load clients against master and slave in the various states of 
 replication,
  - provoking error situations on master and slave, and network,
  - ... 

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

[jira] Created: (DERBY-3553) Write tests for unlogged operations when replication is enabled

Write tests for unlogged operations when replication is enabled
---

 Key: DERBY-3553
 URL: https://issues.apache.org/jira/browse/DERBY-3553
 Project: Derby
  Issue Type: Sub-task
Reporter: V.Narayanan




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

[jira] Updated: (DERBY-3553) Write tests for unlogged operations when replication is enabled


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

V.Narayanan updated DERBY-3553:
---

  Component/s: Replication
Affects Version/s: 10.5.0.0
   10.4.0.0

 Write tests for unlogged operations when replication is enabled
 ---

 Key: DERBY-3553
 URL: https://issues.apache.org/jira/browse/DERBY-3553
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: V.Narayanan



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

[jira] Commented: (DERBY-3553) Write tests for unlogged operations when replication is enabled


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

V.Narayanan commented on DERBY-3553:


I feel extensive tests can be written to test for the various unlogged 
operations
in the context of replication and that this has scope to be done in a seperate 
issue.

 Write tests for unlogged operations when replication is enabled
 ---

 Key: DERBY-3553
 URL: https://issues.apache.org/jira/browse/DERBY-3553
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: V.Narayanan



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

[jira] Commented: (DERBY-3550) The Reference guide says that you can create your own user-defined aggregates, but Derby does not have this capability.

2008-03-18 Thread Rick Hillegas (JIRA)


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

Rick Hillegas commented on DERBY-3550:
--

Thanks, Kim. Looks good to me. Committed at subversion revision 638353.

 The Reference guide says that you can create your own user-defined 
 aggregates, but Derby does not have this capability.
 ---

 Key: DERBY-3550
 URL: https://issues.apache.org/jira/browse/DERBY-3550
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.4.1.0

 Attachments: DERBY-3550.diff, rrefsqlj33923.html


 The Aggregates (set functions) section of the Reference Guide says You can 
 also create your own aggregates to perform other set functions such as 
 calculating the standard deviation. This is not true. See DERBY-672. This 
 sentence confuses users. See the following email thread: 
 http://www.nabble.com/STDDEV-for-Derby-td16038184.html#a16038184

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

[jira] Updated: (DERBY-3529) ReplicationSuite.ReplicationRun_Local_StateTest_part1_1._testPostStartedMasterAndSlave_StopMaster() fails on stopslave after master shutdown on Windows


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

Ole Solberg updated DERBY-3529:
---

Description: 
- startslave and startmaster done, i.e. master and slave in replication mode.
- stopslave on slave - fails w/XRE41 - OK
- stopslave on master - fails w/XRE40 - OK
(i.e. slave and master still in repl. mode)
- shutdown on master server.
- stopslave on slave - fails w/XRE11(db not booted)  expected XRE42(slave 
shutdown ok)

ReplicationRun_Local_StateTest_part1_1._testPostStartedMasterAndSlave_StopMaster():
.
.
3. testPostStartedMasterAndSlave_StopSlave: 
jdbc:derby://localhost:4527/C:\cludev\jagtmp\os136789derbyJunitTest\derbyJunitTest_0\log\db_slave\wombat;stopSlave=true
3. Got -1 XRE11 DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE11, SQLERRMC: 
stopSlave 
C:\cludev\jagtmp\os136789derbyJunitTest\derbyJunitTest_0\log\db_slave\wombat 
XRE11 Expected: XRE42





  was:
- startslave and startmaster done, i.e. master and slave in replication mode.
- stopslave on slave - fails w/XRE41 - OK
- stopslave on master - fails w/XRE40 - OK
(i.e. slave and master still in repl. mode)
- shutdown on master server.
- stopslave on slave - fails w/XRE11(db not booted)  expected XRE42(slave 
shutdown ok)

ReplicationRun_Local_StateTest_part1_2._testPostStartedMasterAndSlave_StopMaster():
.
.
3. testPostStartedMasterAndSlave_StopSlave: 
jdbc:derby://localhost:4527/C:\cludev\jagtmp\os136789derbyJunitTest\derbyJunitTest_0\log\db_slave\wombat;stopSlave=true
3. Got -1 XRE11 DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE11, SQLERRMC: 
stopSlave 
C:\cludev\jagtmp\os136789derbyJunitTest\derbyJunitTest_0\log\db_slave\wombat 
XRE11 Expected: XRE42





Summary: 
ReplicationSuite.ReplicationRun_Local_StateTest_part1_1._testPostStartedMasterAndSlave_StopMaster()
 fails on stopslave after master shutdown on Windows  (was: 
ReplicationSuite.ReplicationRun_Local_StateTest_part1_2._testPostStartedMasterAndSlave_StopMaster()
 fails on stopslave after master shutdown on Windows)

 ReplicationSuite.ReplicationRun_Local_StateTest_part1_1._testPostStartedMasterAndSlave_StopMaster()
  fails on stopslave after master shutdown on Windows
 ---

 Key: DERBY-3529
 URL: https://issues.apache.org/jira/browse/DERBY-3529
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
 Environment: Windows 2003
 JVM 1.6 Sun Microsystems
Reporter: Ole Solberg

 - startslave and startmaster done, i.e. master and slave in replication mode.
 - stopslave on slave - fails w/XRE41 - OK
 - stopslave on master - fails w/XRE40 - OK
 (i.e. slave and master still in repl. mode)
 - shutdown on master server.
 - stopslave on slave - fails w/XRE11(db not booted)  expected XRE42(slave 
 shutdown ok)
 ReplicationRun_Local_StateTest_part1_1._testPostStartedMasterAndSlave_StopMaster():
 .
 .
 3. testPostStartedMasterAndSlave_StopSlave: 
 jdbc:derby://localhost:4527/C:\cludev\jagtmp\os136789derbyJunitTest\derbyJunitTest_0\log\db_slave\wombat;stopSlave=true
 3. Got -1 XRE11 DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE11, SQLERRMC: 
 stopSlave 
 C:\cludev\jagtmp\os136789derbyJunitTest\derbyJunitTest_0\log\db_slave\wombat 
 XRE11 Expected: XRE42

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

[jira] Resolved: (DERBY-3528) ReplicationSuite tests hang when running on jvm 1.5, jvm 1.4


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

Ole Solberg resolved DERBY-3528.


Resolution: Fixed

Fixed by DERBY-3162 /  patch erby-3162.6_v1.

 ReplicationSuite tests hang when running on jvm 1.5, jvm 1.4
 

 Key: DERBY-3528
 URL: https://issues.apache.org/jira/browse/DERBY-3528
 Project: Derby
  Issue Type: Bug
  Components: Replication, Test
Affects Versions: 10.4.0.0, 10.5.0.0
 Environment: jvm 1.5, jvm 1.4 Sun Microsystems
Reporter: Ole Solberg
Assignee: Ole Solberg

 Master derby.log:
 .
 .
 Database Class Loader started - derby.database.classpath=''
 Slave derby.log:
 .
 .
 Replication slave database 
 '/export/home/tmp/jagtmp/os136789derbyJunitTest/derbyJunitTest_0/log/db_slave/wombat'
  listens for connections from master on 'localhost:'.
 startMaster does not complete?

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

[jira] Resolved: (DERBY-3550) The Reference guide says that you can create your own user-defined aggregates, but Derby does not have this capability.

2008-03-18 Thread Rick Hillegas (JIRA)


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

Rick Hillegas resolved DERBY-3550.
--

Resolution: Fixed

 The Reference guide says that you can create your own user-defined 
 aggregates, but Derby does not have this capability.
 ---

 Key: DERBY-3550
 URL: https://issues.apache.org/jira/browse/DERBY-3550
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.4.1.0

 Attachments: DERBY-3550.diff, rrefsqlj33923.html


 The Aggregates (set functions) section of the Reference Guide says You can 
 also create your own aggregates to perform other set functions such as 
 calculating the standard deviation. This is not true. See DERBY-672. This 
 sentence confuses users. See the following email thread: 
 http://www.nabble.com/STDDEV-for-Derby-td16038184.html#a16038184

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

[jira] Commented: (DERBY-3550) The Reference guide says that you can create your own user-defined aggregates, but Derby does not have this capability.

2008-03-18 Thread Rick Hillegas (JIRA)


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

Rick Hillegas commented on DERBY-3550:
--

Ported 638353 from docs trunk to 10.4 docs branch at subversion revision 638354.

 The Reference guide says that you can create your own user-defined 
 aggregates, but Derby does not have this capability.
 ---

 Key: DERBY-3550
 URL: https://issues.apache.org/jira/browse/DERBY-3550
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.4.1.0

 Attachments: DERBY-3550.diff, rrefsqlj33923.html


 The Aggregates (set functions) section of the Reference Guide says You can 
 also create your own aggregates to perform other set functions such as 
 calculating the standard deviation. This is not true. See DERBY-672. This 
 sentence confuses users. See the following email thread: 
 http://www.nabble.com/STDDEV-for-Derby-td16038184.html#a16038184

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

Re: Impending release branch cut; how to mask unifinished roles feature

2008-03-18 Thread fp

I get a little bit confused about the SQL Role Feature.
Is it part of the 10.4.1 Release as stated on
http://wiki.apache.org/db-derby/DerbyTenFourRelease
or not as in the RELEASE-NOTES of the 10.4.1.0 beta - (637204M).

When i set the property -Dderby.database.sqlAuthorization=true and execute
create role
I get an error 42Z60: CREATE ROLE not allowed unless database property
derby.database.sq
lAuthorization has value 'TRUE'.
But the Table select * from sys.sysroles; ist there.
What's the status quo with SQL ROLES?

Dag H. Wanvik wrote:

Daniel John Debrunner [EMAIL PROTECTED] writes:

It is possible to provide a quick summary of what the current state is
(what works and what doesn't)?

Sure.

Works:

- Parsing, binding and constant actions for all specified new syntax
works (see spec.html attached to DERBY-2207), including persisting
and accessing role dictionary information, basic checks and
dictionary soft/hard upgrade behavior. Thus, permissions can be
granted and revoked to/from roles, but currently such permissions
are not activated when permissions are checked. The relaxing of role
name length and SYS prefix reservation is checked in.

- Tests for the above: RolesTest, two new Changes10_4 fixtures.

- ij show roles command

Patches available (not committed yet):

- SQL session context implementation (DERBY-3327) (routine stack
behavior for current roles, schema).
Also solves DERBY-1331. Not sure if I should commit this before
branch cut; changing default schema semantics and implementation
may be risky. Running some performance checks on schema part of
this patch now.

- Additional checks for PUBLIC keyword (DERBY-).

Sandbox stage yet (partly implemented, partly works):

- making use of permissions through roles, including
in roles in role grant closure
- registering dependencies on roles for persistent objects
(views, constraints, triggers) and prepared
statements/activations
- invalidation actions when roles are dropped, role grants revoked, and
current role changes.

Not yet started:

- best effort attempt to check that new role does not overlap with a
user name, cf. spec section 6.1.
- memory caching of roles descriptors for performance
- user documentation

Dag

--
View this message in context:
http://www.nabble.com/Impending-release-branch-cut--how-to-mask-unifinished-roles-feature-tp15627783p16121336.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

[jira] Commented: (DERBY-3527) The slave will not notice that a network cable is unplugged and will therefore reject failover/stopSlave commands

2008-03-18 Thread JIRA


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

Jørgen Løland commented on DERBY-3527:
--

All tests passed except testStartStopManagementFromApplication, which has also 
been reported in tinderbox.

 The slave will not notice that a network cable is unplugged and will 
 therefore reject failover/stopSlave commands
 -

 Key: DERBY-3527
 URL: https://issues.apache.org/jira/browse/DERBY-3527
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.4.0.0, 10.5.0.0
Reporter: Jørgen Løland
Assignee: Jørgen Løland
 Attachments: derby-3527-1a.diff, derby-3527-1a.stat


 If a network cable between the master and slave is unplugged (or a switch 
 crashes etc), ObjectInputStream#readObject will not get an exception. Neither 
 the socket nor the input stream can be queried for information on whether or 
 not the connection is working. AFAIK, the only way to find out if the network 
 is down is to send a message.
 The slave commands stopSlave and failover are rejected if the network 
 connection is working. To be absolutely sure that the connection is working, 
 we need to ping the master when these commands are requested.

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

Re: Impending release branch cut; how to mask unifinished roles feature

2008-03-18 Thread Rick Hillegas


Hi Frank,

Thanks for wanting to test-drive this feature. The Roles work has been 
postponed to the next feature release. The DerbyTenFourRelease wiki page 
says that the Roles work is postponed, but that indication is easy to 
miss because it's in the far right column of the table of features.


Hope this helps,
-Rick

fp wrote:
I get a little bit confused about the SQL Role Feature. 
Is it part of the 10.4.1 Release as stated on

http://wiki.apache.org/db-derby/DerbyTenFourRelease
or not as in the RELEASE-NOTES of the  10.4.1.0 beta - (637204M).

When i set the property -Dderby.database.sqlAuthorization=true and execute
create role
I get an error 42Z60: CREATE ROLE not allowed unless database property
derby.database.sq
lAuthorization has value 'TRUE'.
But the Table select * from sys.sysroles; ist there.
What's the status quo with SQL ROLES?


Dag H. Wanvik wrote:
  
Daniel John Debrunner [EMAIL PROTECTED] writes: 



It is possible to provide a quick summary of what the current state is
(what works and what doesn't)?
  

Sure.

Works:

- Parsing, binding and constant actions for all specified new syntax
  works (see spec.html attached to DERBY-2207), including persisting
  and accessing role dictionary information, basic checks and
  dictionary soft/hard upgrade behavior.  Thus, permissions can be
  granted and revoked to/from roles, but currently such permissions
  are not activated when permissions are checked. The relaxing of role
  name length and SYS prefix reservation is checked in.

- Tests for the above: RolesTest, two new Changes10_4 fixtures.

- ij show roles command

Patches available (not committed yet):

 - SQL session context implementation (DERBY-3327) (routine stack
   behavior for current roles, schema).
   Also solves DERBY-1331. Not sure if I should commit this before
   branch cut; changing default schema semantics and implementation
   may be risky. Running some performance checks on schema part of
   this patch now.

-  Additional checks for PUBLIC keyword (DERBY-).

Sandbox stage yet (partly implemented, partly works):

 - making use of permissions through roles, including
   in roles in role grant closure
 - registering dependencies on roles for persistent objects
   (views, constraints, triggers) and prepared
   statements/activations
 - invalidation actions when roles are dropped, role grants revoked, and
   current role changes.

Not yet started:

 - best effort attempt to check that new role does not overlap with a
   user name, cf. spec section  6.1.
 - memory caching of roles descriptors for performance
 - user documentation

Dag

[jira] Commented: (DERBY-3550) The Reference guide says that you can create your own user-defined aggregates, but Derby does not have this capability.


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

Kim Haase commented on DERBY-3550:
--

Thanks very much, Rick.

 The Reference guide says that you can create your own user-defined 
 aggregates, but Derby does not have this capability.
 ---

 Key: DERBY-3550
 URL: https://issues.apache.org/jira/browse/DERBY-3550
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Reporter: Rick Hillegas
Assignee: Kim Haase
 Fix For: 10.4.1.0

 Attachments: DERBY-3550.diff, rrefsqlj33923.html


 The Aggregates (set functions) section of the Reference Guide says You can 
 also create your own aggregates to perform other set functions such as 
 calculating the standard deviation. This is not true. See DERBY-672. This 
 sentence confuses users. See the following email thread: 
 http://www.nabble.com/STDDEV-for-Derby-td16038184.html#a16038184

-- 
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-03-18 Thread jira

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


Key Summary
DERBY-3527  The slave will not notice that a network cable is unplugged and 
will therefore reject failover/stopSlave commands
https://issues.apache.org/jira/browse/DERBY-3527
DERBY-3162  Create a framework for replication tests
https://issues.apache.org/jira/browse/DERBY-3162
DERBY-3169  Add documentation for replication
https://issues.apache.org/jira/browse/DERBY-3169
DERBY-3447  Shutdown on a database without stopping replication hangs
https://issues.apache.org/jira/browse/DERBY-3447
DERBY-3379  No Current connection on PooledConnection.getConnection() if 
pooled connection is reused during connectionClosed processing
https://issues.apache.org/jira/browse/DERBY-3379
DERBY-3542  New ROW_NUMBER function topic needs a few minor fixes
https://issues.apache.org/jira/browse/DERBY-3542
DERBY-3474  update unique constraint sections of refrence manual
https://issues.apache.org/jira/browse/DERBY-3474
DERBY-3445  Make it easier to use the EMMA tool to measure the code coverage of 
the Derby testing
https://issues.apache.org/jira/browse/DERBY-3445
DERBY-3382  Replication: Slave must inform master if DBs are out of sync.
https://issues.apache.org/jira/browse/DERBY-3382
DERBY-3310  ASSERT in MergeSort.checkColumnTypes() disallow legal type 
conversions
https://issues.apache.org/jira/browse/DERBY-3310
DERBY-3494  Move the setup of NormalizeResultSetNode into the 
NormalizeResultSetNode
https://issues.apache.org/jira/browse/DERBY-3494
DERBY-3460  SQL roles: patch to mask off roles on 10.4 release branch
https://issues.apache.org/jira/browse/DERBY-3460
DERBY-3327  SQL roles: Implement authorization stack (and SQL session context 
to hold it)
https://issues.apache.org/jira/browse/DERBY-3327
DERBY-2871  XATransactionTest gets XaException: Error executing a 
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3409  Remove JDBC 2.0-specific topics from Reference Manual and merge 
implementation notes as needed
https://issues.apache.org/jira/browse/DERBY-3409
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-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

Re: Impending release branch cut; how to mask unifinished roles feature

2008-03-18 Thread Dyre Tjeldvoll


Rick Hillegas wrote:

Hi Frank,

Thanks for wanting to test-drive this feature. The Roles work has been 
postponed to the next feature release. The DerbyTenFourRelease wiki page 
says that the Roles work is postponed, but that indication is easy to 
miss because it's in the far right column of the table of features.


Also note that the patch that will disable the parts that do not yet 
work, has not been applied to the 10.4 branch.


Dyre

[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

2008-03-18 Thread Mamta A. Satoor (JIRA)


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

Mamta A. Satoor commented on DERBY-3320:


I spent some time on this jira entry and found that we get the Locale and 
Collator for the database even before we know that we are dealing with a 
territory based database. This happens in DataValueFactoryImpl.setLocale which 
gets called by BasicDatabase.boot(). The reason we do this setting before the 
store module and data dictionary module boots up is so that Collator info is 
available to store if needs to do recovery. I am trying to tackle the problem 
first for database create time only(will address subsequent boot times later 
on). I will try to see if I can find the request for territory based database 
during DataValueFactory module bootup so we can see if Collator is really 
supported or not for the given locale.

 Database creation and boot should fail if collation=TERRITORY_BASED and the 
 selected locale is not supported
 

 Key: DERBY-3320
 URL: https://issues.apache.org/jira/browse/DERBY-3320
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.4.0.0
 Environment: Java ME:
 Product: phoneME Advanced (phoneme_advanced_mr2-b34)
 Profile: Foundation Profile Specification 1.1
 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 
 GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
 Attachments: DERBY_3320_Repro.java


 A problem I've discovered when testing with the phoneME advanced platform is 
 that the collationtests expect other locales than Locale.US to be available 
 on the platform that is used for the test, and for phoneME advanced (when 
 compiled as foundation profile) only Locale.US is available. From the jdk1.6 
 javadoc of Collator.getAvailableLocales() I see that only Locale.US is 
 strictly required:
 public static Locale[] getAvailableLocales()
 Returns an array of all locales for which the getInstance methods of this 
 class can return localized instances. The returned array represents the union 
 of locales supported by the Java runtime and by installed CollatorProvider 
 implementations. It must contain at least a Locale instance equal to 
 Locale.US.
 Returns:
 An array of locales for which localized Collator instances are 
 available.
 This led me to thinking about how Derby should behave if created/booted with 
 collation=TERRITORY_BASED and territory=some unsupported locale. I'm not 
 sure what the consequences could be if the database is first created on a 
 platform that supports whatever locale is set and later booted with one that 
 doesn't, or created on a platform missing support and later booted with one 
 that has. In any case I think it may confuse a user needlessly to see the 
 database boot successfully with his collation setting and later behave in a 
 way he does not expect.
 Opinions voiced on the derby-dev list are that both database creation and 
 boot should fail if collation=TERRITORY_BASED and the selected locale is not 
 supported.
 If a change like this is implemented, the collationtests should be changed to 
 verify correct behavior also if they are executed in an environment were some 
 of the tested locales are not supported.

-- 
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 637971 - Sun DBTG

2008-03-18 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 637971/2008-03-17 18:01:15 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0274274 083.99% derbyall
F:1,E:01045710456 0   1400.00% suitesAll
 sles
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sol
0274274 077.26% derbyall
F:1,E:01045710456 0   1786.26% suitesAll
 solN+1
0274274 099.63% derbyall
F:1,E:01045710456 0   190.51% suitesAll
 sparc
0274274 066.89% derbyall
F:1,E:01045710456 0   364.28% suitesAll
 vista
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 w2003
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-637971.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/637971_bySig.html 

*Jvm: 1.5*
 lin
0275275 080.96% derbyall
F:1,E:087378736 0   1014.63% suitesAll
 sles
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sol
0275275 080.30% derbyall
F:1,E:087378736 0   862.65% suitesAll
 solN+1
1275274 089.52% derbyall
F:1,E:087378736 0   817.15% suitesAll
 sparc
0275275 068.29% derbyall
F:1,E:087378736 0   711.62% suitesAll
 vista
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 w2003
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-637971.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/637971_bySig.html 

*Jvm: 1.4*
 lin
0272272 281.70% derbyall
085858585 0   911.63% suitesAll
 sles
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sol
0272272 278.02% derbyall
085858585 0   689.78% suitesAll
 solN+1
0272272 289.88% derbyall
085858585 0   756.89% suitesAll
 sparc
0272272 267.66% derbyall
085858585 0   707.69% suitesAll
 vista
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 w2003
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-637971.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/637971_bySig.html 

---

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

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

Re: [Db-derby Wiki] Update of DerbySnapshotOrRelease by DyreTjeldvoll

2008-03-18 Thread Andrew McIntyre

On Tue, Mar 18, 2008 at 7:16 AM, Apache Wiki [EMAIL PROTECTED] wrote:
  +
  +   /!\ '''Is this still necessary?'''
  +
  +   {{{cd tools/release
  + ant bumplastdigit}}}
  +
  +   /!\ '''Commit the changed version number here?'''
  +

I hadn't caught this question earlier in the previous diffs to the
release wiki page.

To answer this question, the process should be:

* update version to reflect proper version for release candidate,
check it in, run svn update, so that the version reported doesn't
contain an 'M' or a range

* build release candidate, RC then reflects a specific revision in Subversion

* bump the last digit, and commit the version again so that any
further changes to the branch are reflected as not being in the RC
version and sysinfo reports a version that is newer than the RC
version.

There is also a question on the page about running maintversion2props,
I'm pretty sure the build.xml in tools/release handles this, no? Dyre,
if you didn't need to run it separately, please remove the mention of
this tool from the page.

Thanks,
andrew

[jira] Updated: (DERBY-3169) Add documentation for replication


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

Kim Haase updated DERBY-3169:
-

Attachment: DERBY-3169-3.stat
DERBY-3169-4.zip
DERBY-3169-4.diff

Here's another version of the docs that includes the new properties for the 
Tuning Guide in addition to the Reference Manual attributes and the Admin Guide 
documentation. Everything is as up to date as I can make it. 

The stat file looks like this:

A  src/adminguide/cadminreplicstop.dita
A  src/adminguide/cadminreplicstartrun.dita
M  src/adminguide/derbyadmin.ditamap
A  src/adminguide/cadminreplicsecurity.dita
A  src/adminguide/cadminreplicfailover.dita
A  src/adminguide/cadminreplicfailures.dita
A  src/adminguide/cadminreplication.dita
A  src/ref/rrefattribstopslave.dita
A  src/ref/rrefattribstartmaster.dita
A  src/ref/rrefattribstartslave.dita
A  src/ref/rrefattribstopmaster.dita
A  src/ref/rrefattribslaveport.dita
M  src/ref/refderby.ditamap
A  src/ref/rrefattribfailover.dita
A  src/ref/rrefattribslavehost.dita
A  src/tuning/rtunproperlogbuffersize.dita
M  src/tuning/ctunproper22250.dita
M  src/tuning/tuningderby.ditamap
A  src/tuning/rtunproperminlogshippinginterval.dita
A  src/tuning/rtunpropermaxlogshippinginterval.dita
A  src/tuning/rtunproperverbose.dita

I should mention that in the Derby properties topic with the table of all the 
properties (ctunproper22250.html) I have taken the liberty of fixing some table 
entries so that empty cells don't show up with an apostrophe in the PDF and 
HTML book files. (I inserted a non-breaking space, nbsp;, into empty 
entries.)

I've seen some JIRA comments on other issues that propose additional things 
that may need to be documented -- like a SYSCS_UTIL.SYSCS_PREPARE_REPLICATION 
procedure, for example. Please let me know when/if further changes are 
necessary.

 Add documentation for replication
 -

 Key: DERBY-3169
 URL: https://issues.apache.org/jira/browse/DERBY-3169
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: Kim Haase
 Attachments: DERBY-3169-2.diff, DERBY-3169-2.stat, DERBY-3169-2.zip, 
 DERBY-3169-3.diff, DERBY-3169-3.stat, DERBY-3169-3.zip, DERBY-3169-4.diff, 
 DERBY-3169-4.zip, DERBY-3169.diff, DERBY-3169.stat, DERBY-3169.zip




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

Regression Test Report - tinderbox_trunk16 638427 - Sun DBTG

2008-03-18 Thread Ole . Solberg

[Auto-generated mail]

*tinderbox_trunk16* 638427/2008-03-18 17:02:18 CET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
  SunOS-5.10_i86pc-i386
0274274 087.35% derbyall
F:1,E:01045710456 0   1182.37% 
org.apache.derbyTesting.functionTests.suites.All
  Details in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-638427.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/638427_bySig.html
 
---

Changes in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/638427.txt 

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

[jira] Updated: (DERBY-2185) Referene manual has conflicting information on when the territory attribute can be specified on the jdbc url.


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

Kim Haase updated DERBY-2185:
-

Priority: Minor  (was: Major)
Assignee: (was: Kim Haase)

I'm unassigning myself from this issue, since we never got answers to the 
question it poses. I'm also downgrading it from major to minor, since it 
doesn't seem to have caused problems for users so far.

If we get enough information to fix the documentation, I'll be happy to pick up 
the issue again.

 Referene manual has conflicting information on when the territory attribute 
 can be specified on the jdbc url.
 -

 Key: DERBY-2185
 URL: https://issues.apache.org/jira/browse/DERBY-2185
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.6
Reporter: Mamta A. Satoor
Priority: Minor

 Derby 10.2 Reference Manual under the section territory=ll_CC says that 
 When creating or upgrading a database, use this attribute to associate a 
 non-default territory with the database. 
 In the same section, under title Combining with other attributes, the 
 manual says that The territory attribute is used only when creating a 
 database. 
 My question is Is the territory attribute really valid during the upgrade?

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

[jira] Updated: (DERBY-3193) SQL roles: Add documentation


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

Kim Haase updated DERBY-3193:
-

Fix Version/s: (was: 10.4.0.0)
   10.5.0.0

It now looks as if SQL Roles will be documented at 10.5, not 10.4.

 SQL roles: Add documentation
 

 Key: DERBY-3193
 URL: https://issues.apache.org/jira/browse/DERBY-3193
 Project: Derby
  Issue Type: New Feature
  Components: Documentation
Reporter: Dag H. Wanvik
Assignee: Kim Haase
 Fix For: 10.5.0.0




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

[jira] Updated: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

2008-03-18 Thread Mamta A. Satoor (JIRA)

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

Mamta A. Satoor updated DERBY-3320:
---

Attachment: DERBY_3320_not_ready_for_commit_stat_v1.txt
DERBY_3320_not_ready_for_commit_diff_v1.txt

Patch DERBY_3320_not_ready_for_commit_diff_v1.txt not ready for commit.

I have added code in DataValueFactoryImpl.setLocale to see if we are dealing
with database create time and if user has asked for territory based database in
JDBC url. If yes, then verify that a Collator object can be instantiated for
the requested locale. If not, then throw an exception.

Notice though that this does not take care of subsequent database boot up time.
A user might boot up a territory based database on a machine that does not have
Collator support for the locale. The reason I could not do the check for
Collator during subsequent boot up time is that at this time of Derby bootup
(ie when we are in DVF.setLocale method), we do not have access to the
information if the database is territory based or not. That information becomes
available after the store has finished booting up. But store bootup happens
after DVF bootup finishes.

We can not wait for store to finish booting up to decide if the Collator
support is available because store during bootup may need to go through the
recovery and at the time of recovery, we need access to Collator object. So,
this is a kind of catch 22 during subsequent database bootup time. We need to
know if the databsase is territory based to see if we need to check Collator
support. But to know if the database is territory based, we need for store to
finish booting up. But store during bootup may require access to Collator if it
needs to recover the db.

A solution could be to always check if the Collator support is available for
the locale of the database, whether or not user has requested territory based
database. This can be done in DVF.setLocale. This approach will be fine IF we
know that there will always be Collator support for the default locale of the
JVM when dealing with the non-territory based databases.

Please ask questions if this store recovery and Collator dependency is not
clear.

Database creation and boot should fail if collation=TERRITORY_BASED and the
selected locale is not supported

Key: DERBY-3320
URL: https://issues.apache.org/jira/browse/DERBY-3320
Project: Derby
Issue Type: Bug
Affects Versions: 10.4.0.0
Environment: Java ME:
Product: phoneME Advanced (phoneme_advanced_mr2-b34)
Profile: Foundation Profile Specification 1.1
Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386
GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt,
DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java

A problem I've discovered when testing with the phoneME advanced platform is
that the collationtests expect other locales than Locale.US to be available
on the platform that is used for the test, and for phoneME advanced (when
compiled as foundation profile) only Locale.US is available. From the jdk1.6
javadoc of Collator.getAvailableLocales() I see that only Locale.US is
strictly required:
public static Locale[] getAvailableLocales()
Returns an array of all locales for which the getInstance methods of this
class can return localized instances. The returned array represents the union
of locales supported by the Java runtime and by installed CollatorProvider
implementations. It must contain at least a Locale instance equal to
Locale.US.
Returns:
An array of locales for which localized Collator instances are
available.
This led me to thinking about how Derby should behave if created/booted with
collation=TERRITORY_BASED and territory=some unsupported locale. I'm not
sure what the consequences could be if the database is first created on a
platform that supports whatever locale is set and later booted with one that
doesn't, or created on a platform missing support and later booted with one
that has. In any case I think it may confuse a user needlessly to see the
database boot successfully with his collation setting and later behave in a
way he does not expect.
Opinions voiced on the derby-dev list are that both database creation and
boot should fail if collation=TERRITORY_BASED and the selected locale is not
supported.
If a change like this is implemented, the collationtests should be changed to
verify correct behavior also if they are executed in an environment were some
of the tested locales are not supported.

--
This message is automatically generated by JIRA.
-

[jira] Commented: (DERBY-3320) Database creation and boot should fail if collation=TERRITORY_BASED and the selected locale is not supported

2008-03-18 Thread Daniel John Debrunner (JIRA)


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

Daniel John Debrunner commented on DERBY-3320:
--

Why not just throw an exception when the collator object is created if the 
locale is not supported?
Then there's no need to figure out if it's boot or create database time.

 Database creation and boot should fail if collation=TERRITORY_BASED and the 
 selected locale is not supported
 

 Key: DERBY-3320
 URL: https://issues.apache.org/jira/browse/DERBY-3320
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.4.0.0
 Environment: Java ME:
 Product: phoneME Advanced (phoneme_advanced_mr2-b34)
 Profile: Foundation Profile Specification 1.1
 Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:14:12 EST 2006 i686 athlon i386 
 GNU/Linux
Reporter: Vemund Østgaard
Assignee: Mamta A. Satoor
 Attachments: DERBY_3320_not_ready_for_commit_diff_v1.txt, 
 DERBY_3320_not_ready_for_commit_stat_v1.txt, DERBY_3320_Repro.java


 A problem I've discovered when testing with the phoneME advanced platform is 
 that the collationtests expect other locales than Locale.US to be available 
 on the platform that is used for the test, and for phoneME advanced (when 
 compiled as foundation profile) only Locale.US is available. From the jdk1.6 
 javadoc of Collator.getAvailableLocales() I see that only Locale.US is 
 strictly required:
 public static Locale[] getAvailableLocales()
 Returns an array of all locales for which the getInstance methods of this 
 class can return localized instances. The returned array represents the union 
 of locales supported by the Java runtime and by installed CollatorProvider 
 implementations. It must contain at least a Locale instance equal to 
 Locale.US.
 Returns:
 An array of locales for which localized Collator instances are 
 available.
 This led me to thinking about how Derby should behave if created/booted with 
 collation=TERRITORY_BASED and territory=some unsupported locale. I'm not 
 sure what the consequences could be if the database is first created on a 
 platform that supports whatever locale is set and later booted with one that 
 doesn't, or created on a platform missing support and later booted with one 
 that has. In any case I think it may confuse a user needlessly to see the 
 database boot successfully with his collation setting and later behave in a 
 way he does not expect.
 Opinions voiced on the derby-dev list are that both database creation and 
 boot should fail if collation=TERRITORY_BASED and the selected locale is not 
 supported.
 If a change like this is implemented, the collationtests should be changed to 
 verify correct behavior also if they are executed in an environment were some 
 of the tested locales are not supported.

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

[jira] Reopened: (DERBY-2720) remove dead code associated with unsupported National Char implementation

2008-03-18 Thread Daniel John Debrunner (JIRA)

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

Daniel John Debrunner reopened DERBY-2720:
--

Some of the code that the national types (incorrectly) used to convert between
datetime values and national characters has not been removed.

E.g. the SQLChar.get{Date,Time.Timestamp}Format methods are not used (I think).
Removing these methods may show other methods not used and may progress to the
date time methods in LocaleFinder being removed.

I'm testing removing the getXXXFormat() methods.

remove dead code associated with unsupported National Char implementation
-

Key: DERBY-2720
URL: https://issues.apache.org/jira/browse/DERBY-2720
Project: Derby
Issue Type: Improvement
Components: SQL
Reporter: Mike Matrigali
Assignee: Mamta A. Satoor
Priority: Minor
Fix For: 10.3.2.2, 10.4.0.0

Derby still has some untested, unused code relating to a non-standard
implementation of a Nationa Char type. The current code can be removed.
I believe the interesting functionality associated with this is now provided
by DERBY-1478 (territory based collation) . If Derby ever implements a
National Char type it should do so differently than the existing code,
collation should not be tied to the National Char type.
I believe a future National char type might have to maintain a separate type
id for compatibility with jdbc interface, but actual implmentation should be
the same code as the char types. Collating of the the national char type
should be supported in exactly same way as regular char types.
If anyone is really intested in the national char code, it's history will
always be available in svn, and a consistent version is available by looking
at 10.0, 10.1,
and 10.2 codelines. I would propose any removal of code only take place in
trunk and not be backported to a released codeline.

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

[jira] Updated: (DERBY-2351) ORDER BY with expression with distinct in the select list returns incorrect result


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

Dyre Tjeldvoll updated DERBY-2351:
--


This issue has fix version 10.4 and is marked with either 'Release note needed' 
or 'Existing application impact', but does not have a releaseNote.html attached 
to it. Should it?

 ORDER BY with expression with distinct in the select list returns incorrect 
 result
 --

 Key: DERBY-2351
 URL: https://issues.apache.org/jira/browse/DERBY-2351
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
 Environment: Any
Reporter: Yip Ng
Assignee: Bryan Pendleton
 Fix For: 10.3.2.2, 10.4.0.0, 10.4.1.0, 10.5.0.0

 Attachments: d2351_aliasing.diff, d2351_aliasing.diff, 
 d2351_aliasing_checkQualifiedName.diff, derby_2351.diff, derby_2351_v2.diff, 
 modifySynonymResults.diff, reproTests.diff


 When distinct is in the select list and the query has order by with 
 expression, the resultset produced contains an additional column.  
 ij create table t1 (c1 int, c2 varchar(10))
 0 rows inserted/updated/deleted
 ij insert into t1 values (1,'a'),(2,'b'),(3,'c');
 3 rows inserted/updated/deleted
 select distinct c1, c2 from t1 order by c1;
 C1 |C2
 --
 1  |a
 2  |b
 3  |c
 3 rows selected
 ij select distinct c1, c2 from t1 order by c1+1;
 C1 |C2|3 =returns 3 
 columns, incorrect result returned
 --
 1  |a |2
 2  |b |3
 3  |c |4
 3 rows selected

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

[jira] Updated: (DERBY-3023) Different result rows depending on the sequence of INNER JOIN and OUTER JOIN


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

Dyre Tjeldvoll updated DERBY-3023:
--


This issue has fix version 10.4 and is marked with either 'Release note needed' 
or 'Existing application impact', but does not have a releaseNote.html attached 
to it. Should it?

 Different result rows depending on the sequence of INNER JOIN and OUTER JOIN
 

 Key: DERBY-3023
 URL: https://issues.apache.org/jira/browse/DERBY-3023
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4
 Environment: Windows XP, Java 1.4.2
Reporter: Stefan Cordes
Assignee: A B
 Fix For: 10.3.2.2, 10.4.0.0

 Attachments: d3023_notTested_v1.patch, d3023_repro.sql, 
 d3023_v2.patch, derby-02-search-joins.zip, derby-02-search-joins2.zip, 
 DerbySearchJoins.java, RUNTIMESTATISTICS-10.3.zip, Statement10.3.1.4 - 
 (561794)-j1.4.2_10.zip


 We have a complex SQL joining 11 Tables via INNER JOIN and OUTER JOIN.
 These SQLs were tested against an z/OS DB2 Version 8.
 After moving to our local platform with Derby we found out the resultsets 
 returned by the SQLs were too less.
 I tested our old style SQL which results in 889 rows.
 Our new style SQL expected to give similar rows but gives *0*.
 After some work we found a workaround: first place all the INNER JOINs in 
 the SQL and then the OUTER JOINs.
 {code:title=Result of testprogram}
 Derby=10.3-b561794
 Test 10.3-b561794-old-style-sql
 889 Rows in 1703ms
 Test 10.3-b561794-new-style-sql
 0 Rows in 563ms  _(expected 924 rows instead)_
 Test 10.3-b561794-new-style-sql-only-inner
 2 Rows in 766ms _(only inner joins, no outer joins but larger result)_
 Test 10.3-b561794-new-style-sql_first-inner-joins
 924 Rows in 578ms
 Test 10.3-b561794-new-style-sql_without-condition
 924 Rows in 438ms
 {code}
 Here our initial used SQL:
 {code:title=SQL giving wrong result (0 rows)}
 SELECT O4Work.ESVN01.NU_BUY_CPY AS PO_BuyCompanyNo, O4Work.ESVN01.NU_ODR AS 
 PO_Number, O4Work.ESVN01.FL_ODR_CAE AS PO_Type, O4Work.ESVN01.NU_MCS_SPY AS 
 PO_SupplierNo, O4Work.ESVN01.NU_ST3 AS PO_StatusNo, 
 O4Work.ESVN01.DA_SPY_COY_PRT AS PO_SCPrintDate, O4Work.ESVN01.FL_SAS AS 
 PO_SeasFlag, CASE WHEN (SELECT COUNT(O4Work.ESVNA5.ID_PTE) FROM O4Work.ESVNA5 
 WHERE O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVNA5.NU_BUY_CPY AND 
 O4Work.ESVN02.NU_ODR = O4Work.ESVNA5.NU_ODR AND O4Work.ESVN02.NU_PST = 
 O4Work.ESVNA5.NU_PST) = 0 THEN 'N' ELSE 'Y' END AS POPA_PictureID, CASE WHEN 
 (SELECT COUNT(O4Work.ESVNG3.NU_ODR) FROM O4Work.ESVNG3 WHERE 
 O4Work.ESVN01.NU_BUY_CPY = O4Work.ESVNG3.NU_BUY_CPY AND O4Work.ESVN01.NU_ODR 
 = O4Work.ESVNG3.NU_ODR) = 0 THEN 'N' ELSE 'Y' END AS ON_ID, 
 O4Work.ESVN02.NU_PST AS POP_Position_Id, O4Work.ESVN02.NU_CTT AS 
 POP_ContractNo, O4Work.ESVN02.NU_ARO_CTT AS POP_ArosContractNo, 
 O4Work.ESVN02.NU_ST3 AS POP_StatusNo, O4Work.ESVN02.DA_CAE AS 
 POP_CreationDate, O4Work.ESVN02.DA_LAT_AMD AS POP_LastAmendDate, 
 O4Work.ESVNA0.NU_SSN_IDE AS POPD_SeasonInd,  O4Work.ESVNA0.NU_STL_ID1 AS 
 POPD_StyleId, O4Work.ESVNA0.NU_SRY_ID1 AS POPD_StoryID, O4Work.ESVNA0.NU_LC1 
 AS POPD_LicenseID, O4Work.ESVP00.NU_CSY AS SER_ClassNo, O4Work.ESVP00.NU_COE 
 AS SER_CodeNo, O4Work.ESVP00.NU_SRL AS SER_SerialNo, O4Work.ESVP00.NU_PIK_MOD 
 AS SER_PickingM, O4Work.ESVN03.NU_MT1_CPY AS POPC_MasterCpyNo, 
 O4Work.ESVN03.QU_ODR AS POPC_OrderedQty, O4Work.ESVN03.DA_EDD AS POPC_Edd, 
 O4Work.ESVN03.DA_LDD AS POPC_Ldd, O4Work.ESVN03.DA_PAD AS POPC_Pad, 
 O4Work.ESVN03.DA_SAD AS POPC_Sad, O4Work.ESVN03.PR_SCP AS POPC_SupCstPrice, 
 O4Work.ESVN03.NU_SCP_CR1 AS POPC_SupCstPrCurr, O4Work.ESVN03.NU_ST3 AS 
 POPC_StatusNo, O4Work.ESVN03.NU_COY_FRM_ODR AS POPC_Src_PO_Number, 
 O4Work.ESVN03.NU_COY_UTL_ODR AS POPC_Tgt_PO_Number, O4Work.ESVN03.DA_FLR_RDY 
 AS POPC_FRM_DATE, O4Work.ESVN03.FL_CSG AS POPC_CS_FLAG, 
 O4Work.ESVN03.NU_PAK_MOD_SPY AS POPC_PackSupplNo, 
 O4Work.ESVN03.NU_PAK_MOD_DCR AS POPC_PackingDCNo, O4Work.ESVN03.NU_PS2_MOD AS 
 POPC_PresMethodNo, O4Work.ESVN04.NU_RTL_CPY AS POPRC_RetailCode, 
 O4Work.ESVN04.PR_PLN_SEL AS POPRC_SellPrice, O4Work.ESVN04.NU_PLN_SEL_PRC_CR1 
 AS POPRC_SellPrCurr, O4Work.ESVN08.NU_AVE AS POPRCA_AdvertNo, 
 O4Work.ESVQ00.ID_SHP AS SHP_ShippingID, O4Work.ESVQ00.NU_SHP AS 
 SHP_ShippingNo, O4Work.ESVNB0.NU_NTL_PDE_ID1 AS POPDC_NationalID, 
 O4Work.ESVNB0.NU_EQP AS POPDC_EquipNumber, O4Work.ESVNE1.PE_OMU AS POPCC_OMU, 
 CASE WHEN (SELECT COUNT(O4Work.ESVN07.NU_ODR) FROM O4Work.ESVN07 WHERE 
 O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVN07.NU_BUY_CPY AND 
 O4Work.ESVN03.NU_MT1_CPY = O4Work.ESVN07.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR 
 = O4Work.ESVN07.NU_ODR AND O4Work.ESVN03.NU_PST = O4Work.ESVN07.NU_PST AND 
 O4Work.ESVN07.FL_ALE_RMK = 'Y') = 0 THEN 'N' ELSE 'Y' END AS

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

Dyre Tjeldvoll updated DERBY-3301:
--


This issue has fix version 10.4 and is marked with either 'Release note needed' 
or 'Existing application impact', but does not have a releaseNote.html attached 
to it. Should it?

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
Assignee: Thomas Nielsen
 Fix For: 10.4.0.0

 Attachments: d3301-queryplan.log, derby-3301-1.diff, 
 derby-3301-1.stat, derby-3301-2.diff, derby-3301-3.diff, derby-3301-3b.diff, 
 derby-3301-4.diff, derby-3301-4b.diff, derby-3301-4b.stat, 
 derby-3301-4c.diff, derby-3301-5.diff, derby-3301-6.diff, derby-3301-7.diff, 
 derby-3301-8.diff, derby-3301-extra.sql, derby-3301-test-1.diff, 
 derby-3301-test-1.stat, derby-3301-test-2.diff, derby-3301-test-3.diff, 
 derby-3301-test-3.stat, derby-3301-test-master-2.diff, 
 derby-3301-test-master-3.diff, derby-3301-test-master-3.stat, 
 derby-3301-test-master.diff, derby-3301-test-master.stat, derby-3301.sql


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

[jira] Closed: (DERBY-2370) EXISTS may return the wrong value for sub-queries involving set operations