date:20130416


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

Knut Anders Hatlen updated DERBY-6169:
--

Issue  fix info:   (was: Patch Available)

Thanks, Dag.

I've also committed the 02-a patch with revision 1468317.

 Reduce visibility of classes and methods under impl/sql
 ---

 Key: DERBY-6169
 URL: https://issues.apache.org/jira/browse/DERBY-6169
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Affects Versions: 10.11.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Attachments: derby-6169-01-a.diff, derby-6169-02-a.diff


 My IDE shows many warnings in the classes under impl/sql because they are 
 public and may make parts of the internal state more visible than necessary. 
 I'd like to reduce the visibility of classes and methods, if possible, to 
 make it clearer to IDEs and tools that perform static analysis that the code 
 is only accessed from the same package, and reduce some of the noise from the 
 tools.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DERBY-6184) Clean up warnings in XA transaction id classes

Knut Anders Hatlen created DERBY-6184:
-

 Summary: Clean up warnings in XA transaction id classes
 Key: DERBY-6184
 URL: https://issues.apache.org/jira/browse/DERBY-6184
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.11.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor


I see some FindBugs warnings in impl.store.raw.xact.GlobalXactId and 
iapi.store.access.xa.XAXactId about internal arrays being exposed through 
public methods. We should silence the warnings by making the methods non-public 
or by exposing copies of the arrays instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6184) Clean up warnings in XA transaction id classes


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

Knut Anders Hatlen updated DERBY-6184:
--

Attachment: derby-6184-01-a.diff

The patch derby-6184-01-a.diff silences the warnings.
All the regression tests ran cleanly.

Description of the changes:

- simplify existing cloning of arrays by using clone() instead of
  calling new and arraycopy

- reduce visibility of array-returning methods in GlobalXactId to make
  it clearer for code analysis tools that they are not called from
  outside of the package in which the class lives

- remove said methods from the GlobalTransactionId to allow them to be
  non-public

- make the public, array-returning methods in XAXactId return copies
  of the internal arrays to protect the internal state, as instances
  of this class may be returned all the way out to the user

 Clean up warnings in XA transaction id classes
 --

 Key: DERBY-6184
 URL: https://issues.apache.org/jira/browse/DERBY-6184
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.11.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Attachments: derby-6184-01-a.diff


 I see some FindBugs warnings in impl.store.raw.xact.GlobalXactId and 
 iapi.store.access.xa.XAXactId about internal arrays being exposed through 
 public methods. We should silence the warnings by making the methods 
 non-public or by exposing copies of the arrays instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6184) Clean up warnings in XA transaction id classes


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

Knut Anders Hatlen updated DERBY-6184:
--

Issue  fix info: Patch Available

 Clean up warnings in XA transaction id classes
 --

 Key: DERBY-6184
 URL: https://issues.apache.org/jira/browse/DERBY-6184
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.11.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Attachments: derby-6184-01-a.diff


 I see some FindBugs warnings in impl.store.raw.xact.GlobalXactId and 
 iapi.store.access.xa.XAXactId about internal arrays being exposed through 
 public methods. We should silence the warnings by making the methods 
 non-public or by exposing copies of the arrays instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Java DB - testing] Failure nightly trunk (rev 1468167)

Java DB testing and reporting infrastructure.

Failure nightly trunk (rev 1468167)

There were 48 failures.

Test report:  http://download.java.net/javadesktop/derby/javadb-5575171-report/

[Java DB - testing] Success continuous trunk (rev 1468307)

Java DB testing and reporting infrastructure.

Success continuous trunk (rev 1468307)

No errors or failures.

Test report:  http://download.java.net/javadesktop/derby/javadb-5575185-report/

[Java DB - testing] Failure continuous 10.10 (rev 1468305)

Java DB testing and reporting infrastructure.

Failure continuous 10.10 (rev 1468305)

There were 6 failures.

Test report:  http://download.java.net/javadesktop/derby/javadb-5575184-report/

[Java DB - testing] Success continuous trunk (rev 1468317)

Java DB testing and reporting infrastructure.

Success continuous trunk (rev 1468317)

No errors or failures.

Test report:  http://download.java.net/javadesktop/derby/javadb-5575186-report/

Re: Mechanism for omitted release notes


On 4/15/13 2:58 PM, Katherine Marsden wrote:
For existing users looking to upgrade from any version, I encourage 
them to review all the intervening release notes for a list of changes 
that might affect their application.  Some users do this quite 
diligently and I would like to find a way to add on release notes 
which should have been added earlier once discovered.  An example of 
this is the type change  of the CARDINALITY and PAGES columns of 
getIndexInfo() changed in DERBY-6000  and the new security manager 
permissions required by DERBY-5363.


My hope would be that these release notes could be added to the 
10.10.2 release notes when that release comes out.  My thought is to 
just add a Jira Task with title Add omitted 10.x.x release note: 
Description e.g.
Add omitted 10.10.1 release note: getIndexInfo() columns CARDINALITY 
AND PAGES type change to BIGINT with DERBY-6000


And then just  attach the release note to that issue and resolve for 
10.10.2 so it gets picked up.

Does this sound like a good solution?

Hi Kathey,

This simple solution sounds good to me.

Thanks,
-Rick


Kathey

[RESULT] [VOTE] 10.10.1.1 release

Thanks for everyone's work on coding, documenting, and testing 
10.10.1.1. The polls have closed. The community has approved 10.10.1.1 
as an official Derby release:



+1:
Knut Anders Hatlen (pmc)
Rick Hillegas (pmc)
Dag Wanvik (pmc)
Kim Haase (pmc)
Bryan Pendleton (pmc)
Myrna van Lunteren (pmc)
Kathey Marsden (pmc)
Mike Matrigali (pmc)
Mamta Satoor (pmc)

No other votes were cast.

[jira] [Commented] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas commented on DERBY-6104:
--

I have attempted to add the 10.10 docs to the website. At the very end of this 
long checkin, I received this subversion error:

svn: Commit failed (details follow):
svn: No such transaction '858668-ifqo'

When I tried to commit again, I received this error:

svn: Commit failed (details follow):
svn: Server sent unexpected return value (405 Method Not Allowed) in response 
to MKCOL request for 
'/repos/infra/!svn/wrk/90d61d29-058a-4d4d-be39-3dc240f81a05/websites/production/db/content/derby/docs/10.10'

I then svn updateed my website client. I received a diagnostic line for every 
html file, saying it was updated and it already existed:

EG   10.10/tools/rtoolsoptdbmetadata.html

...and I went through the following dialog on every binary file:

Conflict discovered in '10.10/tools/derbytools.pdf'.
Select: (p) postpone,
(mf) mine-full, (tf) theirs-full,
(s) show all options: mf

Now svn status shows that I have no files checked out in my client. I believe 
that the checkin succeeded. At least, I can see the Getting Started Guide at 
http://db.apache.org/derby/docs/10.10/getstart/index.html. But we should keep 
an eye out for problems with this checkin.



 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6164) Improve Derby's Code Coverage - GSoC 2013 Project

2013-04-16 Thread Bryan Pendleton (JIRA)


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

Bryan Pendleton commented on DERBY-6164:


Hello, Ahsan, I am glad to hear you are interested in Derby. 

Here are several ways to learn more about Derby:
1) Download a recent copy of Derby and go through the tutorials:  
http://db.apache.org/derby/docs/10.9/getstart/cgstutorialintro.html
2) Download the Derby source code from subversion, and follow the instructions 
to be able to build the code and run the test suites: 
http://db.apache.org/derby/dev/derby_source.html
3) Install the Emma tool and run one of the Derby test suites using Emma: 
http://wiki.apache.org/db-derby/CodeCoverageWithEMMA?highlight=%28Emma%29%7C%28Derby%29

Do you get the same code coverage results as the automated runs at 
http://dbtg.foundry.sun.com/derby/test/coverage/?

If not, in which area are your coverage results different?

 Improve Derby's Code Coverage - GSoC 2013 Project
 -

 Key: DERBY-6164
 URL: https://issues.apache.org/jira/browse/DERBY-6164
 Project: Derby
  Issue Type: Task
Reporter: Bryan Pendleton
Assignee: Bryan Pendleton
Priority: Minor
  Labels: gsoc2013

 This year's edition of Google Summer of Code includes, once again, the Apache 
 Software Foundation.
 For the Derby project, I'm offering to mentor a student on the tasks 
 described here.
 For this project, you are required to have some basic knowledge of JUnit and 
 of how code coverage works.
 Currently some packages of Derby have poor code coverage. Emma defines the 
 minimum acceptable code coverage as 70% and some engineers suggest a minimum 
 of 80% is desired. 
 Students are invited to look at [1] to get familiar with Emma's code coverage 
 reports on Derby. 
 The Derby project conducted this effort last year, and substantial 
 improvements were made.
 We are looking to continue this process this year, as there are still areas 
 of the Derby code base where code coverage could be substantially improved.
 The candidate students are also expected to come up with their own schedule 
 for the tests they plan on creating and to discuss this schedule publicly on 
 the mailing list. 
 After a student applies, a small interview will be conducted via email as 
 part of the ASF's evaluation process. 
 [1] - http://dbtg.foundry.sun.com/derby/test/coverage/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

text of release announcement for 10.10.1.1

Here's what I have so far. Please help me improve this. I plan to 
announce the release in the next day or two.


Thanks,
-Rick



Derby 10.10.1.1 contains the following new features:

* SYSCS_UTIL.SYSCS_INVALIDATE_STORED_STATEMENTS - Derby has a new 
system procedure for invalidating stored prepared statements when you 
think that your metadata queries or triggers are misbehaving--for 
example if they throw a NoSuchMethodError on execution. See the section 
on this new system procedure in the Derby Reference Manual.
* Unencrypting databases - Encryption can be turned off on existing 
databases. See the section on the decryptDatabase attribute in the Derby 
Reference Manual.

* Small device profile - Derby runs on the small CP2 profile of Java 8.
* JDBC 4.2 - Derby supports the Java 8 enhancements to JDBC.
* User-defined aggregates - Applications can create their own 
aggregate operators. See the CREATE DERBY AGGREGATE section in the 
Derby Reference Manual.
* Varargs routines - SQL routines can be bound to user-written Java 
methods which have variable length argument lists.
* Optional tools - Derby has new, optional tools to support data 
migration and metadata queries. See the Optional tools section in the 
Derby Tools and Utilities Guide.


In addition, Derby 10.10.1.1 contains many bug, security, and 
documentation fixes.


Please try out this new release.

[jira] [Commented] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas commented on DERBY-6104:
--

Checked in website changes for release 10.10.1.

Source revision 1468456
Generated files revision 858682

 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed

2013-04-16 Thread Rong Qu (JIRA)

Rong Qu created DERBY-6185:
--

 Summary: Query against view  with where name LIKE 'Col1' ESCAPE 
'\'  failed
 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.8.3.0, 10.8.2.2
 Environment: windows 7
Reporter: Rong Qu


The error can be reproduced,
1) create table mytbl1 (name clob(10K));
2) create table mytbl2 (name clob(10K));
3) create view myview (name) as select t1.name from mytbl1 t1 union all select 
t2.name from mytbl2 t2;
4) select name from myview where name LIKE 'Col1' ESCAPE '\';

4) failed with error message 
ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' are 
not supported. Types must be comparable. String types must also have matching 
collation. If collation does not match, a possible solution is to cast operands 
to force them to the default collation (e.g. SELECT tablename FROM 
sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
at org.apache.derby.iapi.error.StandardException.newException(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
 Source)
at 
org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
 Source)
at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
Source)
at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
Source)
at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
Source)
at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
Source)
at 
org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
 Source)
... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6180) DatabaseMetaDataTest should not fail if there are extra columns but only check the expected ones


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

Mike Matrigali updated DERBY-6180:
--

Component/s: Test

 DatabaseMetaDataTest should not fail if there are extra columns but only 
 check the expected ones
 

 Key: DERBY-6180
 URL: https://issues.apache.org/jira/browse/DERBY-6180
 Project: Derby
  Issue Type: Improvement
  Components: Test
Reporter: Kathey Marsden

 In new JDBC versions colums can be added  to DatabaseMetaData. Tests should 
 just check expectedColumns and ignore extra columns to prevent failures with 
 compatibility testing.
 This check occurs in assertColumnNames and assertColumnTypes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6164) Improve Derby's Code Coverage - GSoC 2013 Project

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

Mike Matrigali updated DERBY-6164:
--

Component/s: Test

Improve Derby's Code Coverage - GSoC 2013 Project
-

Key: DERBY-6164
URL: https://issues.apache.org/jira/browse/DERBY-6164
Project: Derby
Issue Type: Task
Components: Test
Reporter: Bryan Pendleton
Assignee: Bryan Pendleton
Priority: Minor
Labels: gsoc2013

