date:20070201


[ 
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469453
 ] 

Daniel John Debrunner commented on DERBY-1275:
--

That's the general idea, at least for existing decorators returned by 
TestConfiguration, but I'm curious as to why you feel in this case the static 
method is useful or required.

A class can be used as a decorator, just using 

new SystemPropertyTestSetup(suite, newProperties)

which is actually less to type than

TestDecorator.systemPropertiesSetupDecorator(suite,  newProperties)

Then exposing the class as the decorator actually allows tests to customize it.
Typically a test may want to perform additional setup or teardown based upon an
existing decorator. Java allows this without having to define an additional 
class
explicitly.

For example see CleanDatabaseTestSetup, which allows a test to use it in-line
and easily add DDL statements. This is from the javadoc for 
CleanDatabaseTestSetup.

 return new CleanDatabaseTestSetup(suite) {
protected void decorateSQL(Statement s) throws SQLException {

s.execute(CREATE TABLE T (I INT));
s.execute(CREATE INDEX TI ON T(I))

}
};

If the CleanDatabaseTestSetup was exposed as a static method then this style of 
customization is no longer possible.
Exposing it as a class and a static method has the downside of multiple ways to 
perform the same task, which tends to make it harder for people to add tests, 
e.g. which way should I use?




 Provide a way to enable client tracing without changing the application
 ---

 Key: DERBY-1275
 URL: https://issues.apache.org/jira/browse/DERBY-1275
 Project: Derby
  Issue Type: Improvement
  Components: Network Client
Affects Versions: 10.1.3.1, 10.2.1.6
Reporter: Kathey Marsden
 Assigned To: Mamta A. Satoor
Priority: Minor
 Fix For: 10.2.3.0

 Attachments: DERBY1275EnableClientTracingDiffV1.txt, 
 DERBY1275EnableClientTracingDiffV2.txt, 
 DERBY1275EnableClientTracingDiffV3.txt, 
 DERBY1275EnableClientTracingDiffV4.txt, 
 DERBY1275EnableClientTracingStatV1.txt, 
 DERBY1275EnableClientTracingStatV2.txt, 
 DERBY1275EnableClientTracingStatV3.txt, DERBY1275EnableClientTracingStatV4.txt


 Currently  the client tracing can be enabled by  setting attributes on the 
 client url, setXXX methods on the DataSource or calling 
 DriverManager.setLogWriter(), but it often cannot be enabled in a deployed 
 client application  because all of these API's require modification of the 
 application or its configuration files.
 It would be good to have a global way to turn on client tracing.  A system 
 property pointing to a property file is  one possibility but probably not 
 ideal because of the impact in class loader contexts.I am not sure what 
 the other possiblities are,

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

2007-02-01 Thread jira

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


Key Summary
DERBY-1275  Provide a way to enable client tracing without changing the 
application
https://issues.apache.org/jira/browse/DERBY-1275
DERBY-2107  Move page latching out of the lock manager
https://issues.apache.org/jira/browse/DERBY-2107
DERBY-2280  DatabaseMetaData.getTypeInfo() UNSIGNED_ATTRIBUTE and 
AUTO_INCREMENT column returns incorrect information for BLOB  CLOB data type
https://issues.apache.org/jira/browse/DERBY-2280
DERBY-2258  DatabaseMetaData.getTypeInfo() does not list supported Derby SQL 
types correctly.
https://issues.apache.org/jira/browse/DERBY-2258
DERBY-2108  Implement SSL/TLS communication between client and server
https://issues.apache.org/jira/browse/DERBY-2108
DERBY-2247  provide set methods for blob in embeded driver
https://issues.apache.org/jira/browse/DERBY-2247
DERBY-1662  Document derbyrun.jar
https://issues.apache.org/jira/browse/DERBY-1662
DERBY-2087  Clean up of a database server directory after running junit tests.
https://issues.apache.org/jira/browse/DERBY-2087
DERBY-1842  Accessibility of figures in Derby Docs
https://issues.apache.org/jira/browse/DERBY-1842
DERBY-2137  CALL (PROCEDURE) statement documentation in reference manual has 
incomplete syntax for arguments
https://issues.apache.org/jira/browse/DERBY-2137
DERBY-2031  Convert derbynet/testProtocol.java to JUnit
https://issues.apache.org/jira/browse/DERBY-2031
DERBY-2255  ij should indicate that it is waiting for more input in a 
multi-line interactive statement.
https://issues.apache.org/jira/browse/DERBY-2255
DERBY-1620  SQL CASE statement returns ERROR 42X89 when including NULL as a 
return value
https://issues.apache.org/jira/browse/DERBY-1620
DERBY-1909  ALTER TABLE DROP COLUMN needs to update GRANTed column privileges
https://issues.apache.org/jira/browse/DERBY-1909
DERBY-2161  MessageBuilder can write the properties file using the wrong 
encoding.
https://issues.apache.org/jira/browse/DERBY-2161
DERBY-681   Eliminate the parser's rewriting of the abstract syntax tree for 
queries with GROUP BY and/or HAVING clauses
https://issues.apache.org/jira/browse/DERBY-681
DERBY-1938  Add support for setObject(arg, null)
https://issues.apache.org/jira/browse/DERBY-1938

[jira] Updated: (DERBY-2087) Clean up of a database server directory after running junit tests.

2007-02-01 Thread Julius Stroffek (JIRA)


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

Julius Stroffek updated DERBY-2087:
---

Attachment: d2087_round2.stat
d2087_round2.diff

 Clean up of a database server directory after running junit tests.
 --

 Key: DERBY-2087
 URL: https://issues.apache.org/jira/browse/DERBY-2087
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.3.0.0
Reporter: Julius Stroffek
 Assigned To: Julius Stroffek
Priority: Minor
 Fix For: 10.3.0.0

 Attachments: d2087.diff, d2087.stat, d2087_round2.diff, 
 d2087_round2.stat, d2087_try2.diff, d2087_try2.stat


 If I create a test using multiple connections using code like this 
   DataSource ds1 = JDBCDataSource.getDataSource(FIRSTDB1);
   JDBCDataSource.setBeanProperty(ds1, connectionAttributes, 
 create=true);
   Connection conn1 = ds1.getConnection();
 the files created on a server does not get cleaned.

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