This year's edition of Google Summer of Code includes, once again, the Apache
Software Foundation.
For the Derby project, I'm offering to mentor a student on the tasks
described here.
For this project, you are required to have some basic knowledge of JUnit and
of how code coverage works.
Currently some packages of Derby have poor code coverage. Emma defines the
minimum acceptable code coverage as 70% and some engineers suggest a minimum
of 80% is desired.
Students are invited to look at [1] to get familiar with Emma's code coverage
reports on Derby.
The Derby project conducted this effort last year, and substantial
improvements were made.
We are looking to continue this process this year, as there are still areas
of the Derby code base where code coverage could be substantially improved.
The candidate students are also expected to come up with their own schedule
for the tests they plan on creating and to discuss this schedule publicly on
the mailing list.
After a student applies, a small interview will be conducted via email as
part of the ASF's evaluation process.
[1] - http://dbtg.foundry.sun.com/derby/test/coverage/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6157) text for message XSLA4 might encouraging people to delete part of the transaction log

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

Mike Matrigali updated DERBY-6157:
--

Component/s: Store

text for message XSLA4 might encouraging people to delete part of the
transaction log
-

Key: DERBY-6157
URL: https://issues.apache.org/jira/browse/DERBY-6157
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.10.1.1, 10.10.1.2, 10.9.2.2, 10.11.0.0
Reporter: Myrna van Lunteren

This is not new, but while reviewing some of the 'disk full' messages
resulting from one of the long-running system tests, I realized that the text
of ERROR XSLA4 could be read, by people unfamiliar with derby and brave or in
a panic, as suggesting one to delete parts of the log directory:
ERROR XSLA4: Cannot write to the log, most likely the log is full. Please
delete unnecessary files. It is also possible that the file system is read
only, or the disk has failed, or some other problems with the media.
We've been fighting people deleting files from the log directory, and even if
this message text may not be the culprit, it certainly is open for
misinterpretation.
I think we need to change this message.
English language experts and native as well as non-native speakers are
particularly invited to chime in.
One suggestion is:
Error encountered when attempting to write the transaction recovery log.
Most likely the disk holding the recovery log is full. If the disk is full,
the only way to proceed is to free up space on the disk by either expanding
it or deleting files not related to Derby. It is also possible that the file
system and/or disk where the Derby transaction log resides is read only. The
error can also be encountered if the disk or filesystem has failed.

[jira] [Updated] (DERBY-6152) 10.10 upgrade and compatibility testing


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

Mike Matrigali updated DERBY-6152:
--

Component/s: Test

 10.10 upgrade and compatibility testing 
 

 Key: DERBY-6152
 URL: https://issues.apache.org/jira/browse/DERBY-6152
 Project: Derby
  Issue Type: Bug
  Components: Test
Reporter: Kathey Marsden
Assignee: Kathey Marsden
 Attachments: test10_8_tests10_10productjars.out


 I  am doing some upgrade  and test compatibility testing with 10.8 and am 
 using this issue for tracking tests and results.
 The first test was to try to run the 10.8 tests against the 10.10 product 
 jars to identify user compatibility issues and make sure we have adequate 
 release notes.
 Output of this initial run  attached as test10_8_tests10_10productjars.out
 The run failed miserably because of cascade failures, lock timeouts and 
 failure to cleanup. These are general test and test framework issues that 
 best  be addressed before analyzing failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6149) Long wait when 10.8 lang.SequenceGeneratorTest is run against 10.10 jars


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

Mike Matrigali updated DERBY-6149:
--

Component/s: Test

 Long wait  when 10.8 lang.SequenceGeneratorTest is run against 10.10 jars
 -

 Key: DERBY-6149
 URL: https://issues.apache.org/jira/browse/DERBY-6149
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.1
Reporter: Kathey Marsden

 Using the 10.8 testing jar and the 10.10 product jars the 10.8 test 
 lang.SequenceGeneratorTest  has multiple failures and then hangs after 
 test_07_dropSequence fails.
 To reproduce put the 10.8 derbyTesting.jar (latest on 10.8 branch) and 
 10.10.1.1  product jars in your classpath and run the junit test 
 org.apache.derbyTesting.functionTests.tests.lang.SequenceGeneratorTest.
 ++ java -Xmx512M -Xms512M -Dderby.tests.debug=true -Dderby.tests.trace=true 
 -Dderby.tests.basePort=1630 '-DderbyTesting.
 oldReleasePath=C:\cygwin\svnreleases\jars' junit.textui.TestRunner 
 org.apache.derbyTesting.functionTests.tests.lang.Sequ
 enceGeneratorTest
 ++ tee rju.out
 DEBUG: {TC@55923149} basePort=1630, bogusPort=1631, jmxPort=1632
 DEBUG: {TC@55937944} basePort=1630, bogusPort=1631, jmxPort=1633
 .
 test_01_basic DEBUG: Preparing statement:
 create sequence seq_01
 DEBUG: Preparing statement:
 select currentvalue from sys.syssequences seq, sys.sysschemas s where 
 s.schemaname = ? and seq.sequencename = ?
 and s.schemaid = seq.schemaid
 DEBUG: Preparing statement:
 values( next value for TEST_DBO.SEQ_01 )
 DEBUG: Preparing statement:
 select currentvalue from sys.syssequences seq, sys.sysschemas s where 
 s.schemaname = ? and seq.sequencename = ?
 and s.schemaid = seq.schemaid
 used 723 ms F.
 test_02_boundary used 323 ms E.
 test_03_nonCycling used 315 ms E.
 test_04_reboot DEBUG: Preparing statement:
 create sequence seq_04
 DEBUG: Preparing statement:
 values( next value for TEST_DBO.SEQ_04 )
 DEBUG: Preparing statement:
 select currentvalue from sys.syssequences seq, sys.sysschemas s where 
 s.schemaname = ? and seq.sequencename = ?
 and s.schemaid = seq.schemaid
 used 383 ms F.
 test_05_concurrency DEBUG: Preparing statement:
 create sequence seq_05
 DEBUG: Preparing statement:
 grant usage on sequence seq_05 to public
 DEBUG: Preparing statement:
 values( next value for TEST_DBO.SEQ_05 )
 DEBUG: Preparing statement:
 select currentvalue from sys.syssequences seq, sys.sysschemas s where 
 s.schemaname = ? and seq.sequencename = ?
 and s.schemaid = seq.schemaid
 used 427 ms F.
 test_06_bigStepSize used 306 ms E.
 test_07_dropSequence DEBUG: Preparing statement:
 create sequence seq_07
 DEBUG: Preparing statement:
 values( next value for TEST_DBO.SEQ_07 )
 DEBUG: Preparing statement:
 select currentvalue from sys.syssequences seq, sys.sysschemas s where 
 s.schemaname = ? and seq.sequencename = ?
 and s.schemaid = seq.schemaid
 used 330 ms F  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6128) Examine Derby classes to determine if we need to add serialVersionUID to any of them


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

Mike Matrigali commented on DERBY-6128:
---

are there any more outstanding for this issue?

 Examine Derby classes to determine if we need to add serialVersionUID to any 
 of them
 

 Key: DERBY-6128
 URL: https://issues.apache.org/jira/browse/DERBY-6128
 Project: Derby
  Issue Type: Task
Reporter: Rick Hillegas
 Attachments: derby-6128-ecpds40.diff, SerializableLister.java


 The discussion on DERBY-6124 has raised the possibility that we may need to 
 add serialVersionUIDs to some serializable Derby classes. Without the 
 serialVersionUIDs, Derby may encounter deserialization errors on objects 
 which were serialized by one version of Derby or the JVM and then 
 deserialized by another version of Derby or the JVM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Mike Matrigali updated DERBY-6104:
--

Component/s: Build tools

 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
  Components: Build tools
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6128) Examine Derby classes to determine if we need to add serialVersionUID to any of them


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

Mike Matrigali updated DERBY-6128:
--

Component/s: JDBC

 Examine Derby classes to determine if we need to add serialVersionUID to any 
 of them
 

 Key: DERBY-6128
 URL: https://issues.apache.org/jira/browse/DERBY-6128
 Project: Derby
  Issue Type: Task
  Components: JDBC
Reporter: Rick Hillegas
 Attachments: derby-6128-ecpds40.diff, SerializableLister.java


 The discussion on DERBY-6124 has raised the possibility that we may need to 
 add serialVersionUIDs to some serializable Derby classes. Without the 
 serialVersionUIDs, Derby may encounter deserialization errors on objects 
 which were serialized by one version of Derby or the JVM and then 
 deserialized by another version of Derby or the JVM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5866) testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError: matching triggers need to be fired in orde


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

Mamta A. Satoor commented on DERBY-5866:


Backported changes to 10.9 with revision 1468479

  
 testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
  matching triggers need to be fired in order creation:1,NO CASCADE 
 BEFORE,DELETE,ROW
 -

 Key: DERBY-5866
 URL: https://issues.apache.org/jira/browse/DERBY-5866
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.10.1.1, 10.10.1.2
 Environment: Windows IBM 1.6 10.10.0.0 alpha - (1361856)
Reporter: Kathey Marsden
Assignee: Mamta A. Satoor
  Labels: derby_triage10_10
 Fix For: 10.11.0.0


 I saw this failure in the IBM nightlies on 7/15. The subsequent night did not 
 fail, so appears intermittent
 http://cloudsoft.usca.ibm.com/intranet/nightlies/derbywinvm/JarResults.2012-07-15/ibm16_suites.All/suites.All.out
 1) 
 testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
  matching triggers need to be fired in order creation:1,NO CASCADE 
 BEFORE,DELETE,ROW
   at 
 org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.assertFiringOrder(TriggerTest.java:560)
   at 
 org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.testFiringConstraintOrder(TriggerTest.java:500)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6069) Derby doesn't export the version number in its OSGI exported packages


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

Mike Matrigali updated DERBY-6069:
--

Component/s: Build tools

not sure what component is best, setting build tools.

 Derby doesn't export the version number in its OSGI exported packages
 -

 Key: DERBY-6069
 URL: https://issues.apache.org/jira/browse/DERBY-6069
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Affects Versions: 10.9.1.0, 10.8.3.0
Reporter: Christian Müller
  Labels: osgi
 Attachments: MANIFEST.MF


 Derby doesn't export the version number in its OSGI exported packages. See 
 the following exports:
 {noformat}
 karaf@root headers 259
 Apache Derby 10.8 (259)
 ---
 Manifest-Version = 1.0
 Ant-Version = Apache Ant 1.7.0
 Class-Path = derbyLocale_cs.jar derbyLocale_de_DE.jar derbyLocale_es.jar 
 derbyLocale_fr.jar derbyLocale_hu.jar derbyLocale_it.jar derbyLocal
 e_ja_JP.jar derbyLocale_ko_KR.jar derbyLocale_pl.jar derbyLocale_pt_BR.jar 
 derbyLocale_ru.jar derbyLocale_zh_CN.jar derbyLocale_zh_TW.jar
 Sealed = true
 Created-By = 2.4 (IBM Corporation)
 Bundle-Vendor = Apache Software Foundation
 Bundle-Activator = org.apache.derby.osgi.EmbeddedActivator
 Bundle-Name = Apache Derby 10.8
 Bundle-SymbolicName = derby
 Bundle-Version = 10.8.300.1405108
 Bundle-ManifestVersion = 2
 DynamicImport-Package =
 *
 Export-Package =
 org.apache.derby.authentication,
 org.apache.derby.database,
 org.apache.derby.io,
 org.apache.derby.jdbc,
 org.apache.derby.vti
 {noformat}
 {noformat}
 karaf@root headers 250
 Apache Derby 10.9 (250)
 ---
 Manifest-Version = 1.0
 Ant-Version = Apache Ant 1.7.1
 Class-Path = derbyLocale_cs.jar derbyLocale_de_DE.jar derbyLocale_es.jar 
 derbyLocale_fr.jar derbyLocale_hu.jar derbyLocale_it.jar derbyLocal
 e_ja_JP.jar derbyLocale_ko_KR.jar derbyLocale_pl.jar derbyLocale_pt_BR.jar 
 derbyLocale_ru.jar derbyLocale_zh_CN.jar derbyLocale_zh_TW.jar
 Sealed = true
 Created-By = 20.6-b01-415 (Apple Inc.)
 Bundle-Vendor = Apache Software Foundation
 Bundle-Activator = org.apache.derby.osgi.EmbeddedActivator
 Bundle-Name = Apache Derby 10.9
 Bundle-SymbolicName = derby
 Bundle-Version = 10.9.100.1344872
 Bundle-ManifestVersion = 2
 DynamicImport-Package =
 *
 Export-Package =
 org.apache.derby.authentication,
 org.apache.derby.database,
 org.apache.derby.io,
 org.apache.derby.jdbc,
 org.apache.derby.vti
 {noformat}
 This leads to problems, if other bundles imports derby packages with a 
 specific version or version range (like spring-jdbc do):
 {noformat}
 karaf@root headers 251
 Spring JDBC (251)
 -
 Manifest-Version = 1.0
 ...
 Import-Package =
 ...
 org.apache.derby.impl.io;resolution:=optional;version=[10.5.0, 
 11.0.0),
 org.apache.derby.jdbc;resolution:=optional;version=[10.5.0, 11.0.0),
 ...
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6020) Issue a clearer syntax error message for use of LIKE with a numeric column


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