2007-02-01 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 501898/2007-01-31 18:00:10 CET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
0498498 0   101.24% derbyall
066236623 0   116.67% suitesAll
 sol
0498498 0   103.14% derbyall
066236623 0   152.82% suitesAll
 solN+1
0498498 0   123.35% derbyall
066236623 0   191.49% suitesAll
 sparc
0498498 0   107.88% derbyall
066236623 0   178.70% suitesAll
 win
   NA NA NANA   derbyall
F:2,E:066236621 0   112.04% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-501898.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/501898.html 

*Jvm: 1.5*
 lin
0492492 297.93% derbyall
023742374 0   190.30% suitesAll
 sles
1492491 2   102.93% derbyall
023742374 0   117.56% suitesAll
 sol
0492492 2   107.09% derbyall
023742374 0   147.79% suitesAll
 solN+1
0492492 2   128.22% derbyall
023742374 0   152.58% suitesAll
 sparc
0492492 2   108.39% derbyall
023742374 0   144.18% suitesAll
 win
0492492 2   119.10% derbyall
F:2,E:023742372 0   107.32% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-501898.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/501898.html 

*Jvm: 1.4*
 lin
0486486 498.39% derbyall
023702370 0   194.26% suitesAll
 sles
0486486 4   100.85% derbyall
023702370 0   118.38% suitesAll
 sol
0486486 4   103.70% derbyall
023702370 0   144.11% suitesAll
 solN+1
0486486 4   130.47% derbyall
023702370 0   164.22% suitesAll
 sparc
0486486 4   109.36% derbyall
023702370 0   156.20% suitesAll
 win
0486486 469.06% derbyall
F:2,E:023702368 0   115.80% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-501898.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/501898.html 

---

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

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

[jira] Updated: (DERBY-2087) Clean up of a database server directory after running junit tests.

2007-02-01 Thread Julius Stroffek (JIRA)

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

Julius Stroffek updated DERBY-2087:
---

Attachment: d2087_round2_try2.stat
d2087_round2_try2.diff

I created an additional patch which uses logical database names in
additionalDatabaseDecorator function (which replaces singleUseDatabaseDecorator
with database name). I added also a openConnection method where one can specify
a connection attributes as a string.

Since the prototype of new method openConnection(String dbName, String
connectionAttributes) added to Connector interface conflicts
with the openConnection(String user, String password) and this method is not
used I commented it and have a plan to remove it since it is possible to
specify user name and password in connection attributes. Is ok to do it this
way or it is better to define connection properties in Properties object
instead of string? I think that using String for connection attributes is
simpler to use.

I ran derbyall and suites.All without failures. Please, give me any comments or
suggestions.

Clean up of a database server directory after running junit tests.
--

Key: DERBY-2087
URL: https://issues.apache.org/jira/browse/DERBY-2087
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.3.0.0
Reporter: Julius Stroffek
Assigned To: Julius Stroffek
Priority: Minor
Fix For: 10.3.0.0

Attachments: d2087.diff, d2087.stat, d2087_round2.diff,
d2087_round2.stat, d2087_round2_try2.diff, d2087_round2_try2.stat,
d2087_try2.diff, d2087_try2.stat

If I create a test using multiple connections using code like this
DataSource ds1 = JDBCDataSource.getDataSource(FIRSTDB1);
JDBCDataSource.setBeanProperty(ds1, connectionAttributes,
create=true);
Connection conn1 = ds1.getConnection();
the files created on a server does not get cleaned.

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

[jira] Commented: (DERBY-2252) Add Jar IDs to the EXTERNAL names in routine declarations

2007-02-01 Thread Rick Hillegas (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469517
]

Rick Hillegas commented on DERBY-2252:
--

Thanks for the feedback, Dan. I have incorporated your improvements in the next
revs of this spec and the companion spec for phase 3 (DERBY-2253). I will wait
a bit to collect more feedback before posting the new revs.

1) I added signatures to the syntax of the EXTERNAL NAMEs as you suggested.

2) I clarified class/method resolution rules.

3) The System Tables section now explains my reasons for tracking jar IDs in a
new SYSALIASES.FILEID column. The issue here was not dependency tracking but
rather the construction of the jar-specific classpath. That is addressed in the
phase 3 spec but I can see that some explanation is needed in this spec too. I
agree that we could reconstruct this information from the dependency system.
But I think that modelling the jar ID in SYSALIASES will make it more
straightforward to construct the jar-specific classpath and it will make it
easier for tech support to figure out that classpath from the catalogs.

4) I have improved the REVOKE USAGE explanation as you suggested.

Add Jar IDs to the EXTERNAL names in routine declarations
-

Key: DERBY-2252
URL: https://issues.apache.org/jira/browse/DERBY-2252
Project: Derby
Issue Type: New Feature
Components: Security, SQL
Reporter: Rick Hillegas
Attachments: jarIDs.html

This is phase (2) of the work described in the master JIRA DERBY-2206,
motivated by the wiki page http://wiki.apache.org/db-derby/JavaRoutineSecurity
This task involves adding Jar IDs to the external names in CREATE PROCEDURE
and CREATE FUNCTION statements.

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

[jira] Updated: (DERBY-2264) Restrict shutdown, upgrade, and encryption powers to the database owner

2007-02-01 Thread Rick Hillegas (JIRA)


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

Rick Hillegas updated DERBY-2264:
-

Attachment: dbaPowers.html

Attaching rev 2 of the functional spec. This incorporates Dan's suggestion (in 
a January 26, 2007 comment on DERBY-2206): only enforce these changes if 
authentication is turned on.

 Restrict shutdown, upgrade, and encryption powers to the database owner
 ---

 Key: DERBY-2264
 URL: https://issues.apache.org/jira/browse/DERBY-2264
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
 Attachments: dbaPowers.html, dbaPowers.html


 This JIRA separates out the database-owner powers from the system privileges 
 in the master security JIRA DERBY-2109. Restrict the following powers to the 
 database owner for the moment: shutdown, upgrade, and encryption.

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