Mike Matrigali updated DERBY-6020:
--

Component/s: SQL

 Issue a clearer syntax error message for use of LIKE with a numeric column
 --

 Key: DERBY-6020
 URL: https://issues.apache.org/jira/browse/DERBY-6020
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Affects Versions: 10.9.1.0
Reporter: Bryan Pendleton

 I tried to use 'LIKE' with a numeric column, and the message was quite 
 confusing:
 ij version 10.9
 ij connect 'jdbc:derby:brydb;create=true';
 WARNING 01J01: Database 'brydb' not created, connection made to existing 
 database instead.
 ij drop table bry;
 0 rows inserted/updated/deleted
 ij CREATE TABLE bry( col1 varchar(10), JOBNUMBER INTEGER default 0);
 0 rows inserted/updated/deleted
 ij select * from bry where col1 like '%' or JobNumber like '%';
 ERROR 42884: No authorized routine named 'LIKE' of type 'FUNCTION' having 
 compatible arguments was found.
 ij quit;
 It would have been much easier to diagnose my problem if the message had said 
 something like:
 ERROR x: Operator 'LIKE' must be used with a character expression, but 
 argument 'JobNumber' is of type 'INTEGER'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6019) hang after connect reset error in (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878


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

Mike Matrigali updated DERBY-6019:
--

Bug behavior facts: Regression Test Failure

 hang after connect reset error in 
 (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878
 ---

 Key: DERBY-6019
 URL: https://issues.apache.org/jira/browse/DERBY-6019
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.10.1.1
 Environment: windows XP with ibm 1.5 SR 15
Reporter: Myrna van Lunteren
 Attachments: testRepL3p5DERBY_3878.jar


 I saw a hang in the test 
 (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878
  against trunk:
 10.10.0.0 alpha - (1423738), with the following stack trace:
 (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878
  java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:197)
   at java.net.SocketInputStream.read(SocketInputStream.java:116)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown 
 Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown 
 Source)
   at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown 
 Source)
   at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source)
   at 
 org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:608)
   at 
 org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerStart(NetworkServerTestSetup.java:679)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.pingServer(ReplicationRun.java:2162)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.startServer(ReplicationRun.java:1951)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878(ReplicationRun_Local_3_p5.java:100)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:619)
   at junit.framework.TestCase.runTest(TestCase.java:164)
   at junit.framework.TestCase.runBare(TestCase.java:130)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:246)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:120)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.textui.TestRunner.doRun(TestRunner.java:121)
   at junit.textui.TestRunner.start(TestRunner.java:185)
   at junit.textui.TestRunner.main(TestRunner.java:143)
 java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:197)
   at java.net.SocketInputStream.read(SocketInputStream.java:116)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown 
 Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown 
 Source)
   at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown 
 Source)
   at org.apache.derby.drda.NetworkServerControl.ping(Unknown

[jira] [Commented] (DERBY-6011) Derby performs very badly (seems to deadlock and timeout) in very simple multi-threaded tests

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

Mike Matrigali commented on DERBY-6011:
---

is there any more work planned for this issue. looks fixed in trunk, 10.10 and
10.9 to me, unless more fixes are planned.
Karl were you able to test your application with the change?

Derby performs very badly (seems to deadlock and timeout) in very simple
multi-threaded tests
-

Key: DERBY-6011
URL: https://issues.apache.org/jira/browse/DERBY-6011
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0
Environment: Lenovo laptop with SSD's, Windows 7, 64-bit, Sun JDK
1.6.xx
Reporter: Karl Wright
Attachments: derby.log, force-specific-index.diff, manifoldcf.log,
prefer-unique-index-v1.diff, prefer-unique-index-v2.diff

The Apache ManifoldCF project supports Derby as one of its underlying
databases. Simple tests, however, demonstrate that Derby is apparently
deadlocking and timing out repeatedly under multi-thread conditions. This
problem is long-standing, and is not exhibited by any other database
ManifoldCF supports, and makes a simple test take between 6x and 12x as long.
There is a trivial test with demonstrates the problem vs. other databases.
Please do the following (once you have java 1.6+, svn 1.7+, and ant 1.7+
available):
(1) Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
(2) Run the following ant target to download the dependencies: ant
make-core-deps
(3) Run the Derby test: ant run-rss-tests-derby . Note the time required -
at least 180 seconds, can be up to 360 seconds.
(4) Run the equivalent HSQLDB test: ant run-rss-tests-HSQLDB. This test
takes about 31 seconds to run.
The output of the Derby test can be found in the directory
tests/rss/test-derby-output. Have a look at manifoldcf.log, where all
long-running queries are reported. Derby.log is also included, which shows
only that during the test's cleanup phase the database is deleted before it
is shutdown, which is not pertinent to the performance issue.
I am available to assist with ManifoldCF, if that seems to be required.

[jira] [Updated] (DERBY-5980) Extremely slow roll forward when booting database that wasn't properly closed


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

Mike Matrigali updated DERBY-5980:
--

Component/s: Store

 Extremely slow roll forward when booting database that wasn't properly closed
 -

 Key: DERBY-5980
 URL: https://issues.apache.org/jira/browse/DERBY-5980
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.9.1.0
 Environment: Windows 7, Embedded mode
Reporter: Igor Sereda

 Reproduction sequence:
 1. Open database in embedded mode
 2. Run a considerably large transaction - for example, one that creates 10 - 
 20 MB of db logs
 3. Commit
 4. Do NOT close the Connection
 5. Exit the application (through System.exit() for example)
 6. Restart the application and open the database
 Observed:
 Opening connection is extremely slow. It takes up 30- 60 seconds on the 10-20 
 MB transaction, and for larger transactions it takes forever.
 Looking at the process with FileMon utility, I can see that redo log files 
 are mostly read *1 byte at a time*. :(
  I bet you can improve the performance 100-fold by getting the whole log into 
 memory first.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5979) ant release target creates a release.properties that has conflicting line endings so automatic checkin fails


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

Mike Matrigali updated DERBY-5979:
--

Component/s: Build tools

 ant release target creates a release.properties that has conflicting line 
 endings so automatic checkin fails
 

 Key: DERBY-5979
 URL: https://issues.apache.org/jira/browse/DERBY-5979
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Reporter: Kathey Marsden

 The ant release target  on Windows  creates release.properties with 
 inconsistent line endings that prevent checkin.
 This may be a configuration issue.  I have *.properties = 
 svn:eol-style=native which I think is correct but I could not diff or checkin 
 the file until I removed the dos line endings.  There are similar issues with 
 the release notes but because they are not checked in as part of the a script 
 we document how to fix them up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5980) Extremely slow roll forward when booting database that wasn't properly closed

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

Mike Matrigali commented on DERBY-5980:
---

posting an exact repro case would make it more likely the community would help
with this. It helps to make sure
what you are seeing is what others are seeing. For instance there is a big
difference between 10-20 MB of 1 byte
inserts vs 1 20 mb blob insert.

Extremely slow roll forward when booting database that wasn't properly closed
-

Key: DERBY-5980
URL: https://issues.apache.org/jira/browse/DERBY-5980
Project: Derby
Issue Type: Bug
Affects Versions: 10.9.1.0
Environment: Windows 7, Embedded mode
Reporter: Igor Sereda

Reproduction sequence:
1. Open database in embedded mode
2. Run a considerably large transaction - for example, one that creates 10 -
20 MB of db logs
3. Commit
4. Do NOT close the Connection
5. Exit the application (through System.exit() for example)
6. Restart the application and open the database
Observed:
Opening connection is extremely slow. It takes up 30- 60 seconds on the 10-20
MB transaction, and for larger transactions it takes forever.
Looking at the process with FileMon utility, I can see that redo log files
are mostly read *1 byte at a time*. :(
I bet you can improve the performance 100-fold by getting the whole log into
memory first.

[jira] [Updated] (DERBY-6011) Derby performs very badly (seems to deadlock and timeout) in very simple multi-threaded tests

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

Mike Matrigali updated DERBY-6011:
--

Component/s: SQL

Derby performs very badly (seems to deadlock and timeout) in very simple
multi-threaded tests
-

[jira] [Updated] (DERBY-5866) testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError: matching triggers need to be fired in order


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

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

Fix Version/s: 10.9.2.2
   10.10.1.2

  
 testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
  matching triggers need to be fired in order creation:1,NO CASCADE 
 BEFORE,DELETE,ROW
 -

 Key: DERBY-5866
 URL: https://issues.apache.org/jira/browse/DERBY-5866
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.10.1.1, 10.10.1.2
 Environment: Windows IBM 1.6 10.10.0.0 alpha - (1361856)
Reporter: Kathey Marsden
Assignee: Mamta A. Satoor
  Labels: derby_triage10_10
 Fix For: 10.10.1.2, 10.9.2.2, 10.11.0.0


 I saw this failure in the IBM nightlies on 7/15. The subsequent night did not 
 fail, so appears intermittent
 http://cloudsoft.usca.ibm.com/intranet/nightlies/derbywinvm/JarResults.2012-07-15/ibm16_suites.All/suites.All.out
 1) 
 testFiringConstraintOrder(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)junit.framework.AssertionFailedError:
  matching triggers need to be fired in order creation:1,NO CASCADE 
 BEFORE,DELETE,ROW
   at 
 org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.assertFiringOrder(TriggerTest.java:560)
   at 
 org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.testFiringConstraintOrder(TriggerTest.java:500)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6011) Derby performs very badly (seems to deadlock and timeout) in very simple multi-threaded tests

2013-04-16 Thread Karl Wright (JIRA)

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

Karl Wright commented on DERBY-6011:

I did confirm that the fix worked for ManifoldCF.

Derby performs very badly (seems to deadlock and timeout) in very simple
multi-threaded tests
-

[jira] [Updated] (DERBY-5952) Need a way to determine which indexes are not used over the course of a week


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

Mike Matrigali updated DERBY-5952:
--

Component/s: Store
 SQL

 Need a way to determine which indexes are not used over the course of a week
 

 Key: DERBY-5952
 URL: https://issues.apache.org/jira/browse/DERBY-5952
 Project: Derby
  Issue Type: Improvement
  Components: SQL, Store
Reporter: Dwight Carter
Priority: Minor

 We have a derby database used by a rather complex codebase.  Over time, 
 numerous indexes have been created on the tables.  We'd like to delete 
 indexes which are no longer used, but don't know how to determine that.  It 
 would be very useful if derby provided a way to get a list of indexes on a 
 database which have not been used in a period of time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5952) Need a way to determine which indexes are not used over the course of a week


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

Mike Matrigali commented on DERBY-5952:
---

Derby provides ways to log the execution plans of every query executed.  Then 
user could look at this out put and parse it to get 
the info.  There is overhead to this, and likely not what the request is 
looking for.

 Need a way to determine which indexes are not used over the course of a week
 

 Key: DERBY-5952
 URL: https://issues.apache.org/jira/browse/DERBY-5952
 Project: Derby
  Issue Type: Improvement
  Components: SQL, Store
Reporter: Dwight Carter
Priority: Minor

 We have a derby database used by a rather complex codebase.  Over time, 
 numerous indexes have been created on the tables.  We'd like to delete 
 indexes which are no longer used, but don't know how to determine that.  It 
 would be very useful if derby provided a way to get a list of indexes on a 
 database which have not been used in a period of time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5952) Need a way to determine which indexes are not used over the course of a week

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

Mike Matrigali commented on DERBY-5952:
---

Just some random thoughts on this:

Could add some sort of date to be associated with ddl objects. There are 2
interesting levels. Could track and maintain the info in the system catalogs
for each table and index. Or
could track and maintain at lowest level in each conglomerate. Or could could
create another table to track this.

Note this request does not want just last used as at the low levels that would
likely be updated on each insert also. So for this you want last used for a
non-insert/update/delete statement. If
you are going to do this, likely should also add a last used also.

Implementation should be careful to not cause too much overhead and/or lock
contention. Updating a system catalog can often interfere with other
operations in the system. For instance
a system doing 1 scans a second, should likely not trying to be updating
this value 1 times. Maybe this could only be done at compile time? Maybe
work on auto increment could
be leveraged to do quick system catalog type updates?

Need a way to determine which indexes are not used over the course of a week

Key: DERBY-5952
URL: https://issues.apache.org/jira/browse/DERBY-5952
Project: Derby
Issue Type: Improvement
Components: SQL, Store
Reporter: Dwight Carter
Priority: Minor

We have a derby database used by a rather complex codebase. Over time,
numerous indexes have been created on the tables. We'd like to delete
indexes which are no longer used, but don't know how to determine that. It
would be very useful if derby provided a way to get a list of indexes on a
database which have not been used in a period of time.

[jira] [Commented] (DERBY-5936) AllocPage.ReadContainerInfo throws ArrayIndexOutOfBoundsException at arraycopy


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