[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application

2007-02-01 Thread Mamta A. Satoor (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469528
 ] 

Mamta A. Satoor commented on DERBY-1275:


I think I misunderstood your following comment on Jan 27th to the review 
package DERBY1275EnableClientTracingDiffV2.txt
The test breaks the pattern for JUnit tests in a few ways: the suite method 
performs test setup. The suite method is for providing a set of fixtures to 
run. Setup should be performed in a test decorator for a set of fixtures or the 
setUp method for each fixture. 

I took the above comment to mean that Junit pattern discourages following setup 
code in the suite() method
Properties traceRelatedProperties = new Properties();
traceRelatedProperties.setProperty(derby.client.traceLevel, 64);
traceDirectory = . + File.separator + TraceDir  + 
File.separator;
traceRelatedProperties.setProperty(derby.client.traceDirectory, 
traceDirectory);
return new SystemPropertyTestSetup(suite, traceRelatedProperties);

Now, I think your comment was really for following piece of code in the suite() 
method and not for the code related to SystemPropertyTestSetup fixture. 
+File dir = new File( traceDirectory );
+dir.mkdirs();

This is the only outstanding issue that I need to resolve on this Jira entry 
based on all different comments. I have already moved the directory setup code 
in the setUp() method in the .DERBY1275EnableClientTracingDiffV4.txt Next, I 
will remove systemPropertiesSetupDecorator from TestConfiguration and have my 
junit test directly use the fixture SystemPropertyTestSetup.



 Provide a way to enable client tracing without changing the application
 ---

 Key: DERBY-1275
 URL: https://issues.apache.org/jira/browse/DERBY-1275
 Project: Derby
  Issue Type: Improvement
  Components: Network Client
Affects Versions: 10.1.3.1, 10.2.1.6
Reporter: Kathey Marsden
 Assigned To: Mamta A. Satoor
Priority: Minor
 Fix For: 10.2.3.0

 Attachments: DERBY1275EnableClientTracingDiffV1.txt, 
 DERBY1275EnableClientTracingDiffV2.txt, 
 DERBY1275EnableClientTracingDiffV3.txt, 
 DERBY1275EnableClientTracingDiffV4.txt, 
 DERBY1275EnableClientTracingStatV1.txt, 
 DERBY1275EnableClientTracingStatV2.txt, 
 DERBY1275EnableClientTracingStatV3.txt, DERBY1275EnableClientTracingStatV4.txt


 Currently  the client tracing can be enabled by  setting attributes on the 
 client url, setXXX methods on the DataSource or calling 
 DriverManager.setLogWriter(), but it often cannot be enabled in a deployed 
 client application  because all of these API's require modification of the 
 application or its configuration files.
 It would be good to have a global way to turn on client tracing.  A system 
 property pointing to a property file is  one possibility but probably not 
 ideal because of the impact in class loader contexts.I am not sure what 
 the other possiblities are,

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

[jira] Commented: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles

2007-02-01 Thread Dag H. Wanvik (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469543
 ] 

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

I have made a Wiki page for this topic and added some thoughts from
a preliminary investigation. Please see:

http://wiki.apache.org/db-derby/SqlRoles


 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas

 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

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

[jira] Assigned: (DERBY-2196) Run standalone network server with security manager by default

2007-02-01 Thread Rick Hillegas (JIRA)

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

Rick Hillegas reassigned DERBY-2196:

Assignee: Rick Hillegas

Run standalone network server with security manager by default
--

Key: DERBY-2196
URL: https://issues.apache.org/jira/browse/DERBY-2196
Project: Derby
Issue Type: Improvement
Components: Network Server, Security
Reporter: Daniel John Debrunner
Assigned To: Rick Hillegas
Attachments: secureServer.html, secureServer.html, secureServer.html,
secureServer.html

From an e-mail discussion:
... Derby should match the security provided by typical client server
systems such as DB2, Oracle, etc. I
think in this case system/database owners are trusting the database
system to ensure that their system cannot be attacked. So maybe if Derby
is booted as a standalone server with no security manager involved, it
should install one with a default security policy. Thus allowing Derby
to use Java security manager to manage system privileges but not
requiring everyone to become familiar with them.
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/[EMAIL
PROTECTED]
I imagine such a policy would allow any access to databases under
derby.system.home and/or user.home.
By standalone I mean the network server was started though the main() method
(command line).

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

[jira] Commented: (DERBY-2252) Add Jar IDs to the EXTERNAL names in routine declarations


[ 
https://issues.apache.org/jira/browse/DERBY-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469544
 ] 

Daniel John Debrunner commented on DERBY-2252:
--

Thanks for putting up with all my comments Rick.

 3) The System Tables section now explains my reasons for tracking jar IDs in 
 a new SYSALIASES.FILEID column. The issue here was not dependency tracking 
 but rather the construction of the jar-specific classpath.

I look forward to seeing that, I don't see how the definition of an entry point 
is related to the jar specific class path, but I haven't thought a lot about 
how to implement it.

 Add Jar IDs to the EXTERNAL names in routine declarations
 -

 Key: DERBY-2252
 URL: https://issues.apache.org/jira/browse/DERBY-2252
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
 Attachments: jarIDs.html


 This is phase (2) of the work described in the master JIRA DERBY-2206, 
 motivated by the wiki page http://wiki.apache.org/db-derby/JavaRoutineSecurity
 This task involves adding Jar IDs to the external names in CREATE PROCEDURE 
 and CREATE FUNCTION statements.

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

[jira] Created: (DERBY-2282) Incorrect transitive closure logic leads to inconsistent behavior for binary comparison predicates.

2007-02-01 Thread A B (JIRA)

Incorrect transitive closure logic leads to inconsistent behavior for binary 
comparison predicates.
-

 Key: DERBY-2282
 URL: https://issues.apache.org/jira/browse/DERBY-2282
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.2.2.0, 10.2.1.6, 10.1.3.1, 10.1.2.1, 10.1.1.0, 
10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.3.2, 10.1.4.0, 10.2.2.1, 10.2.3.0, 10.3.0.0
Reporter: A B
Priority: Minor


The logic that handles transive closure for search predicates is in the 
searchClauseTransitiveClosure() method of 
impl/sql/compile/PredicateList.java.  That method contains the following logic:

else if (operator instanceof BinaryComparisonOperatorNode)
{
BinaryComparisonOperatorNode bcon = 
(BinaryComparisonOperatorNode) operator;
ValueNode left = bcon.getLeftOperand();
ValueNode right = bcon.getRightOperand();

// RESOLVE: Consider using variant type of the expression, 
instead of
// ConstantNode or ParameterNode in the future.
if (left instanceof ColumnReference  
  (right instanceof ConstantNode || right instanceof 
ParameterNode))
{
searchClauses.addElement(predicate);
}
else if (right instanceof ConstantNode  left instanceof 
ColumnReference)
{
// put the ColumnReference on the left to simplify things
bcon.swapOperands();
searchClauses.addElement(predicate);
}
continue;
}

Notice that the inner else-if condition is wrong.  It's supposed to be 
checking to see if the right node is a ColumnReference and the left node is a 
Constant, but that's not what it does--instead, it does a check that is really 
a sub-condition of the if condition--i.e. whenever the else if condition is 
true the if condition will be true and thus we won't ever execute the else 
if branch.

I confirmed this by looking at the code coverage results for 10.2:

  http://people.apache.org/~fuzzylogic/codecoverage/428586/_files/2f4.html#2d

The lines in question are never executed.

What this means is that a query which specifies constants on the *left* side of 
a comparison predicate will behave differently than a query which specifies 
constants on the *right* side of the same comparison.  As an example:

create table t1 (i int);
create table t2 (j int);

insert into t1 values 1, 5, 7, 11, 13, 17, 19;
insert into t2 values 23, 29, 31, 37, 43, 47, 53;
insert into t1 select 23 * i from t1 where i  19;
insert into t2 select 23 * j from t2 where j  55;

-- Following will show two qualifiers for T2 and three for T1
-- because transitive closure adds two new qualifiers, t2.j = 23
-- and t1.i = 30 to the list.
select * from t1, t2 where t1.i = t2.j and t1.i = 23 and t2.j = 30;

-- But if we put the constants on the left-hand side, we don't
-- detect the transitive closure and thus we have a single qualifier
-- for T2 and only two qualifiers for T1.
select * from t1, t2 where t1.i = t2.j and 23 = t1.i and 30 = t2.j;

The above two queries should in theory show the same query plan--but if we 
execute the above statements while logging query plans, we'll see a difference 
(as explained in the sql comments above).

I did a quick scan of the various branches and found that this incorrect logic 
appears in every branch back to 10.0 (hence the massive Affects Versions 
list).  That said, the result of this bug isn't an error nor is it wrong 
results, so I'm just marking it Minor.

The fix looks to be pretty straightforward

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

[jira] Updated: (DERBY-2237) Cleanup copyrights in the DITA source and generated docs

2007-02-01 Thread Jean T. Anderson (JIRA)

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

Jean T. Anderson updated DERBY-2237:

Attachment: copyright-2237-html-1.zip
copyright-2237-1.diff

Here is a first shot at rewording the copyright notice and adding the apache
license, like the http project does, initially just for the Getting Started
guide.

copyright-2237-1.diff - svn diff (patch -p0 at the trunk level)
copyright-2237-html-1.zip (html pages: index, toc, copyright and license)

In keeping with the http project, I ended up making the license a separate page
(separate topic). The http project spent a lot of time fussing to make the
format of the license text pretty (for example, see
http://httpd.apache.org/docs/2.2/license). I spent long enough fussing to
realize that obtaining a pretty format is non trivial, so included it as a
codeblock. It's ok in the html and definitely clunky in the PDF because some of
the text is just long enough to wrap.

Thoughts?

Cleanup copyrights in the DITA source and generated docs

Key: DERBY-2237
URL: https://issues.apache.org/jira/browse/DERBY-2237
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.2.1.6, 10.2.2.0
Environment: linux
Reporter: scott hutinger
Priority: Blocker
Attachments: copyright-2237-1.diff, copyright-2237-html-1.zip,
dita2fo-shell-copyr1.diff.gz, pt_BR_copyright.diff,
pt_BR_copyright.diff.html, radmincopyright.html, rgscopyright.html,
rrefcopyright.html

Problems include:
1) The PDF docs currently include an empty Copyright string in the header.
dita2fo-shell-copyr1.diff.gz is a patch to fix the fop (.pdf) copyright
header which is currently blank. This is from march 9, 2006.
2) Some source files have the old style copyright in the header that is not
in compliance with http://www.apache.org/legal/src-headers.html. For example,
see src/ref/rrefsistabssyscolperms.dita
3) The generated html docs have new copyright tags added, such as these
entries in ref/crefjavbclobnot.html
meta name=copyright content=(C) Copyright 2005 /
meta name=DC.rights.owner content=(C) Copyright 2005 /

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

[jira] Commented: (DERBY-2107) Move page latching out of the lock manager

2007-02-01 Thread Suresh Thalamati (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469575
]

Suresh Thalamati commented on DERBY-2107:
-

Hi Knut,

I reviewed the latest patch, it looks good to be committed. I have only
few minor questions/comments :

1) you may want to fix comments in void setExclusive(BaseContainerHandle
requester)

// because i) lock manager might assume latches are exclusive for
// performance, ii)

2)
+ owner = requester;
+ requester.addObserver(this);

It took me some time to understand how this works on an error cases
scenarios, basically what happens if a thread after acquiring a latch
errors out for some reason. My understanding is you are handling
this cases by by putting the pages on the container observer list
(requester.addObserver(this)). Please add some comments to why this page
is added to observer list.

3)
+
+ // just deadlock out if a transaction tries to double latch the
+ // page while not in abort

comment is good. But , you may want to add some assertion or throw
error here, if this case should not happen.

4)
- /** Debugging, print slot table information */
- protected String slotTableToString()

I don't know why you removed this method in this patch. May
be this method is not used or not required. Occasionally I found
these type of methods useful while debugging a page corruption
to quickly dump page info with some minor changes to the code.

5)
+ // Expect notify from releaseExclusive().
+ wait();

I was wondering , if the wait() method here should be time based to catch
any infinite waits due to incorrectly missing release latch calls or you think
it is going to be be unnecessarily expensive ?

5) Did you find the existing unit tests already tests latching methods ? or
you are planning to write one.

Thanks
-suresh

Move page latching out of the lock manager
--

Key: DERBY-2107
URL: https://issues.apache.org/jira/browse/DERBY-2107
Project: Derby
Issue Type: Improvement
Components: Performance, Services, Store
Affects Versions: 10.3.0.0
Reporter: Knut Anders Hatlen
Assigned To: Knut Anders Hatlen
Priority: Minor
Attachments: derby-2107-1a.diff, derby-2107-1a.stat,
derby-2107-1b.diff, derby-2107-1c.diff, derby-2107-1c.stat

Latching of pages could be done more efficiently locally in store than in the
lock manager. See the discussion here:
http://thread.gmane.org/gmane.comp.apache.db.derby.devel/33135

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

Derby fully sql-2003 compliant?

2007-02-01 Thread Christian Lang

Hi,

I'm trying to understand which SQL language subset Derby is using. I 
installed version 10.2.2.0 and tried to compile and execute the following 
statement:

SELECT MIN(A) OVER (PARTITION BY B) FROM C;

(which seems a legal SQL-2003 statement). However, the Derby sql compiler 
complains about the '(' after the 'OVER' keyword.
I looked into the sqlgrammar.jj file and could not find a partition or 
over keyword at all. Is this not supported (yet)?
Or am I doing something wrong?

Thanks for clarifying,
Christian

Re: Derby fully sql-2003 compliant?

2007-02-01 Thread Bernt M. Johnsen

 [EMAIL PROTECTED] wrote (2007-02-01 19:15:16):
 Christian Lang [EMAIL PROTECTED] writes:
 
  Hi,
 
  I'm trying to understand which SQL language subset Derby is using. I 
  installed version 10.2.2.0 and tried to compile and execute the following 
  statement:
 
  SELECT MIN(A) OVER (PARTITION BY B) FROM C;
 
  (which seems a legal SQL-2003 statement). However, the Derby sql compiler 
  complains about the '(' after the 'OVER' keyword.
  I looked into the sqlgrammar.jj file and could not find a partition or 
  over keyword at all. Is this not supported (yet)?
  Or am I doing something wrong?
 
 I don't find anything about this on
 http://wiki.apache.org/db-derby/SQLvsDerbyFeatures
 
 so either it is completely over-looked, or it isn't required.

It is in section 7.11 window clause in the 2003 standard

Tis is optional feature T612 Advanced OLAP operations which is not
implemented in Derby

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway


signature.asc
Description: Digital signature

[jira] Created: (DERBY-2283) convert lang/currentof.java test junit

convert lang/currentof.java test junit
--

 Key: DERBY-2283
 URL: https://issues.apache.org/jira/browse/DERBY-2283
 Project: Derby
  Issue Type: Test
Reporter: Manjula Kutty
 Assigned To: Manjula Kutty
Priority: Minor
 Fix For: 10.3.0.0


Using this Jira entry to attach the converted test in future

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

[jira] Created: (DERBY-2284) OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80

OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change 
once written: was 0, now 80
-

 Key: DERBY-2284
 URL: https://issues.apache.org/jira/browse/DERBY-2284
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.3.0.0
 Environment: Windows 2000, IBM JDK 1.5
Reporter: Andrew McIntyre


Saw this error in the nightlies last week, seems to be intermittant, filing 
this for tracking purposes:

*** Start: OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:37:22 ***
5 del
 database shutdown properly
6 del
 Restored From the Backup
7 del
 Consistency Check is Done
8 del
 database shutdown properly
9 del
 End Online Backup Test1
9 add
 ERROR XJ001: Java exception: ': 
 org.apache.derby.iapi.services.context.ShutdownException'.
 org.apache.derby.iapi.services.context.ShutdownException: 
 ERROR 08003: No current connection.
 java.sql.SQLException: No current connection.
 ERROR XSDB3: Container information cannot change once written: was 0, now 80
 ERROR XSDB3: Container information cannot change once written: was 0, now 80
   at org.apache.derby.impl.store.raw.log.LogToFile.checkpException in 
 thread main java.lang.Exception: BACKUP FAILED:Container information cannot 
 change once written: was 0, now 80
 oint(Unknown Source)
Test Failed.
*** End:   OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:38:23 ***


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

[jira] Updated: (DERBY-2284) OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change once written: was 0, now 80

2007-02-01 Thread Suresh Thalamati (JIRA)


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

Suresh Thalamati updated DERBY-2284:


Attachment: derby.log
OnlineBackupTest1.out

error log files related to this test failure. 

 OnlineBackupTest1 fails with ERROR XSDB3: Container information cannot change 
 once written: was 0, now 80
 -

 Key: DERBY-2284
 URL: https://issues.apache.org/jira/browse/DERBY-2284
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.3.0.0
 Environment: Windows 2000, IBM JDK 1.5
Reporter: Andrew McIntyre
 Attachments: derby.log, OnlineBackupTest1.out


 Saw this error in the nightlies last week, seems to be intermittant, filing 
 this for tracking purposes:
 *** Start: OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:37:22 
 ***
 5 del
  database shutdown properly
 6 del
  Restored From the Backup
 7 del
  Consistency Check is Done
 8 del
  database shutdown properly
 9 del
  End Online Backup Test1
 9 add
  ERROR XJ001: Java exception: ': 
  org.apache.derby.iapi.services.context.ShutdownException'.
  org.apache.derby.iapi.services.context.ShutdownException: 
  ERROR 08003: No current connection.
  java.sql.SQLException: No current connection.
  ERROR XSDB3: Container information cannot change once written: was 0, now 80
  ERROR XSDB3: Container information cannot change once written: was 0, now 80
  at org.apache.derby.impl.store.raw.log.LogToFile.checkpException in 
  thread main java.lang.Exception: BACKUP FAILED:Container information 
  cannot change once written: was 0, now 80
  oint(Unknown Source)
 Test Failed.
 *** End:   OnlineBackupTest1 jdk1.5.0 storeall:storemore 2007-01-23 02:38:23 
 ***

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

[jira] Updated: (DERBY-1752) Fix javadoc to account for changes required by new licence header policy.


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

Andrew McIntyre updated DERBY-1752:
---

Attachment: derby-1752-v2.diff