Mike Matrigali commented on DERBY-5936:
---

without more info, probably need to close this as can not reproduce.

 AllocPage.ReadContainerInfo throws ArrayIndexOutOfBoundsException at arraycopy
 --

 Key: DERBY-5936
 URL: https://issues.apache.org/jira/browse/DERBY-5936
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.6.1.0
 Environment: intel, windows XP, embedded driver, c3p0
Reporter: Yuan Yao

 The db may not be closed normally. It throws following exceptions as starting.
 logs:
 {code}
 Caused by: java.lang.ArrayIndexOutOfBoundsException
   at java.lang.System.arraycopy(Native Method)
   at 
 org.apache.derby.impl.store.raw.data.AllocPage.ReadContainerInfo(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.FileContainer.readHeader(Unknown Source)
   at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown Source)
   at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
  Source)
   at 
 org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openDroppedContainer(Unknown
  Source)
   at 
 org.apache.derby.impl.store.raw.xact.Xact.openDroppedContainer(Unknown Source)
   at 
 org.apache.derby.impl.store.raw.data.ContainerBasicOperation.findContainer(Unknown
  Source)
   at 
 org.apache.derby.impl.store.raw.data.ContainerBasicOperation.needsRedo(Unknown
  Source)
   at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
   at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
   at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown 
 Source)
   at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown 
 Source)
   at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
   at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown
  Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown
  Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown
  Source)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown 
 Source)
   ... 24 more
 {code}
 I'd like to upload data files if necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5936) AllocPage.ReadContainerInfo throws ArrayIndexOutOfBoundsException at arraycopy


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

Mike Matrigali updated DERBY-5936:
--

Component/s: Store

 AllocPage.ReadContainerInfo throws ArrayIndexOutOfBoundsException at arraycopy
 --

 Key: DERBY-5936
 URL: https://issues.apache.org/jira/browse/DERBY-5936
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.6.1.0
 Environment: intel, windows XP, embedded driver, c3p0
Reporter: Yuan Yao

 The db may not be closed normally. It throws following exceptions as starting.
 logs:
 {code}
 Caused by: java.lang.ArrayIndexOutOfBoundsException
   at java.lang.System.arraycopy(Native Method)
   at 
 org.apache.derby.impl.store.raw.data.AllocPage.ReadContainerInfo(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.FileContainer.readHeader(Unknown Source)
   at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(Unknown 
 Source)
   at org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown Source)
   at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown 
 Source)
   at 
 org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
  Source)
   at 
 org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openDroppedContainer(Unknown
  Source)
   at 
 org.apache.derby.impl.store.raw.xact.Xact.openDroppedContainer(Unknown Source)
   at 
 org.apache.derby.impl.store.raw.data.ContainerBasicOperation.findContainer(Unknown
  Source)
   at 
 org.apache.derby.impl.store.raw.data.ContainerBasicOperation.needsRedo(Unknown
  Source)
   at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
   at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
   at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown 
 Source)
   at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown 
 Source)
   at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
   at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
   at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown 
 Source)
   at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown
  Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown
  Source)
   at 
 org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown
  Source)
   at 
 org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown 
 Source)
   ... 24 more
 {code}
 I'd like to upload data files if necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Knut Anders Hatlen updated DERBY-6185:
--

Component/s: (was: JDBC)
 SQL

My guess is that name LIKE 'Col1' gets optimized to name = 'Col1', which fails 
because Derby does not support equality comparisons between CLOBs. There is 
code in place to prevent this optimization for CLOBs, for example in 
LikeEscapeOperatorNode.preprocess():

/* Don't try to optimize for (C)LOB type since it doesn't allow 
 * comparison.
 * RESOLVE: should this check be for LONG VARCHAR also?
 */
if (receiver.getTypeId().getSQLTypeName().equals(CLOB)) 
{
return this;
}

But maybe the query in question takes a different code path and doesn't bump 
into this check.

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5902) Test Derby OSGi bundle


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

Mike Matrigali updated DERBY-5902:
--

  Component/s: Test
Affects Version/s: 10.11.0.0

 Test Derby OSGi bundle
 --

 Key: DERBY-5902
 URL: https://issues.apache.org/jira/browse/DERBY-5902
 Project: Derby
  Issue Type: Task
  Components: Test
Affects Versions: 10.11.0.0
Reporter: Mohamed Nufail
Assignee: Mohamed Nufail
Priority: Minor
 Attachments: OSGiTest.java, PlumbingOSGiTest.java, pom.xml, Probe.java


 There is a lack of tests that test Derby's support for OSGi. I hope to 
 provide some integration tests to Derby OSGi bundle.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5895) Fix/test/document http and https sub protocols


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

Mike Matrigali updated DERBY-5895:
--

Component/s: Services

 Fix/test/document http and https sub protocols  
 

 Key: DERBY-5895
 URL: https://issues.apache.org/jira/browse/DERBY-5895
 Project: Derby
  Issue Type: Improvement
  Components: Services
Reporter: Kathey Marsden

 In the derby thread some time ago 
 http://old.nabble.com/Bug-with-http-sub-protocol--td31889839.html it came to 
 light that the Derby http and https sub protoocols  are not documented and 
 behave oddly.
 We should decide on a definitive format  behavior for these sub protocols, 
 test and document the feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5882) Test for methods in CPFile


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

Mike Matrigali updated DERBY-5882:
--

Component/s: Test

 Test for methods in CPFile
 --

 Key: DERBY-5882
 URL: https://issues.apache.org/jira/browse/DERBY-5882
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-5882) Test for methods in CPFile


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

Mike Matrigali commented on DERBY-5882:
---

any more work planned on this?

 Test for methods in CPFile
 --

 Key: DERBY-5882
 URL: https://issues.apache.org/jira/browse/DERBY-5882
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5879) Fix problems in English messages disclosed by a localization audit.

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

Mike Matrigali updated DERBY-5879:
--

Component/s: SQL

setting sql component, don't know anything better for message changes. really
likely affects all components.

Fix problems in English messages disclosed by a localization audit.
---

Key: DERBY-5879
URL: https://issues.apache.org/jira/browse/DERBY-5879
Project: Derby
Issue Type: Task
Components: SQL
Affects Versions: 10.10.1.1
Reporter: Rick Hillegas
Assignee: Rick Hillegas
Attachments: derby-5879-01-aa-multiLineToolsMessages.diff,
derby-5879-02-aa-MessageIdmessages.diff,
derby-5879-03-aa-SQLStatemessages.diff, derby-5879-04-aa-DRDAmessages.diff,
derby-5879-05-aa-commentArguments.diff,
derby-5879-05-ab-commentArguments.diff, derby-5879-06-aa-doNotTranslate.diff,
derby-5879-06-ab-doNotTranslate.diff,
derby-5879-07-aa-commentQueryPlanStrings.diff,
derby-5879-08-aa-explainContext.diff, derby-5879-09-aa-spelling.diff,
derby-5879-09-ab-spelling.diff, derby-5879-10-aa-deleteUnused.diff,
derby-5879-11-aa-deleteUntranslatable.diff, derby-5879-j9_f_outparams.diff

The team which is localizing the 10.9 messages would like to audit our
existing messages to ensure that they are easy to translate. A quick glance
at their audit results shows many issues in the following categories:
1) Multi-line messages whose formatting confuses the translators. Translators
tend to be language experts and not experts in the arcana of how Java
properties files are formatted. I am hoping that these issues can be
addressed by simply prefixing the multi-line messages with comments,
explaining the arcane formatting.
2) Grammar, punctuation, and capitalization problems. I think we should just
clean these up.
I am filing this issue as a place to hold patches which address issues raised
by the localization audit.

[jira] [Commented] (DERBY-6128) Examine Derby classes to determine if we need to add serialVersionUID to any of them


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

Rick Hillegas commented on DERBY-6128:
--

Hi Mike: It don't think that derby-6128-ecpds40 has been checked in yet.

 Examine Derby classes to determine if we need to add serialVersionUID to any 
 of them
 

 Key: DERBY-6128
 URL: https://issues.apache.org/jira/browse/DERBY-6128
 Project: Derby
  Issue Type: Task
  Components: JDBC
Reporter: Rick Hillegas
 Attachments: derby-6128-ecpds40.diff, SerializableLister.java


 The discussion on DERBY-6124 has raised the possibility that we may need to 
 add serialVersionUIDs to some serializable Derby classes. Without the 
 serialVersionUIDs, Derby may encounter deserialization errors on objects 
 which were serialized by one version of Derby or the JVM and then 
 deserialized by another version of Derby or the JVM.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5863) Running Derby Network Server in an OSGi container


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

Mike Matrigali updated DERBY-5863:
--

Component/s: Build tools

marking osgi related issues as build tool component, unless someone has better 
suggestion.

 Running Derby Network Server in an OSGi container
 -

 Key: DERBY-5863
 URL: https://issues.apache.org/jira/browse/DERBY-5863
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Reporter: Pieter
Priority: Minor

 I try to deploy the derby and derbynet bundles in an OSGi container and use 
 it as a Derby Network Server. The feature seems to be there, but I did not 
 get it working right away. I also could not find any documentation so I 
 wonder if anyone has actually done it? With some tweaks I got it working, but 
 I think some changes are needed. 
 The derby bundle does have an EmbeddedActivator that attempts to bootstrap 
 NetworkServerControlImpl (via DRDAServerStarter) to get an up and running 
 Derby Network Server. However, the derbynet jar containing 
 NetworkServerControlImpl is not an OSGi bundle. 
 So my first step was to wrap the derbynet jar and make it a bundle. That was 
 not enough, because NetworkServerControlImpl used derby internal classes 
 which are not exported by the derby bundle. I got around that by creating a 
 fragment-bundle that exports packages needed by derbynet:
 Fragment-Host: derby
 Export-Package: org.apache.derby.catalog,
   org.apache.derby.iapi.db,
   org.apache.derby.iapi.error,
   org.apache.derby.iapi.jdbc,
   org.apache.derby.iapi.services.i18n,
   org.apache.derby.iapi.services.info,
   org.apache.derby.iapi.services.io,
   org.apache.derby.iapi.services.jmx,
   org.apache.derby.iapi.services.monitor,
   org.apache.derby.iapi.services.property,
   org.apache.derby.iapi.services.stream,
   org.apache.derby.iapi.store.access.xa,
   org.apache.derby.iapi.tools.i18n,
   org.apache.derby.iapi.util,
   org.apache.derby.impl.jdbc,
   org.apache.derby.mbeans,
   org.apache.derby.security
 Import-Package: org.apache.derby.impl.drda
 With this fragment I am able to connect the the Derby Network Server.
 Exporting these packages is not nice and I think a more elegant solution is 
 needed. Merging the derbynet jar into the derby jar would fix it, again not a 
 solution that will get much votes I think. Make derbynet a fragment of derby?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5857) Test for methods in BrokeredStatement


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

Mike Matrigali updated DERBY-5857:
--

Component/s: Test

 Test for methods in BrokeredStatement
 -

 Key: DERBY-5857
 URL: https://issues.apache.org/jira/browse/DERBY-5857
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Reporter: Siddharth Srivastava
Priority: Minor



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5853) Test for methods in BrokeredPreparedStatement


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

Mike Matrigali updated DERBY-5853:
--

Component/s: Test

 Test for methods in BrokeredPreparedStatement
 -

 Key: DERBY-5853
 URL: https://issues.apache.org/jira/browse/DERBY-5853
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor
 Attachments: brokeredps.patch, pstest.patch


 According to emma code coverage report, several methods of 
 BrokeredPreparedStatement are uncovered. 
 This issue deals with adding tests for those methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5850) store/rollForwardRecovery fails with java.lang.ArrayIndexOutOfBoundsException


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

Mike Matrigali updated DERBY-5850:
--

   Component/s: Test
Bug behavior facts: Regression Test Failure

 store/rollForwardRecovery fails with java.lang.ArrayIndexOutOfBoundsException
 -

 Key: DERBY-5850
 URL: https://issues.apache.org/jira/browse/DERBY-5850
 Project: Derby
  Issue Type: Bug
  Components: Test
 Environment: ava Version:1.7.0
 Java Vendor: IBM Corporation
 Java home:   /local1/cloudtst/dev/src/ibm17/jre
 OS name: Linux
 OS architecture: x86
 OS version:  2.6.32-220.7.1.el6.i686
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.7
 java.runtime.version: pxi3270sr1-20120330_01 (SR1)
 java.fullversion: JRE 1.7.0 IBM J9 2.6 Linux x86-32 20120322_106209 (JIT 
 enabled, AOT enabled)
 J9VM - R26_Java726_SR1_20120322_1720_B106209
 JIT  - r11_20120322_22976
 GC   - R26_Java726_SR1_20120322_1720_B106209
 J9CL - 20120322_106209