Attaching another patch for this. Corrects copyright dates and removes 'or its 
licensors' text, and updates the front page text to match what has been 
proposed for the docs in DERBY-2237.

 Fix javadoc to account for changes required by new licence header policy.
 -

 Key: DERBY-1752
 URL: https://issues.apache.org/jira/browse/DERBY-1752
 Project: Derby
  Issue Type: Sub-task
Reporter: Daniel John Debrunner
 Assigned To: Andrew McIntyre
 Fix For: 10.2.3.0, 10.3.0.0

 Attachments: derby-1752-v1.diff, derby-1752-v2.diff


 The published javadoc creates a copyright with the old copyright statement, 
 should be replaced with the collected works copyright,.

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

[jira] Updated: (DERBY-1752) Fix javadoc to account for changes required by new licence header policy.


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

Andrew McIntyre updated DERBY-1752:
---

Derby Info: [Patch Available]

 Fix javadoc to account for changes required by new licence header policy.
 -

 Key: DERBY-1752
 URL: https://issues.apache.org/jira/browse/DERBY-1752
 Project: Derby
  Issue Type: Sub-task
Reporter: Daniel John Debrunner
 Assigned To: Andrew McIntyre
 Fix For: 10.2.3.0, 10.3.0.0

 Attachments: derby-1752-v1.diff, derby-1752-v2.diff


 The published javadoc creates a copyright with the old copyright statement, 
 should be replaced with the collected works copyright,.

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

suites.EncryptionSuite added - appreciate other platform testing

2007-02-01 Thread Daniel John Debrunner

With revision 502400 I created top-level suite that mimics the 
encryption suite from the old harness. It runs a set of tests
against a number of encryption algorithms, those from the set used in 
the old harness. It only has one test in it, LobStreamsTest, as that is 
the only converted test (so far) that runs in the old encryption suite.


I have not yet added to suites.All as I'd like to get some more testing 
done on it. I've tested on windows with these JVMs with no issues:


Sun: 1.4.2, 1.5, 1.6
IBM: 1.4.2, 1.5

I'd appreciate others running on other platform/vm combinations to see 
if the algorithms are supported everywhere, or if the test needs to 
check to see if an algorithm is available before running. I know it 
needs some additional logic to handle not running in J2ME.


I'll plan on committing it into suites.All ( the ant targets) next week 
if no problems appear.


Test class:

org.apache.derbyTesting.functionTests.suites.EncryptionSuite

Thanks,
Dan.

[jira] Updated: (DERBY-2283) convert lang/currentof.java test junit


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

Manjula Kutty updated DERBY-2283:
-

Attachment: _Suite.java
CurrentOfTest.java

Attaching the CurrentOfTest.java for review. I ran the lang Suite and one test 
failed. It was UpdatableResultSetTest which timed out during getting a n/w 
server connection. This is my first attempt in conversion of tests to junit. 

 convert lang/currentof.java test junit
 --

 Key: DERBY-2283
 URL: https://issues.apache.org/jira/browse/DERBY-2283
 Project: Derby
  Issue Type: Test
Reporter: Manjula Kutty
 Assigned To: Manjula Kutty
Priority: Minor
 Fix For: 10.3.0.0

 Attachments: _Suite.java, CurrentOfTest.java


 Using this Jira entry to attach the converted test in future

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

[jira] Updated: (DERBY-2283) convert lang/currentof.java test junit


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

Manjula Kutty updated DERBY-2283:
-

Derby Info: [Patch Available]

 convert lang/currentof.java test junit
 --

 Key: DERBY-2283
 URL: https://issues.apache.org/jira/browse/DERBY-2283
 Project: Derby
  Issue Type: Test
Reporter: Manjula Kutty
 Assigned To: Manjula Kutty
Priority: Minor
 Fix For: 10.3.0.0

 Attachments: _Suite.java, CurrentOfTest.java


 Using this Jira entry to attach the converted test in future

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

[jira] Updated: (DERBY-2283) convert lang/currentof.java test to junit test


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

Manjula Kutty updated DERBY-2283:
-

Summary: convert lang/currentof.java test to junit test  (was: convert 
lang/currentof.java test junit)

 convert lang/currentof.java test to junit test
 --

 Key: DERBY-2283
 URL: https://issues.apache.org/jira/browse/DERBY-2283
 Project: Derby
  Issue Type: Test
Reporter: Manjula Kutty
 Assigned To: Manjula Kutty
Priority: Minor
 Fix For: 10.3.0.0

 Attachments: _Suite.java, CurrentOfTest.java


 Using this Jira entry to attach the converted test in future

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

derby-dev gets publicly archived

2007-02-01 Thread Jean T. Anderson

Every now and then a post comes through with a disclaimer at the bottom
that mentions that the post is (or may be) confidential. The wording on
these disclaimers varies.

I wanted to make sure that everyone subscribed to the derby-dev list
understands that not only are the Derby mail lists publicly archived in
the ASF archives, they also get archived many other places as well. The
Derby mail lists page [1] provides links to the Apache (mod_mbox)
archives as well as to gmane and nabble. The Derby lists also get
archived at mail-archive.com [2] -- and I don't know how many other places.

So, understand that posts are publicly archived. Also understand that
there is no way to revoke a post.

 -jean

[jira] Commented: (DERBY-2283) convert lang/currentof.java test to junit test


[ 
https://issues.apache.org/jira/browse/DERBY-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469623
 ] 

Daniel John Debrunner commented on DERBY-2283:
--

The test generally looks good, usually the timeout failures are due to another 
test not closing its JDBC objects, such as statements. So it might be due to 
your test, I think at least one prepared statement is not closed.

Some minor improvements that would make the test even more readable for others:

Instead of:
   assertEquals(cursor.getCursorName(), null);
use
   assertNull(cursor.getCursorName());
Also the pattern for assert methods is the expected value is the left argument 
, and the tested value the right, the use with null above has it the other way 
around, just an FYI.

Similar for:
   assertEquals(false, cursor.next());
use
   assertFalse(cursor.next());

You can look at the JUnit javadoc for the Assert class to see the range of 
assert methods available.

I think many of the try-catch blocks in the test can be replaced with the 
assert methods Army added a while ago:
e.g.
try {
delete.executeUpdate(); // no current row / closed
fail(Exception expected above!);
} catch (SQLException se) {
assertSQLState(24000, se);
}

with
   // no current row / closed
   assertStatementError(24000, delete);