Reporter: Kathey Marsden
 Attachments: derby.log


 On trunk IBM 1.7 run on July 5 rolForwardRecovery failed with the following 
 diff ...
 Failure Details:
 * Diff file derbyall/storeall/storemore/rollForwardRecovery.diff
 *** Start: rollForwardRecovery jdk1.7.0 storeall:storemore 2012-07-06 
 00:33:18 ***
 730a731,732
  ERROR XJ040: Failed to start database 'wombat' with class loader ,  see 
  the next exception for details.
  ERROR XJ001: Java exception: ': java.lang.ArrayIndexOutOfBoundsException'.
 734 del
  A   
 |B
   
  |C   
 
 |D
|E 
   
 
 735 del
  
 
 736 del
  1   
|2
   
 |3   

 |4   
|5
   
 
 737 del
  10  
|20   
   
 |30  

 |40  
|50   
   
 
 738 del
 
 Unfortunately things didn't get pushed out to Apache. I will follow up with 
 the stack trace

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5850) store/rollForwardRecovery fails with java.lang.ArrayIndexOutOfBoundsException


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

Mike Matrigali updated DERBY-5850:
--

Affects Version/s: 10.10.1.1

 store/rollForwardRecovery fails with java.lang.ArrayIndexOutOfBoundsException
 -

 Key: DERBY-5850
 URL: https://issues.apache.org/jira/browse/DERBY-5850
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.1
 Environment: ava Version:1.7.0
 Java Vendor: IBM Corporation
 Java home:   /local1/cloudtst/dev/src/ibm17/jre
 OS name: Linux
 OS architecture: x86
 OS version:  2.6.32-220.7.1.el6.i686
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.7
 java.runtime.version: pxi3270sr1-20120330_01 (SR1)
 java.fullversion: JRE 1.7.0 IBM J9 2.6 Linux x86-32 20120322_106209 (JIT 
 enabled, AOT enabled)
 J9VM - R26_Java726_SR1_20120322_1720_B106209
 JIT  - r11_20120322_22976
 GC   - R26_Java726_SR1_20120322_1720_B106209
 J9CL - 20120322_106209
Reporter: Kathey Marsden
 Attachments: derby.log


 On trunk IBM 1.7 run on July 5 rolForwardRecovery failed with the following 
 diff ...
 Failure Details:
 * Diff file derbyall/storeall/storemore/rollForwardRecovery.diff
 *** Start: rollForwardRecovery jdk1.7.0 storeall:storemore 2012-07-06 
 00:33:18 ***
 730a731,732
  ERROR XJ040: Failed to start database 'wombat' with class loader ,  see 
  the next exception for details.
  ERROR XJ001: Java exception: ': java.lang.ArrayIndexOutOfBoundsException'.
 734 del
  A   
 |B
   
  |C   
 
 |D
|E 
   
 
 735 del
  
 
 736 del
  1   
|2
   
 |3   

 |4   
|5
   
 
 737 del
  10  
|20   
   
 |30  

 |40  
|50   
   
 
 738 del
 
 Unfortunately things didn't get pushed out to Apache. I will follow up with 
 the stack trace

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5844) Code coverage for org.apache.derby.impl.io


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

Mike Matrigali updated DERBY-5844:
--

Component/s: Test

 Code coverage for org.apache.derby.impl.io
 --

 Key: DERBY-5844
 URL: https://issues.apache.org/jira/browse/DERBY-5844
 Project: Derby
  Issue Type: Improvement
  Components: Test
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor
 Attachments: derby_server_initial.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5843) Remove unused method in CharacterStreamDescriptor


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

Mike Matrigali updated DERBY-5843:
--

Component/s: Services

 Remove unused method in CharacterStreamDescriptor
 -

 Key: DERBY-5843
 URL: https://issues.apache.org/jira/browse/DERBY-5843
 Project: Derby
  Issue Type: Sub-task
  Components: Services
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor
 Attachments: Derby5843.patch


 Following function is not used:
 public String toString()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5842) Remove unused method in DRDAServerStarter class


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

Mike Matrigali updated DERBY-5842:
--

Component/s: Network Server

 Remove unused method in DRDAServerStarter class
 ---

 Key: DERBY-5842
 URL: https://issues.apache.org/jira/browse/DERBY-5842
 Project: Derby
  Issue Type: Sub-task
  Components: Network Server
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor
 Attachments: DRDAServerStarter.patch


 Following method is unused in DRDAServerStarter class:
 public void setStartInfo(InetAddress listenAddress, int portNumber,String 
 userName, String password,
  PrintWriter consoleWriter)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5824) testOSReadOnly fails with k.AssertionFailedError: expected an error indicating the db is readonly on HP java 1.6


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

Mike Matrigali updated DERBY-5824:
--

Component/s: Test

 testOSReadOnly fails with k.AssertionFailedError: expected an error 
 indicating the db is readonly on HP java 1.6
 

 Key: DERBY-5824
 URL: https://issues.apache.org/jira/browse/DERBY-5824
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.5.3.1
 Environment: HP Itanium Java version 1.6.0.14
 OS name: HP-UX
 OS architecture: IA64N
 OS version:  B.11.23
Reporter: Kathey Marsden

 This failure was reported running suites.All on HP. Read only database is 
 apparently not read only.
 1) 
 testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError:
  expected an error indicating the db is readonly
 at 
 org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.assertExpectedInsertBehaviour(OSReadOnlyTest.java:261)
 at 
 org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:139)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 2) 
 testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError:
  Failed to copy directory from 
 /local1/derbytest/test/system/singleUse/oneuse4b to 
 /local1/derbytest/test/system/singleUse/readOnly
 at 
 org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.copyDatabaseOnOS(OSReadOnlyTest.java:282)
 at 
 org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:131)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
 at junit.extensions.TestSetup.run(TestSetup.java:25)
 FAILURES!!!
 Tests run: 11145,  Failures: 2,  Errors: 0
 bash-4.0#

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5738) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to the OS pages in the last extent


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

Mike Matrigali updated DERBY-5738:
--

Component/s: Store

 SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE only returns to the OS pages in the 
 last extent
 ---

 Key: DERBY-5738
 URL: https://issues.apache.org/jira/browse/DERBY-5738
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 
 10.6.2.1, 10.7.1.1, 10.8.2.2
Reporter: Mike Matrigali

 It looks like inplace compress only gives back space to the OS from the empty 
 pages in the last extent of the file.  If the defrag and purge phases are
 run they can reclaim internal space in the form of free pages to be used for 
 future inserts, but free pages before last extent are not returned to 
 OS.   
 Only current workaround is to use SYSCS_UTIL.SYSCS_COMPRESS_TABLE instead.
 In filecontainer.java!compressContainer there is a comment with steps to be 
 performed, but no code exists for step 5 and 6:
   This is outline of the algorithm used in compressing the container.
   Until a non free page is found loop, in each loop return to the OS
  all space at the end of the container occupied by free pages, 
 including
  the allocation page itself if all of it's pages are free.
   1) Find last 2 allocation pages in container (last if there is only 
 one).
   2) invalidate the allocation information cached by the container.
  Without the cache no page can be gotten from the container.  Pages
  already in the page cache are not affected.  Thus by latching the
  allocPage and invalidating the allocation cache, this NTT blocks out
  all page gets from this container until it commits.
   3) the allocPage determines which pages can be released to the OS,
  mark that in its data structure (the alloc extent).  Mark the
  contiguous block of nallocated/free pages at the end of the file
  as unallocated.  This change is associated with the NTT.
   4) The NTT calls the OS to deallocate the space from the file.  Note
  that the system can handle being booted and asked to get an allocated
  page which is past end of file, it just extends the file 
 automatically.
   5) If freeing all space on the alloc page, and there is more than one
  alloc page, then free the alloc page - this requires an update to the
  previous alloc page which the loop has kept latched also.
   6) if the last alloc page was deleted, restart loop at #1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5684) Explore possible istat daemon improvements and optimizations


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

Mike Matrigali updated DERBY-5684:
--

Component/s: Store
 SQL

 Explore possible istat daemon improvements and optimizations
 

 Key: DERBY-5684
 URL: https://issues.apache.org/jira/browse/DERBY-5684
 Project: Derby
  Issue Type: Task
  Components: SQL, Store
Reporter: Kristian Waagan
 Attachments: derby-istat-exploration-1.diff, 
 derby-istat-exploration-2.diff, derby-istat-exploration-3.diff, 
 derby-istat-exploration.diff


 A task tracking some experiments on the istat daemon and the statistics 
 update code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5673) backupRestore1 fails with Error copying file (during backup) ... logctrl.dat


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

Mike Matrigali updated DERBY-5673:
--

Component/s: Test

  backupRestore1 fails with Error copying file (during backup)  ... logctrl.dat
 --

 Key: DERBY-5673
 URL: https://issues.apache.org/jira/browse/DERBY-5673
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.9.1.0
 Environment: Windows IBM 1.5
Reporter: Kathey Marsden

 Saw this new failure in the IBM runs March 24
 http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/1304978-derbyall_diff.txt
  Diff file derbyall/storeall/storemore/backupRestore1.diff
 *** Start: backupRestore1 jdk1.5.0 storeall:storemore 2012-03-24 20:29:54 ***
 7 del
  database shutdown properly
 8 del
  database shutdown properly
 8a7,16
  FAIL -- unexpected exception: java.sql.SQLException: Failed to start 
  database 'wombat' with class loader ,  see the next exception for 
  details.
  SQLSTATE(XJ040):SQLSTATE(XBM0I):
  java.sql.SQLException: Directory 
  D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\wombat
   cannot be removed.
  Caused by: ERROR XBM0I: Directory 
  D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\wombat
   cannot be removed.
   ... 9 more
  FAIL -- unexpected exception: java.sql.SQLException: Error copying file 
  (during backup) from 
  D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\wombat\log\log.ctrl
   to extinout\mybackup\wombat\log\log.ctrl.
  SQLSTATE(XSRS5):
  java.sql.SQLException: Error copying file (during backup) from 
  D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\wombat\log\log.ctrl
   to extinout\mybackup\wombat\log\log.ctrl.
  Caused by: ERROR XSRS5: Error copying file (during backup) from 
  D:\jartest\JarResults.2012-03-24\ibm15_derbyall\derbyall\storeall\storemore\backupRestore1\wombat\log\log.ctrl
   to extinout\mybackup\wombat\log\log.ctrl.
   ... 5 more
 Test Failed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5674) Improve Derby's Code Coverage - GSoC 2012 Project


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

Mike Matrigali updated DERBY-5674:
--

Component/s: Test

 Improve Derby's Code Coverage - GSoC 2012 Project
 -

 Key: DERBY-5674
 URL: https://issues.apache.org/jira/browse/DERBY-5674
 Project: Derby
  Issue Type: Task
  Components: Test
Reporter: Tiago R. Espinha
Priority: Minor
  Labels: gsoc2012

 This year's edition of Google Summer of Code includes, once again, the Apache 
 Software Foundation. As I did last year, I'm offering to mentor a student 
 again this year, this time for a different project.
 For this project, the student is required to have some basic knowledge of 
 JUnit and of how code coverage works. Currently some packages of Derby have 
 poor code coverage. Emma defines the minimum acceptable code coverage as 70% 
 and some engineers suggest a minimum of 80% is desired.
 Students are invited to look at [1] to get familiar with Emma's code coverage 
 reports on Derby.
 A few suggestions of classes that require improvements are:
 - org.apache.derby.client.net - importnat package with poor coverage.
 - org.apache.derby.iapi.types - several classes not tested at all and others 
 with poor coverage.
 - org.apache.derby.iapi.jdbc - could use extensive improvements.
 - org.apache.derby.impl.io - another package with poor coverage.
 The candidate students are also expected to come up with their own schedule 
 for the tests they plan on creating and to discuss this schedule publicly on 
 the mailing list.
 After a student applies, a small interview will be conducted on IRC as part 
 of the ASF's evaluation process.
 [1] - http://dbtg.foundry.sun.com/derby/test/coverage/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6019) hang after connect reset error in (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878


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

Mike Matrigali updated DERBY-6019:
--