This helps to give the code a cleaner look.

That would also cleanup these try-catch blocks:
try {
assertUpdateCount(update, 0);
fail(Exception expected above!);

} catch (SQLException se) {
assertSQLState(XCL07, se);
}

Here I think the assertUpdateCount() confuses the reader as you don't expect 
that update statement to succeed an return zero rows, but the assertUpdateCount 
implies that. If for some reason the assertStatementError() didn't work here, I 
think clearer code would be:
try {
update.executeUpdate();
fail(Exception expected above!);

} catch (SQLException se) {
assertSQLState(XCL07, se);
}
but this is just an FYI, since the assertStatementError is the correct approach.

Can you provide a patch using svn diff instead of individual files? Also are 
you going to remove the old test and its master files etc?



 convert lang/currentof.java test to junit test
 --

 Key: DERBY-2283
 URL: https://issues.apache.org/jira/browse/DERBY-2283
 Project: Derby
  Issue Type: Test
Reporter: Manjula Kutty
 Assigned To: Manjula Kutty
Priority: Minor
 Fix For: 10.3.0.0

 Attachments: _Suite.java, CurrentOfTest.java


 Using this Jira entry to attach the converted test in future

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

Re: suites.EncryptionSuite added - appreciate other platform testing

2007-02-01 Thread Andrew McIntyre


On 2/1/07, Daniel John Debrunner [EMAIL PROTECTED] wrote:

With revision 502400 I created top-level suite that mimics the
encryption suite from the old harness. It runs a set of tests
against a number of encryption algorithms, those from the set used in
the old harness. It only has one test in it, LobStreamsTest, as that is
the only converted test (so far) that runs in the old encryption suite.

I have not yet added to suites.All as I'd like to get some more testing
done on it.


Mac OS X 10.4 with JDK 1.5, all tests pass.

andrew

[jira] Closed: (DERBY-2022) jdbcapi.LobStreamsTest runs only in client (not embedded) but its suite() method gives no reason why.


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

Daniel John Debrunner closed DERBY-2022.


   Resolution: Fixed
Fix Version/s: 10.3.0.0
 Assignee: Daniel John Debrunner

Committed revision 502409 adding comment indicating embedded does not implement 
the methods being tested.

 jdbcapi.LobStreamsTest runs only in client (not embedded) but its suite() 
 method gives no reason why.
 -

 Key: DERBY-2022
 URL: https://issues.apache.org/jira/browse/DERBY-2022
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.3.0.0
Reporter: Daniel John Debrunner
 Assigned To: Daniel John Debrunner
Priority: Minor
 Fix For: 10.3.0.0


 It's essential to document why such decisions were made, makes life easier 
 for subsequent deveopers as they try to understand the code and why it is not 
 being used to test embedded.

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

[jira] Commented: (DERBY-2237) Cleanup copyrights in the DITA source and generated docs


[ 
https://issues.apache.org/jira/browse/DERBY-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469627
 ] 

Andrew McIntyre commented on DERBY-2237:


Looks good to me, can't hurt to include the license in the docs. I've taken the 
text you used on the copyright page, and used this for my DERBY-1752 patch.

 Cleanup copyrights in the DITA source and generated docs
 

 Key: DERBY-2237
 URL: https://issues.apache.org/jira/browse/DERBY-2237
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.1.6, 10.2.2.0
 Environment: linux
Reporter: scott hutinger
Priority: Blocker
 Attachments: copyright-2237-1.diff, copyright-2237-html-1.zip, 
 dita2fo-shell-copyr1.diff.gz, pt_BR_copyright.diff, 
 pt_BR_copyright.diff.html, radmincopyright.html, rgscopyright.html, 
 rrefcopyright.html


 Problems include:
 1) The PDF docs currently include an empty Copyright string in the header. 
 dita2fo-shell-copyr1.diff.gz is a patch to fix the fop (.pdf) copyright 
 header which is currently blank.  This is from march 9, 2006.
 2) Some source files have the old style copyright in the header that is not 
 in compliance with http://www.apache.org/legal/src-headers.html. For example, 
 see src/ref/rrefsistabssyscolperms.dita
 3) The generated html docs have new copyright tags added, such as these 
 entries in ref/crefjavbclobnot.html
 meta name=copyright content=(C) Copyright 2005 /
 meta name=DC.rights.owner content=(C) Copyright 2005 /

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

Re: Junit test question

2007-02-01 Thread Manjula G Kutty


Daniel John Debrunner wrote:


Manjula G Kutty wrote:


Hi,

I'm very new to the junit testing. So I picked lang/currentof.java as 
my first test to convert to junit. I did it with the very little 
knowledge I have and also with the help of the Wiki.  I got the test 
running to some extend but then I get some errors on the testUpdate. 
The error says Invalid cursor state . I tried using printf to see 
how the control goes and I could see the number of rows expected and 
got are 0. So it should come out of the  verifycount method, but it 
is not. There may be 3 reasons for this. Either I didn't understand 
the test fully or did something wrong while converting or there may 
be bug . Can someone please review the attached code(I know it is not 
a very clean code) and let me know what went wrong??



One of the possibly unexpected facts about Junit when coming from the 
old derby test harness is understanding the setup and tearDown methods 
of a test class.  A test class contains fixtures, methods that start 
with 'test' which are individual test cases. The setup and tearDown in 
a test class are run for *each* fixture, thus I think twice in this 
class, once for testUpdate() and once for testDelete(). I think a 
common mistake is to assume they are run once for all the fixtures. 
Could that be the case here?


Another issue is that the order of fixtures is not guaranteed when 
adding a suite using MyTest.class. This is intentional since fixtures 
should be standalone test cases, thus if your test depends on 
testUpdate() running before testDelete() you may see intermittant 
problems.


One more question where will  the test database gets created? Even 
the test fails will the teardown method deletes all tables? If so is 
there a mechanism to access the database or copy the database 
instance when the test went wrong?



Nothing exists at the moment, apart from working in a debugger. Please 
feel free to implement something.


Dan.


Here is  some information I gathered during the process of this test 
conversion. Thought it will be useful to people like me who are new to 
the junit world. Please feel free to add more information and also 
correct if I went wrong in any place.