Component/s: Test

 hang after connect reset error in 
 (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878
 ---

 Key: DERBY-6019
 URL: https://issues.apache.org/jira/browse/DERBY-6019
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.1
 Environment: windows XP with ibm 1.5 SR 15
Reporter: Myrna van Lunteren
 Attachments: testRepL3p5DERBY_3878.jar


 I saw a hang in the test 
 (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878
  against trunk:
 10.10.0.0 alpha - (1423738), with the following stack trace:
 (emb)replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878
  java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:197)
   at java.net.SocketInputStream.read(SocketInputStream.java:116)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown 
 Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown 
 Source)
   at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown 
 Source)
   at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source)
   at 
 org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:608)
   at 
 org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerStart(NetworkServerTestSetup.java:679)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.pingServer(ReplicationRun.java:2162)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.startServer(ReplicationRun.java:1951)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p5.testReplication_Local_3_p5_DERBY_3878(ReplicationRun_Local_3_p5.java:100)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:619)
   at junit.framework.TestCase.runTest(TestCase.java:164)
   at junit.framework.TestCase.runBare(TestCase.java:130)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.runBare(ReplicationRun.java:246)
   at junit.framework.TestResult$1.protect(TestResult.java:106)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.framework.TestResult.run(TestResult.java:109)
   at junit.framework.TestCase.run(TestCase.java:120)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.framework.TestResult.runProtected(TestResult.java:124)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.framework.TestSuite.runTest(TestSuite.java:230)
   at junit.framework.TestSuite.run(TestSuite.java:225)
   at junit.textui.TestRunner.doRun(TestRunner.java:121)
   at junit.textui.TestRunner.start(TestRunner.java:185)
   at junit.textui.TestRunner.main(TestRunner.java:143)
 java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:197)
   at java.net.SocketInputStream.read(SocketInputStream.java:116)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown 
 Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
   at 
 org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown 
 Source)
   at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown 
 Source)
   at org.apache.derby.drda.NetworkServerControl.ping(Unknown

[jira] [Updated] (DERBY-5841) Code coverage of org.apache.derby.iapi.jdbc


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

Mike Matrigali updated DERBY-5841:
--

Component/s: Test

 Code coverage of org.apache.derby.iapi.jdbc
 ---

 Key: DERBY-5841
 URL: https://issues.apache.org/jira/browse/DERBY-5841
 Project: Derby
  Issue Type: Improvement
  Components: Test
Reporter: Siddharth Srivastava
Assignee: Siddharth Srivastava
Priority: Minor



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6045) in list multi-probe by primary key not chosen on tables with 256 rows


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

Mike Matrigali updated DERBY-6045:
--

Component/s: (was: Store)
 SQL

 in list multi-probe by primary key not chosen on tables with 256 rows
 --

 Key: DERBY-6045
 URL: https://issues.apache.org/jira/browse/DERBY-6045
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.9.1.0, 10.10.1.1
 Environment: Linux Debian 6.0.5
Reporter: Tony Brusseau
 Fix For: 10.11.0.0

 Attachments: DERBY6045_patch1_diff.txt, DERBY6045_patch2_diff.txt, 
 optimizerTraceOutputFor10_8.txt, optimizerTraceOutputForTrunk.txt, 
 optimizerTraceOutputWithUpdateStatsFor10_8.txt, 
 optimizerTraceOutputWithUpdateStatsForTrunk.txt


 I have a table with a long integer primary key field and 11 million rows. I 
 seem to be unable to load large chunks of rows via id in a reasonably 
 efficient manner.
   1. If I do individual lookups via the primary key, then a fast indexed 
 lookup occurs. However, if I do large numbers of such queries, then the time 
 is overwhelmed by round-trip overhead which makes everything incredibly slow.
   2. If I use a single query with a disjunction of the primary keys of 
 interest,  then a table scan is performed (even if the clause only contains 
 1-3 items), which walks over 11 million rows...incredibly inefficient.
   3. If I use an IN clause, then a table scan is performed (even if the 
 clause only contains 1-3 items), which walks over 11 million 
 rows...incredibly inefficient.
 I'm guessing that this might have something to do with the fact that I'm 
 using large integers and really big numbers that don't start anywhere at or 
 about 1 for my keys. Could this possibly be confusing the optimizer?
 Here are the unlimited query plans for the 3 cases that I enumerated:
 *
 [EL Fine]: 2013-01-17 
 11:09:53.384--ServerSession(582235416)--Connection(1430986883)--Thread(Thread[Initial
  Lisp Listener,5,SubL Thread Group])--SELECT TERM_ID, ARG0, ARG1, ARG2, 
 ARG3, FORMULA_HASH, FORMULA_LENGTH, FORMULA_TYPE, KB_STATUS FROM 
 KB.FORMULA_TERM WHERE (TERM_ID = ?)
   bind = [2251799814033500]
 Thu Jan 17 11:09:53 CST 2013 Thread[Initial Lisp Listener,5,SubL Thread 
 Group] (XID = 4711079), (SESSIONID = 3), SELECT TERM_ID, ARG0, ARG1, ARG2, 
 ARG3, FORMULA_HASH, FORMULA_LENGTH, FORMULA_TYPE, KB_STATUS FROM 
 KB.FORMULA_TERM WHERE (TERM_ID = ?) *** Project-Restrict ResultSet (3):
 Number of opens = 1
 Rows seen = 1
 Rows filtered = 0
 restriction = false
 projection = true
   constructor time (milliseconds) = 0
   open time (milliseconds) = 0
   next time (milliseconds) = 0
   close time (milliseconds) = 0
   restriction time (milliseconds) = 0
   projection time (milliseconds) = 0
   optimizer estimated row count: 1.00
   optimizer estimated cost: 6.59
 Source result set:
   Index Row to Base Row ResultSet for FORMULA_TERM:
   Number of opens = 1
   Rows seen = 1
   Columns accessed from heap = {1, 2, 3, 4, 5, 6, 7, 8}
   constructor time (milliseconds) = 0
   open time (milliseconds) = 0
   next time (milliseconds) = 0
   close time (milliseconds) = 0
   optimizer estimated row count: 1.00
   optimizer estimated cost: 6.59
   Index Scan ResultSet for FORMULA_TERM using constraint 
 KB_FORMULA_TERM_TERM_ID_PK at read committed isolation level using share row 
 locking chosen by the optimizer
   Number of opens = 1
   Rows seen = 1
   Rows filtered = 0
   Fetch Size = 1
   constructor time (milliseconds) = 0
   open time (milliseconds) = 0
   next time (milliseconds) = 0
   close time (milliseconds) = 0
   next time in milliseconds/row = 0
   scan information:
   Bit set of columns fetched=All
   Number of columns fetched=2
   Number of deleted rows visited=0
   Number of pages visited=3
   Number of rows qualified=1
   Number of rows visited=1
   Scan type=btree
   Tree height=-1
   start position:
   = on first 1 column(s).
   Ordered null semantics on the following 
 columns: 
   stop position:
on first 1 column(s).
   Ordered null semantics on the

[jira] [Commented] (DERBY-6135) Request data compression scheme (i.e., gzip of data pages)

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

Mike Matrigali commented on DERBY-6135:
---

In your example can you run compress database and get any/all space back? Just
trying to understand if in your case the compression would
be working around known issues with reclaiming space in the database. Also
good to know some more detail about your case, is the space
being used in seg0 or log?

Something that I think could be done pretty easily in Derby is to add
compression at the datatype level, rather than page level. Adding this for
blob, clob, and the character types would be interesting. Not sure what
syntax. Could do it at db level like encryption, or at column level with
new ddl.

There tends not to be standards in the ddl. Are there any db's that allow
compression indication at the colun level, and if so what syntax?

Request data compression scheme (i.e., gzip of data pages)
--

Key: DERBY-6135
URL: https://issues.apache.org/jira/browse/DERBY-6135
Project: Derby
Issue Type: Improvement
Components: Store
Reporter: Tony Brusseau

This is a request for a data compression scheme facility added to Derby
(something like gzip of data pages). MySQL and some other databases provide
such a feature, see:
http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-compression-internals.html
The desire for this is because my current database size is 27GB but gzipped,
it goes down to 7GB. I wish to scale my database dramatically, but the
current disk footprint would prevent me from being able to use Derby.

[jira] [Updated] (DERBY-4080) Deadlock between locks and latches in BTreeController.compareRowsForInsert()


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

Mike Matrigali updated DERBY-4080:
--

Affects Version/s: 10.11.0.0

ran script against trunk and it gets lock timeout at end.

 Deadlock between locks and latches in BTreeController.compareRowsForInsert()
 

 Key: DERBY-4080
 URL: https://issues.apache.org/jira/browse/DERBY-4080
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.4.2.0, 10.11.0.0
Reporter: Knut Anders Hatlen
  Labels: derby_triage10_5_2, derby_triage10_9
 Attachments: repro.sql


 It looks like BTreeController.compareRowsForInsert(), which is used to check 
 for duplicates in a unique nullable index, can run into a deadlock which 
 involves both locks and latches.
 Here's what I think can happen:
 comparePreviousRecord() (or compareNextRecord()) holds a latch on the index 
 page where a new row is about to be inserted, and needs to check if there's a 
 duplicate on one of the adjacent rows. Because the row is near a page 
 boundary, this check moves to another index page, while still holding the 
 latch on the original index page. Then compareRowsForInsert() is called, 
 which tries to get an update lock on the existing row. If it has to wait for 
 the update lock, the latch on the current page is released, but the latch on 
 the original index page is kept. This means that the transaction is holding a 
 latch while it is waiting for a lock, which means that it is blocking all 
 access to that page until it has been granted the lock. If some other 
 transaction that is holding a conflicting lock on the row later needs to 
 latch the index page, those two transactions run into a deadlock and the one 
 that's waiting for the lock will eventually time out (but it will not be 
 reported as a deadlock).
 If compareRowsForInsert() releases all latches when it needs to wait for a 
 lock, the deadlock is prevented, and both of the transactions may be able to 
 complete without timing out.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6135) Request data compression scheme (i.e., gzip of data pages)

2013-04-16 Thread Tony Brusseau (JIRA)

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

Tony Brusseau commented on DERBY-6135:
--

The size I gave was after running SYSCS_UTIL.SYSCS_COMPRESS_TABLE on all the
tables.

du -sh log
1.1Mlog

du -sh seg0
29G seg0

All the data is in seg0.

I don't think the datatype level would help since only a very tiny bit of the
data in my particular case is in strings, clobs and lobs.

I use long ids everywhere, I bet a bunch of the gzip compression is from
compression of replicated bytes in the ids.

Request data compression scheme (i.e., gzip of data pages)
--

Key: DERBY-6135
URL: https://issues.apache.org/jira/browse/DERBY-6135
Project: Derby
Issue Type: Improvement
Components: Store
Reporter: Tony Brusseau

problems deploying maven artifacts for 10.10.1.1


I hope that Kristian is still monitoring this mail group.

I am trying to deploy maven artifacts for 10.10.1.1 and am flummoxed 
about what to do next. I am following the instructions in maven2/README.txt.


I have successfully finished steps (a) through (d). That is, I have 
successfully completed the uploading of the signed artifacts. At least, 
I think I've done that step successfully. I saw no error messages and I 
received informational diagnostics like the following:


Uploaded: 
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/derby/derby/10.10.1.1/derby-10.10.1.1.jar 
(2765 KB at 271.2 KB/sec)


However, I am unable to locate the uploaded artifacts. If I paste the 
above url into my browser and then give my Apache LDAP credentials, I 
get the following error message:


Staging of Repository within profile ID='288be52400f0b' is not yet 
started!


...and if I log onto Nexus at https://repository.apache.org/, I can't 
locate a staging repository for the 10.10.1.1 artifacts as expected by 
step (e) in README.txt.


Anyone know what I did wrong? Did I fail to RTFM? Is there a missing 
step which isn't documented in README.txt and 
http://wiki.apache.org/db-derby/ReleasePublication? Has the process 
changed since those two guides were written?


Thanks,
-Rick

[jira] [Updated] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas updated DERBY-6104:
-

Attachment: derby-6104-12-aa-doap.diff

Attaching derby-6104-12-aa-doap.diff. This patch adds 10.10.1.1 to the list of 
versions on Derby's rdf descriptor. Committed at subversion revision 1468540.


 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
  Components: Build tools
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff, derby-6104-12-aa-doap.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6157) text for message XSLA4 might encouraging people to delete part of the transaction log

2013-04-16 Thread Myrna van Lunteren (JIRA)

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

Myrna van Lunteren updated DERBY-6157:
--

Assignee: Myrna van Lunteren

text for message XSLA4 might encouraging people to delete part of the
transaction log
-

[jira] [Commented] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas commented on DERBY-6104:
--

Created 10.10.1.1 code tag at subversion revision 1468541: 
https://svn.apache.org/repos/asf/db/derby/code/tags/10.10.1.1/

Created 10.10.1.1 doc tag at subversion revision 1468542: 
https://svn.apache.org/repos/asf/db/derby/docs/tags/10.10.1.1/

 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
  Components: Build tools
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff, derby-6104-12-aa-doap.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6135) Request data compression scheme (i.e., gzip of data pages)


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

Mike Matrigali commented on DERBY-6135:
---

good feedback, I had always assumed apps looking for compression would be 
string/blob centric.  

For your app do your long id's tend to start at 0 and grow?  Derby internally 
implements a compression technique for number data
that is highly optimized for numbers that are small but types that support much 
bigger.  We only use this for metadata right now.


 Request data compression scheme (i.e., gzip of data pages)
 --

 Key: DERBY-6135
 URL: https://issues.apache.org/jira/browse/DERBY-6135
 Project: Derby
  Issue Type: Improvement
  Components: Store
Reporter: Tony Brusseau

 This is a request for a data compression scheme facility added to Derby 
 (something like gzip of data pages). MySQL and some other databases provide 
 such a feature, see:
 http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-compression-internals.html
 The desire for this is because my current database size is 27GB but gzipped, 
 it goes down to 7GB. I wish to scale my database dramatically, but the 
 current disk footprint would prevent me from being able to use Derby.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas commented on DERBY-6104:
--

Checked 10.10.1.1 jars into a 10.10.1.1 subdirectory of the jars directory used 
by the upgrade tests. Committed at subversion revision 1468547.


 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
  Components: Build tools
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff, derby-6104-12-aa-doap.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6135) Request data compression scheme (i.e., gzip of data pages)

2013-04-16 Thread Tony Brusseau (JIRA)


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

Tony Brusseau commented on DERBY-6135:
--

No, the id's never start anywhere near 0. The upper 8 bits of the long is used 
to represent type info, and the numbers grow normally from there. So the upper 
byte and lower 3-4 bytes always have relevant data bits set.

 Request data compression scheme (i.e., gzip of data pages)
 --

 Key: DERBY-6135
 URL: https://issues.apache.org/jira/browse/DERBY-6135
 Project: Derby
  Issue Type: Improvement
  Components: Store
Reporter: Tony Brusseau

 This is a request for a data compression scheme facility added to Derby 
 (something like gzip of data pages). MySQL and some other databases provide 
 such a feature, see:
 http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-compression-internals.html
 The desire for this is because my current database size is 27GB but gzipped, 
 it goes down to 7GB. I wish to scale my database dramatically, but the 
 current disk footprint would prevent me from being able to use Derby.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mike Matrigali commented on DERBY-6185:
---

does derby support like operation on clob's?

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (DERBY-6135) Request data compression scheme (i.e., gzip of data pages)

2013-04-16 Thread Tony Brusseau (JIRA)

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

Tony Brusseau edited comment on DERBY-6135 at 4/16/13 6:47 PM:
---

No, the id's never start anywhere near 0. The upper 8 bits of the long is used
to represent type info (this allows me to have unique ids across multiple
tables while still using sequences for id generation), and the numbers grow
normally from there. So the upper byte and lower 3-4 bytes always have relevant
data bits set.

was (Author: apb):
No, the id's never start anywhere near 0. The upper 8 bits of the long is
used to represent type info, and the numbers grow normally from there. So the
upper byte and lower 3-4 bytes always have relevant data bits set.

Request data compression scheme (i.e., gzip of data pages)
--

Key: DERBY-6135
URL: https://issues.apache.org/jira/browse/DERBY-6135
Project: Derby
Issue Type: Improvement
Components: Store
Reporter: Tony Brusseau

[jira] [Updated] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas updated DERBY-6104:
-

Attachment: derby-6104-13-aa-upgradeStartingPoints.diff

Attaching derby-6104-13-aa-upgradeStartingPoints.diff. This patch adds 
10.10.1.1 to the table of starting points for the upgrade tests. Committed at 
subversion revision 1468554.

Touches the following file:

M   
java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/OldVersions.java


 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
  Components: Build tools
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff, 
 derby-6104-12-aa-doap.diff, derby-6104-13-aa-upgradeStartingPoints.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6067) JaCoCo fails with missing permissions when writing results


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

Rick Hillegas updated DERBY-6067:
-

Fix Version/s: (was: 10.10.1.1)
   10.10.1.2

 JaCoCo fails with missing permissions when writing results
 --

 Key: DERBY-6067
 URL: https://issues.apache.org/jira/browse/DERBY-6067
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.1
 Environment: most platforms (hopefully more details later)
Reporter: Kristian Waagan
Assignee: Kristian Waagan
 Fix For: 10.10.1.2

 Attachments: derby-6067-1a-fix_privileges.diff, 
 derby-6067-1b-fix_privileges.diff


 The JaCoCo targets fail on most platforms due to missing permissions, i.e. 
 ant jacoco-junit:
 junit-pptesting:
 [junit] Running org.apache.derby.PackagePrivateTestSuite
 [junit] Tests run: 67, Failures: 0, Errors: 0, Time elapsed: 22,858 sec
 [junit] java.security.AccessControlException: access denied 
 (java.io.FilePermission trunk\junit_20130211_1216\jacoco.exec write)
 [junit] at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
 [junit] at 
 java.security.AccessController.checkPermission(AccessController.java:555)
 [junit] at 
 java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 [junit] at 
 java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
 [junit] at java.io.FileOutputStream.init(FileOutputStream.java:203)
 [junit] at 
 org.jacoco.agent.rt.internal_5d10cad.output.FileOutput.openFile(FileOutput.java:67)
 [junit] at 
 org.jacoco.agent.rt.internal_5d10cad.output.FileOutput.writeExecutionData(FileOutput.java:53)
 [junit] at 
 org.jacoco.agent.rt.internal_5d10cad.Agent.shutdown(Agent.java:143)
 [junit] at 
 org.jacoco.agent.rt.internal_5d10cad.Agent$1.run(Agent.java:60)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6012) Print thread dump and dump javacore if NetworkServerTestSetup has to kill off the Network Server start up process due to timeout


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

Rick Hillegas updated DERBY-6012:
-

Fix Version/s: (was: 10.10.1.1)
   10.10.1.2

 Print thread dump and dump javacore if NetworkServerTestSetup has to kill off 
 the Network Server start up  process due to timeout
 -

 Key: DERBY-6012
 URL: https://issues.apache.org/jira/browse/DERBY-6012
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.8.3.0
 Environment: 
Reporter: Kathey Marsden
Assignee: Mamta A. Satoor
 Fix For: 10.10.1.2

 Attachments: derby-6012-1a-error_reporting.diff, 
 DERBY6012_patch1_diff.txt, DERBY6012_patch2_diff.txt


 If Network Server startup hangs or times out as in DERBY-5991, we should 
 generate a javacore or a thread dump so the cause of the problem can be more 
 easily diagnosed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-5781) Investigate lifting the limit on the number of columns in a Derby table


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

Rick Hillegas updated DERBY-5781:
-

Fix Version/s: (was: 10.10.1.1)
   10.10.1.2

 Investigate lifting the limit on the number of columns in a Derby table
 ---

 Key: DERBY-5781
 URL: https://issues.apache.org/jira/browse/DERBY-5781
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Fix For: 10.10.1.2


 Derby tables are limited to 1012 columns. This arbitrary limit is not found 
 in the SQL Standard and is the value of 
 Limits.DB2_MAX_ELEMENTS_IN_SELECT_LIST. We should investigate lifting this 
 limit based on user demand: 
 http://old.nabble.com/limit-on-the-number-of-columns-to33901308.html#a33901308

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mike Matrigali commented on DERBY-6185:
---

Here is doc reference that notes no comparison's are supported in clobs in 10.8.
http://db.apache.org/derby/docs/10.8/ref/rrefsqlj58560.html

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6104) Tasks for producing a 10.10.1 feature release.


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

Rick Hillegas updated DERBY-6104:
-

Attachment: derby-6104-14-aa-status.diff

Attaching derby-6104-14-aa-status.diff. This patch updates the STATUS file to 
reflect the release of 10.10.1.1. Committed at subversion revision 1468560.

Touches the following file:

M   STATUS


 Tasks for producing a 10.10.1 feature release.
 --

 Key: DERBY-6104
 URL: https://issues.apache.org/jira/browse/DERBY-6104
 Project: Derby
  Issue Type: Task
  Components: Build tools
Reporter: Rick Hillegas
 Attachments: derby-6104-01-aa-errorCodeTables.diff, 
 derby-6104-02-aa-releaseNotesFirstRev.diff, 
 derby-6104-03-aa-releaseNotesTypos.diff, 
 derby-6104-04-aa-releaseNotesThirdRev.diff, 
 derby-6104-05-aa-createBranchWithChangeNumber.diff, 
 derby-6104-07-aa-add10.10toWebsite.diff, 
 derby-6104-08-aa-releaseNotesFirstCandidate.diff, 
 derby-6104-09-aa-cleanupAfterJiraSoap.diff, 
 derby-6104-10-aa-scrubMore142References.diff, 
 derby-6104-11-aa-releaseNotesSecondCandidate.diff, 
 derby-6104-12-aa-doap.diff, derby-6104-13-aa-upgradeStartingPoints.diff, 
 derby-6104-14-aa-status.diff




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (DERBY-6070) Document Derby's JDBC 4.2 implementation

2013-04-16 Thread Kim Haase (JIRA)

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

Kim Haase closed DERBY-6070.

Docs are in the 10.10.1 release.

Document Derby's JDBC 4.2 implementation

Key: DERBY-6070
URL: https://issues.apache.org/jira/browse/DERBY-6070
Project: Derby
Issue Type: Improvement
Components: Documentation
Affects Versions: 10.10.1.1
Reporter: Rick Hillegas
Assignee: Kim Haase
Fix For: 10.10.1.1

Attachments: DERBY-6070.diff, DERBY-6070.stat, DERBY-6070.zip

We may want to document the following specifics of Derby's JDBC 4.2
implementation:
--- DatabaseMetaData.getMaxLogicalLobSize() ---
This is a new method added by JDBC 4.2. The javadoc for this method is terse:
long getMaxLogicalLOBSize()
throws SQLException
Retrieves the maximum number of bytes this database allows for the logical
size for a LOB.
Returns:
the maximum number of bytes allowed; a result of zero means that there is
no limit or the limit is not known
Throws:
SQLException - if a database access error occurs
Derby returns 0. The meaningful limits on Derby's BLOB and CLOB datatypes are
documented in the datatype section of the Reference Manual.
--- SQLType ---
JDBC 4.2 introduces a new datatype identifier (java.sql.SQLType) to help
databases describe datatypes which don't appear in the ANSI/ISO SQL Standard.
The idea is that databases with non-standard types can provide their own
implementations of SQLType. JDBC 4.2 also supplies its own implementation
(java.sql.JDBCType) which provides an enum for each of the type ids in
java.sql.Types.
Derby doesn't expose any datatypes which aren't represented by JDBCType enums
and so Derby doesn't need to provide its own implementation of SQLType.
Overloads with SQLType arguments have been added to various interfaces,
alongside the existing methods which take int type ids from java.sql.Types.
The affected interfaces are: CallableStatement, PreparedStatement, and
ResultSet. On Derby, these methods raise an unsupported datatype exception
(SQLState 0A000) if the caller passes in a bad SQLType, namely:
1) A SQLType from a foreign database. That is a SQLType which isn't one of
the JDBCType enums.
2) A JDBCType enum whose corresponding int type id (from java.sql.Types)
isn't supported by Derby. The supported int type ids are documented in the
datatype section of the Reference Manual. The JDBCType enums have the same
names as their corresponding int ids in java.sql.Types.

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed

2013-04-16 Thread Rong Qu (JIRA)


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

Rong Qu commented on DERBY-6185:


Forgot to mention that the same query worked fine if the query is against 
table, not view.

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (DERBY-5886) FILE_CANNOT_REMOVE_FILE exception prints garbage.


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

Mike Matrigali reassigned DERBY-5886:
-

Assignee: Mike Matrigali

 FILE_CANNOT_REMOVE_FILE exception prints garbage.
 -

 Key: DERBY-5886
 URL: https://issues.apache.org/jira/browse/DERBY-5886
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.10.1.1
Reporter: Rick Hillegas
Assignee: Mike Matrigali
  Labels: derby_triage10_10

 SQLState.FILE_CANNOT_REMOVE_FILE maps to a message which has 2 arguments. 
 This SQLState is used many times. It is variously given 1, 2, or 3 arguments. 
 It's unclear whether we need multiple messages here or whether a single 
 message could be pressed into service for all cases. As it is, some of these 
 invocations are going to generate confusing garbage for the user. This 
 SQLState is used in the following classes:
 java/engine/org/apache/derby/impl/store/raw/data/EncryptData.java
 java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java
 java/engine/org/apache/derby/impl/store/raw/data/RFResource.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6183) rlliso2multi and rlliso3multi failing with [WARNING 01004: Data truncation]


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

Mike Matrigali updated DERBY-6183:
--

Attachment: DERBY-6183_patch.txt

proposed patch for this issue.  removes casts from lock table view and updates 
all the master based canon's that are affected.

 rlliso2multi and rlliso3multi failing with [WARNING 01004: Data truncation]
 ---

 Key: DERBY-6183
 URL: https://issues.apache.org/jira/browse/DERBY-6183
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.2
 Environment: Windows XP with IBM jdk 1.7
Reporter: Mamta A. Satoor
Assignee: Mike Matrigali
 Attachments: DERBY-6183_patch.txt, derbyFor_rlliso2multi.log, 
 derbyFor_rlliso3multi.log, error-stacktraceFor_rlliso2multi.out, 
 error-stacktraceFor_rlliso3multi.out


 1) 
 rlliso2multi(org.apache.derbyTesting.functionTests.tests.store.StoreScriptsTest)junit.framework.ComparisonFailure:
  Output at line 1188 expected:[TABLE   |1  |IX  |TEST_11 |Tablelock 
 |GRANT] but was:[WARNING 01004: Data truncation]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:109)
   at 
 org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:204)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:442)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:459)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 2) 
 rlliso3multi(org.apache.derbyTesting.functionTests.tests.store.StoreScriptsTest)junit.framework.ComparisonFailure:
  Output at line 602 expected:[TABLE   |1  |IX  |TEST_6  |Tablelock 
 |GRANT] but was:[WARNING 01004: Data truncation]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:109)
   at 
 org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:204)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:442)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:459)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6183) rlliso2multi and rlliso3multi failing with [WARNING 01004: Data truncation]


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