The Wiki pages available in the Apache Derby site is very useful to a 
get initial startup.


setup and teardown methods will run per fixture. not once for the whole 
test.
By default all tests should be able to run in embedded or N/W server 
mode, without much user intervention


Most of the lang tests needs to be run with only embedded to avoid the 
overhead of testduration. There is no point in running the same tests
against networkserver if the test is doing simple SQL query tests. But 
tests for hold cursors and updateableResultSets are good candidates for 
the both.


There are some more Assert methods in the java/testing/junit package 
which can be used for most of SQL tests, like for getting the numberof 
rows updated for a prepared statement execution
you can use assertUpdateCount(PreparedStatement, rows expected); If the 
number of rows returned are not equal to the rows expected, the test 
will fail.


You can get rid of most of the try catch block with the assert methods. 
I used try/catch methods only for negative tests, where I have to catch 
the SQL exception. which can also be eliminated using the 
assertStatementError() method

To catch the SQLException you can use assertSQLState() method

If you are using eclipse for the test development then click on the 
class name and you can see all the methods in the right most tab and if 
you sort them you can view all the assert methods together.
Also there is a very good java doc for the Assert class. you can find it 
at http://junit.sourceforge.net/javadoc/junit/framework/Assert.html


It will be nice if we can add a functionality to keep the database as it 
is if the one test fails.


will add more later

Thanks,
Manjula.

[jira] Commented: (DERBY-2258) DatabaseMetaData.getTypeInfo() does not list supported Derby SQL types correctly.


[ 
https://issues.apache.org/jira/browse/DERBY-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469633
 ] 

Daniel John Debrunner commented on DERBY-2258:
--

I think the changes means the test DatabaseMetaDataTest needs to be updated, 
otherwise it will most likely fail.

 DatabaseMetaData.getTypeInfo() does not list supported Derby SQL types 
 correctly.
 -

 Key: DERBY-2258
 URL: https://issues.apache.org/jira/browse/DERBY-2258
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 
 10.3.0.0
Reporter: Daniel John Debrunner
 Assigned To: Saurabh Vyas
Priority: Minor
 Attachments: Derby-2258.diff, Derby-2258.stat, Derby-2258_v2.diff


 These types are returned but not supported by Derby.
 LONG NVARCHAR
 NATIONAL CHAR
 NATIONAL CHAR VARYING
 The XML type is supported by Derby but not returned.

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

Re: suites.EncryptionSuite added - appreciate other platform testing

2007-02-01 Thread Bryan Pendleton

I'd appreciate others running on other platform/vm combinations 


RedHat Linux with Sun JDK 1.4 and Sun JDK 1.5 were both fine, 100% pass.

thanks,

bryan

[jira] Commented: (DERBY-2237) Cleanup copyrights in the DITA source and generated docs

2007-02-01 Thread Jean T. Anderson (JIRA)

[
https://issues.apache.org/jira/browse/DERBY-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469653
]

Jean T. Anderson commented on DERBY-2237:
-

I shortened the line length for the Apache license so at least the lines don't
wrap on the PDF (doesn't look quite so clunky), and committed changes to the
trunk for the English manuals, revision 502474. I still need to update the
Brazilian Portuguese and Japanese translations.

Cleanup copyrights in the DITA source and generated docs

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

[jira] Created: (DERBY-2285) Mismatch between network client DatabaseMetaData and ResultSetMetaData for BOOLEAN columns (in system tables)

Mismatch between network client DatabaseMetaData and ResultSetMetaData for 
BOOLEAN columns (in system tables)
-

 Key: DERBY-2285
 URL: https://issues.apache.org/jira/browse/DERBY-2285
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.2.2.0, 10.2.1.6, 10.1.3.1, 10.1.2.1, 10.1.1.0, 10.0.2.1
Reporter: Daniel John Debrunner
Priority: Minor


For BOOLEAN columns (which are only supported as system table columns) 
DatabaseMetaData.getColumns() returns the column as BOOLEAN while 
ResultSetMetaData returns the column as a SMALLINT.

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

[jira] Commented: (DERBY-1662) Document derbyrun.jar

[
https://issues.apache.org/jira/browse/DERBY-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469664
]

Andrew McIntyre commented on DERBY-1662:

ctoolsdblook - should mention JAVA_HOME in first example (see previous comment)

ctoolsusingdblook - I find the line break in the URL is a little confusing, can
we remove it?

rtools1003161 - I think this simplifies the issue of setting classpath just a
little bit too much. I think what is needed is a reminder that this effectively
puts all of the derby classes into the classpath, and if the user wants a
minimal set of jars for deployment, they should consult the Developer's Guide
section on deployment (i think that's where the text for that is).

rtoolssysinfo41288 - should mention JAVA_HOME in first example

rtoolssysinfo1002629 - looks good

ttoolsij11815 - ij should be lowercase in first sentence. These scripts set
the ij.protocol property... this is actually not true, but used to be true for
the frameworks scripts. During some usability discussions last year, we came up
with the idea that ij should assume a default protocol of 'jdbc:derby:' on
startup, see DERBY-1217. Maybe a mention that fully qualified Derby JDBC URLs
are required if the ij.protocol system property is not set, or if it is not set
with ij's PROTOCOL command. When mentioning the network server, a pointer to
how to start the network server would be nice. Needs a JAVA_HOME mention right
before the script invocation. It would be nice to have the invocations in bold
as with the other tools pages (e.g. ctoolsdblook)

ttoolsij30600 - looks good

Thanks, Kim, this is definitely giving derbyrun.jar good visibility in the docs.

Document derbyrun.jar
-

Key: DERBY-1662
URL: https://issues.apache.org/jira/browse/DERBY-1662
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.2.1.6
Reporter: David Van Couvering
Assigned To: Kim Haase
Priority: Minor
Attachments: cgsusingtoolsutils.html, DERBY-1662-2.diff,
DERBY-1662-2.zip, DERBY-1662.diff, tadmincbdjhhfd.html

The documentation for ij in the Tools Guide only describes how to start ij
the old way. It should also describe how to start it using derbyrun.jar.
I wonder if the same is true for the other tools, although I haven't
investigated.

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

[jira] Created: (DERBY-2286) Exception NoSpaceOnPage does not provide SQLState or exception text