Mike Matrigali updated DERBY-6183:
--

Issue  fix info: Patch Available

 rlliso2multi and rlliso3multi failing with [WARNING 01004: Data truncation]
 ---

 Key: DERBY-6183
 URL: https://issues.apache.org/jira/browse/DERBY-6183
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.2
 Environment: Windows XP with IBM jdk 1.7
Reporter: Mamta A. Satoor
Assignee: Mike Matrigali
 Attachments: DERBY-6183_patch.txt, derbyFor_rlliso2multi.log, 
 derbyFor_rlliso3multi.log, error-stacktraceFor_rlliso2multi.out, 
 error-stacktraceFor_rlliso3multi.out


 1) 
 rlliso2multi(org.apache.derbyTesting.functionTests.tests.store.StoreScriptsTest)junit.framework.ComparisonFailure:
  Output at line 1188 expected:[TABLE   |1  |IX  |TEST_11 |Tablelock 
 |GRANT] but was:[WARNING 01004: Data truncation]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:109)
   at 
 org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:204)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:442)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:459)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
 2) 
 rlliso3multi(org.apache.derbyTesting.functionTests.tests.store.StoreScriptsTest)junit.framework.ComparisonFailure:
  Output at line 602 expected:[TABLE   |1  |IX  |TEST_6  |Tablelock 
 |GRANT] but was:[WARNING 01004: Data truncation]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:109)
   at 
 org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:204)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:442)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:459)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (DERBY-6154) add non-order by cases to the BlobClob4BlobTest


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

Mike Matrigali reopened DERBY-6154:
---


previous patch did not work when run in nightly's.  backed out, need new fix.

 add non-order by cases to the BlobClob4BlobTest
 ---

 Key: DERBY-6154
 URL: https://issues.apache.org/jira/browse/DERBY-6154
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.11.0.0
Reporter: Mike Matrigali
Assignee: Mike Matrigali
 Fix For: 10.11.0.0


 From a discussion in DERBY-6092, more code paths could be exercised by adding 
 non order by
 query tests in addition to the order by query tests that exist.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Java DB - testing] Success continuous 10.9 (rev 1468479)

Java DB testing and reporting infrastructure.

Success continuous 10.9 (rev 1468479)

No errors or failures.

Test report:  http://download.java.net/javadesktop/derby/javadb-5575205-report/

Re: problems deploying maven artifacts for 10.10.1.1

2013-04-16 Thread Myrna van Lunteren

If you got those positive messages, you're likely further than what I
managed to do for 10.8.3...

For 10.8.3, I did not change server.xml appropriately, I am assuming you
managed to do all that...
Perhaps you can just do the madman's approach and try the same thing again
and hope for a different result?

Not very helpful message, sorry.

Myrna

On Tue, Apr 16, 2013 at 11:01 AM, Rick Hillegas rick.hille...@oracle.comwrote:

I hope that Kristian is still monitoring this mail group.

I am trying to deploy maven artifacts for 10.10.1.1 and am flummoxed about
what to do next. I am following the instructions in maven2/README.txt.

I have successfully finished steps (a) through (d). That is, I have
successfully completed the uploading of the signed artifacts. At least, I
think I've done that step successfully. I saw no error messages and I
received informational diagnostics like the following:

Uploaded: https://repository.apache.org/**service/local/staging/deploy/**
maven2/org/apache/derby/derby/**10.10.1.1/derby-10.10.1.1.jarhttps://repository.apache.org/service/local/staging/deploy/maven2/org/apache/derby/derby/10.10.1.1/derby-10.10.1.1.jar(2765
KB at 271.2 KB/sec)

However, I am unable to locate the uploaded artifacts. If I paste the
above url into my browser and then give my Apache LDAP credentials, I get
the following error message:

Staging of Repository within profile ID='288be52400f0b' is not yet
started!

...and if I log onto Nexus at https://repository.apache.org/**, I can't
locate a staging repository for the 10.10.1.1 artifacts as expected by step
(e) in README.txt.

Anyone know what I did wrong? Did I fail to RTFM? Is there a missing step
which isn't documented in README.txt and http://wiki.apache.org/db-**
derby/ReleasePublicationhttp://wiki.apache.org/db-derby/ReleasePublication?
Has the process changed since those two guides were written?

Thanks,
-Rick

[jira] [Commented] (DERBY-6154) add non-order by cases to the BlobClob4BlobTest


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

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

I noticed that the committed patch removed ORDER BY clauses for 
testTriggersWithClobColumn(), whereas the test case investigated in DERBY-6092 
was actually testPositionAgressive().

(I haven't verified that testPositionAgressive() is valid without the ORDER BY 
or if it just happened to work with the ordering that came out of the query in 
my environment, though.)

 add non-order by cases to the BlobClob4BlobTest
 ---

 Key: DERBY-6154
 URL: https://issues.apache.org/jira/browse/DERBY-6154
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.11.0.0
Reporter: Mike Matrigali
Assignee: Mike Matrigali
 Fix For: 10.11.0.0


 From a discussion in DERBY-6092, more code paths could be exercised by adding 
 non order by
 query tests in addition to the order by query tests that exist.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: problems deploying maven artifacts for 10.10.1.1

2013-04-16 Thread kristwaa

Rick Hillegas wrote
 -- snip --
 
 ...and if I log onto Nexus at https://repository.apache.org/, I can't 
 locate a staging repository for the 10.10.1.1 artifacts as expected by 
 step (e) in README.txt.

Hi Rick,

I can see the repository in Nexus, but it's still in the open state.
Have you tried to close it?


Regards,
-- 
Kristian



--
View this message in context: 
http://apache-database.10148.n7.nabble.com/problems-deploying-maven-artifacts-for-10-10-1-1-tp129305p129328.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mamta A. Satoor commented on DERBY-6185:


If I recall it right, = and  are not supported on CLOB/BLOB but LIKE is 
allowed. For simplicity purposes, I removed the ESCAPE clause from the query 
and the behavior is the same as seen by Rong.
-- does not work
select name from myview where name like 'Col1';
-- works
select name from mytbl1 where name like 'Col1';

Debugging the code a little bit, I found that we do the check for comparibility 
in BinaryComparisonOperatorNode.bindComparisonOperator() and part of the code 
is as follows
  if (!cmp  !forQueryRewrite) {
throw 
StandardException.newException(SQLState.LANG_NOT_COMPARABLE, 

leftOperand.getTypeServices().getSQLTypeNameWithCollation() ,

rightOperand.getTypeServices().getSQLTypeNameWithCollation());

For the case with table, we come to this code in the bind phase and 
forQueryRewrite has been set to true in LikeEscapeOperatorNode.bindExpression
// Set forQueryRewrite to bypass comparability checks
equals.setForQueryRewrite(true);

For the case with view, we come to the same code as above during the bind phase 
and forQueryRewrite has been set to true and hence bind goes through fine. But 
we come back to BinaryComparisonOperatorNode.bindComparisonOperator check in 
the optimizer's pre-processing phase and at that time, forQueryRewrite is false 
and that is why we throw the exception. May be we have a bug here. I want to 
look at the code little more to see if I can see what the issue might be. But I 
will appreciate any feedback from the list to see if I am on the right track. 
Thanks

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mamta A. Satoor commented on DERBY-6185:


Here is what I tried in ij
java -Dderby.language.logQueryPlan=true -Dij.exceptionTrace=true 
org.apache.derby.tools.ij
connect 'jdbc:derby:db1;create=true';
create table mytbl1 (name clob(10K));
create table mytbl2 (name clob(10K));
create view myview (name) as select t1.name from mytbl1 t1 union all select 
t2.name from mytbl2 t2;
--fails
select name from myview where name like 'Col1';
-- passes
select name from mytbl1 where name like  'Col1';
-- fails because = not supported on CLOB
select name from mytbl1 where name = 'Col1';
-- fails because  not supported on CLOB
select name from mytbl1 where name  'Col1';

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mike Matrigali updated DERBY-6185:
--

Affects Version/s: 10.5.3.2

tried against top of 10.5 branch and did not work there also.

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.5.3.2, 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mike Matrigali updated DERBY-6185:
--

Affects Version/s: 10.1.3.3

tried against top of 10.1 branch, failed with different error message, and 
worked directly against table:
select name from myview where name like 'Col1';
ERROR 42818: Comparisons between 'CLOB' and 'CHAR' are not supported.
ij -- passes
select name from mytbl1 where name like  'Col1';
NAME


0 rows selected


 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.3, 10.5.3.2, 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed


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

Mike Matrigali commented on DERBY-6185:
---

fails all the way back to 10.1 so does not look like a regression.

 Query against view  with where name LIKE 'Col1' ESCAPE '\'  failed
 

 Key: DERBY-6185
 URL: https://issues.apache.org/jira/browse/DERBY-6185
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.3, 10.5.3.2, 10.8.2.2, 10.8.3.0
 Environment: windows 7
Reporter: Rong Qu

 The error can be reproduced,
 1) create table mytbl1 (name clob(10K));
 2) create table mytbl2 (name clob(10K));
 3) create view myview (name) as select t1.name from mytbl1 t1 union all 
 select t2.name from mytbl2 t2;
 4) select name from myview where name LIKE 'Col1' ESCAPE '\';
 4) failed with error message 
 ERROR 42818: Comparisons between 'CLOB (UCS_BASIC)' and 'CHAR (UCS_BASIC)' 
 are not supported. Types must be comparable. String types must also have 
 matching collation. If collation does not match, a possible solution is to 
 cast operands to force them to the default collation (e.g. SELECT tablename 
 FROM sys.systables WHERE CAST(tablename AS VARCHAR(128)) = 'T1')
   at org.apache.derby.iapi.error.StandardException.newException(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.BinaryComparisonOperatorNode.bindComparisonOperator(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.compile.PredicateList.pushExpressionsIntoSelect(Unknown
  Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.UnionNode.pushExpressions(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.pushExpressions(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.FromList.pushPredicates(Unknown 
 Source)
   at org.apache.derby.impl.sql.compile.SelectNode.preprocess(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
   at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
   ... 19 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (DERBY-6157) text for message XSLA4 might encouraging people to delete part of the transaction log

2013-04-16 Thread Myrna van Lunteren (JIRA)

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

Myrna van Lunteren updated DERBY-6157:
--

Attachment: DERBY-6157.diff
DERBY-6157.stat

Attaching a patch which replaces the message.
The full text was only reflected in lang/ErrorCodeTest.java, so I only ran that
test.

I removed the message from most languages.properties files, so that the English
will show up instead of the unhelpful translated one.

Except I amused myself with devising a translation for German, French, Spanish
and Italian.
I don't have the skill of a licensed translator, but with some limited
knowledge, help from various free translators, some dictionaries, and the text
of other translated messages, I think this is pretty close, better than what it
was, and presumably if we get another all-out translation contribution these
will get overwritten anyway.

text for message XSLA4 might encouraging people to delete part of the
transaction log
-

Key: DERBY-6157
URL: https://issues.apache.org/jira/browse/DERBY-6157
Project: Derby
Issue Type: Bug
Components: Store
Affects Versions: 10.9.2.2, 10.10.1.1, 10.10.1.2, 10.11.0.0
Reporter: Myrna van Lunteren
Assignee: Myrna van Lunteren
Attachments: DERBY-6157.diff, DERBY-6157.stat

[jira] [Commented] (DERBY-6157) text for message XSLA4 might encouraging people to delete part of the transaction log

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

Mike Matrigali commented on DERBY-6157:
---

diff looks fine to me, i just checked the english stuff. +1

text for message XSLA4 might encouraging people to delete part of the
transaction log
-

[jira] [Commented] (DERBY-6157) text for message XSLA4 might encouraging people to delete part of the transaction log

2013-04-16 Thread Myrna van Lunteren (JIRA)

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

Myrna van Lunteren commented on DERBY-6157:
---

Thanks for the review Mike. Committed to trunk with revision 1468647
(http://svn.apache.org/viewvc?view=revisionrevision=1468647).

text for message XSLA4 might encouraging people to delete part of the
transaction log
-

[Java DB - testing] Success continuous trunk (rev 1468560)

Java DB testing and reporting infrastructure.

Success continuous trunk (rev 1468560)

No errors or failures.

Test report:  http://download.java.net/javadesktop/derby/javadb-5575207-report/

[jira] [Commented] (DERBY-6185) Query against view with where name LIKE 'Col1' ESCAPE '\' failed