Re: [VOTE] Myrna Van Lunteren as a committer
+1 Fernanda Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby.
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: Please vote +1 if you approve of Myrna as a committer. I will close the voting at 10am PST on Tuesday, November 7th. +1 Olav
Re: [VOTE] Myrna Van Lunteren as a committer
Please vote +1 if you approve of Myrna as a committer. +1 -- Kristian
[jira] Updated: (DERBY-801) Allow parallel access to data files.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Knut Anders Hatlen updated DERBY-801:
-
Derby Info: (was: [Patch Available])
> Allow parallel access to data files.
>
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
>Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-v2.patch,
> DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch,
> NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - tinderbox_trunk15 470647 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk15* 470647/2006-11-03 05:03:04 CET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1519518 2 122.23% SunOS-5.10_i86pc-i386 Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/Limited/testSummary-470647.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/FailReports/470647.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/UpdateInfo/470647.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Regression Test Report - tinderbox_trunk15 470622 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk15* 470622/2006-11-03 02:13:24 CET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1519518 2 123.15% SunOS-5.10_i86pc-i386 Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/Limited/testSummary-470622.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/FailReports/470622.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/UpdateInfo/470622.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Running tests both with and without sqlAuthorization=true
During the review for DERBY-1490, several reviewers noted that it would be useful to be able to run various tests in two configurations: - with sqlAuthorization=true - with sqlAuthorization=false A good example of this is the test suite lang/altertable.sql, which currently runs with sqlAuthorization=true, but since there are a variety of different code paths for both sqlAuthorization configurations, it would be nice if this test suite also ran with sqlAuthorization=false. How does the new JUnit framework handle this situation? Will this problem "go away" when all the lang/*.sql tests have been converted to JUnit? thanks, bryan
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446795 ] Andrew McIntyre commented on DERBY-2006: Checked in revision 470636 which refactors junit-oneclass to always set the jvm for a junit run from a property and default the property to 'java'. So, if the jvm has a different executable name than 'java,' you can now override that by passing in derby.junit.jvm on the command-line. e.g.: ant -Dderby.junit.jvm=j9 junitreport Also, the junit-jdbc4 target is now more like the junit-all target. Additional jdbc4 tests can now be added to the junit-jdbc4 target simply by adding another . For example, to add jdbc4/AutoloadTest, add: Index: build.xml === --- build.xml (revision 470636) +++ build.xml (working copy) @@ -1635,6 +1635,12 @@ + + + + > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Docs: Explain the types of DITA topics used in Derby documentation
On 11/1/06, Laura Stewart <[EMAIL PROTECTED]> wrote: On 11/1/06, Kim Haase <[EMAIL PROTECTED]> wrote: > I've been thinking it may be useful to divide the recommended tags into > two categories -- structural tags and body tags might be appropriate > terms. There are structural elements like lists, paragraphs, tables, and > the like; and there are tags that you use in text within these > structural elements, like codeph, term, varname, filepath, and so on. > Does that seem helpful? > > Kim > > This is a great idea! I'll implement that on the Web page. -- Laura Stewart Kim - I added some content to the Derby Documentation site. When you get a chance, please look over the content on these pages. I tried to capture what we have discussed in this thread, and want to have another pair of eyes look over the content for completeness. -- Laura Stewart
Re: New way of adding internationalized messages. This affects the Derby Reference Guide.
On 11/1/06, Rick Hillegas <[EMAIL PROTECTED]> wrote: Hi Laura, If I understand you correctly, it sounds like you would like to create a website page which gives people stylistic advice on how to write clear, meaningful messages and how to name the arguments plugged into those messages. Then messages.xml could have a prominent header comment directing message writers to the website for style tips. I think that's a great idea. Right now, messages.xml does not have such a header comment. Unfortunately, messages.xml lives in the code repository while the documentation lives in the doc repository. It sound like you have only checked out the doc repository--that would be why you can't find messages.xml. Regards, -Rick Hi Rick - I created this page on the Derby Documentation site http://db.apache.org/derby/manuals/messages.html please let me know if the content is acceptable and if there is anything else that you think needs to be added. -- Laura Stewart
Re: [jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
On 11/2/06, Daniel John Debrunner (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446788 ] Daniel John Debrunner commented on DERBY-2006: -- Thanks Andrew for setting this up, just ran my first report and it looks good! I can see how to add other test cases in general but it's not obvious to me how it would be done for JDK 1.6 tests. Is it possible to add jdbc4/AutoloadTest as an example? > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests and produces JUnit report respectively. It will be nice to have these mechanism incorporated into the Ant script so one can easily kick off a JUnit test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira I found another irritating problem - this task apparently assumes your executable is java.exe. At least, I tried to run it with just j9 and it comes back with: java: eval: ant 302: not found Any suggestions? Myrna
[jira] Commented: (DERBY-2037) provide checking tool to flag possible errors in message translations
[ http://issues.apache.org/jira/browse/DERBY-2037?page=comments#action_12446789 ] Myrna van Lunteren commented on DERBY-2037: --- There were the following additional comments on the first cut of the tool: - the tool needs explanation of what it does and when it is to be used (readme, javadoc, add to relevant wiki pages) > provide checking tool to flag possible errors in message translations > - > > Key: DERBY-2037 > URL: http://issues.apache.org/jira/browse/DERBY-2037 > Project: Derby > Issue Type: Test > Components: Localization >Affects Versions: 10.3.0.0 >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Attachments: LocCompare.java > > > It would be useful to have a tool available that flags possible translation > file issues, such as: > - missing translations for (new) English messages > - mismatched parameters between English and non-English messages > - translation of keywords > - quoting problems (i.e. use of double quotes when single quotes should be > used, use of single quotes when double quotes should be used. This is based > on what's described in the MessageFormat api doc) > - mismatched characters such as < (when meaning smaller than), > (when > meaning larger than), % etc. > - identification of invalid characters, specifically characters in the range > of 0x00-0x1f (which are ASCII) and 0x7f-0xff > Note that such a tool cannot be definite (except about the missing messages) > because the English messages are not following very strict formatting, and > because what's acceptable syntax/grammar in one language may not work in > another. > A discussion about a first cut at such a tool can be found at: > http://comments.gmane.org/gmane.comp.apache.db.derby.devel/32187 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446788 ] Daniel John Debrunner commented on DERBY-2006: -- Thanks Andrew for setting this up, just ran my first report and it looks good! I can see how to add other test cases in general but it's not obvious to me how it would be done for JDK 1.6 tests. Is it possible to add jdbc4/AutoloadTest as an example? > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2037) provide checking tool to flag possible errors in message translations
[ http://issues.apache.org/jira/browse/DERBY-2037?page=all ] Myrna van Lunteren updated DERBY-2037: -- Attachment: LocCompare.java Attaching the source file LocCompare.java I will think about where this should go a bit more, then make a proper patch. This current file differs from the one suggested in the thread to the list (in the description) in the following: - by default, it assumes the locale files to be compared are in the same location as the english ones. One can still specify a temporary location. I thought this maybe might be useful after all. - it continues on to a next message if the original message string is not found. This does not yet implement the following: - print comparison strings by default to allow easy diffs (comment by Rajesh). The program has code that prints out the Strings compared when the program is run with -Dtvtdebug=true. But I've found there's too much information in that case, the output becomes quickly unreadable. I'll play with it a bit more, see if I find a place to print this where it looks ok (to me). - check on non-valid characters (comment Andrew). > provide checking tool to flag possible errors in message translations > - > > Key: DERBY-2037 > URL: http://issues.apache.org/jira/browse/DERBY-2037 > Project: Derby > Issue Type: Test > Components: Localization >Affects Versions: 10.3.0.0 >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Attachments: LocCompare.java > > > It would be useful to have a tool available that flags possible translation > file issues, such as: > - missing translations for (new) English messages > - mismatched parameters between English and non-English messages > - translation of keywords > - quoting problems (i.e. use of double quotes when single quotes should be > used, use of single quotes when double quotes should be used. This is based > on what's described in the MessageFormat api doc) > - mismatched characters such as < (when meaning smaller than), > (when > meaning larger than), % etc. > - identification of invalid characters, specifically characters in the range > of 0x00-0x1f (which are ASCII) and 0x7f-0xff > Note that such a tool cannot be definite (except about the missing messages) > because the English messages are not following very strict formatting, and > because what's acceptable syntax/grammar in one language may not work in > another. > A discussion about a first cut at such a tool can be found at: > http://comments.gmane.org/gmane.comp.apache.db.derby.devel/32187 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446783 ] Andrew McIntyre commented on DERBY-2006: Correct, junitreport is the top-level target. About having to put junit.jar into the classpath, that's a general Ant problem, covered in this FAQ: http://ant.apache.org/faq.html#delegating-classloader-1.6 Apparently this problem has been fixed in Ant 1.7 (due out any day now) such that tasks honor their nested classpath. > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2014) NullPointerException with NULLIF in GROUP BY clause
[ http://issues.apache.org/jira/browse/DERBY-2014?page=all ] Yip Ng updated DERBY-2014: -- Derby Info: [Patch Available] > NullPointerException with NULLIF in GROUP BY clause > --- > > Key: DERBY-2014 > URL: http://issues.apache.org/jira/browse/DERBY-2014 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2014-trunk-diff01.txt, derby2014-trunk-diff02.txt, > derby2014-trunk-stat01.txt, derby2014-trunk-stat02.txt > > > A NPE occurs when NULLIF is used in the GROUP BY clause. > ij> create table t1 (c1 int); > 0 rows inserted/updated/deleted > ij> insert into t1 values 1,2,2,3; > 4 rows inserted/updated/deleted > ij> select nullif(c1,c1) from t1 group by nullif(c1,c1); > ERROR XJ001: Java exception: ': java.lang.NullPointerException'. > Stacktrace: > java.lang.NullPointerException > at > org.apache.derby.impl.sql.compile.ConstantNode.isEquivalent(ConstantNode.java:285) > at > org.apache.derby.impl.sql.compile.CastNode.isEquivalent(CastNode.java:1044) > at > org.apache.derby.impl.sql.compile.ConditionalNode.isEquivalent(ConditionalNode.java:518) > at > org.apache.derby.impl.sql.compile.GroupByList.findGroupingColumn(GroupByList.java:244) > at > org.apache.derby.impl.sql.compile.VerifyAggregateExpressionsVisitor.skipChildren(VerifyAggregateExpressionsVisitor.java:146) > at > org.apache.derby.impl.sql.compile.ConditionalNode.accept(ConditionalNode.java:484) > at > org.apache.derby.impl.sql.compile.ResultColumn.accept(ResultColumn.java:1515) > at > org.apache.derby.impl.sql.compile.QueryTreeNodeVector.accept(QueryTreeNodeVector.java:159) > at > org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:619) > at > org.apache.derby.impl.sql.compile.FromSubquery.bindExpressions(FromSubquery.java:262) > at > org.apache.derby.impl.sql.compile.FromList.bindExpressions(FromList.java:337) > at > org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:500) > at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:249) > at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:162) > at > org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java:253) > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:345) > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:119) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:745) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:568) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:321) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:517) > at > org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:370) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:268) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:204) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170) > at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) > at org.apache.derby.tools.ij.main(ij.java:71) > sysinfo: > -- Java Information -- > Java Version:1.4.2_12 > Java Vendor: Sun Microsystems Inc. > Java home: C:\jdk142\jre > Java classpath: classes;. > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: yip > Java user home: C:\Documents and Settings\Administrator > Java user dir: C:\derby\trunk > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\derby\trunk\classes] 10.3.0.0 alpha - (1) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.3.0.0 alpha - (1) > Found support for locale: [es] > version: 10.3.0.0 alpha - (1) > Found support for locale: [fr] > version: 10.3.0.0 alpha - (1) > Found support for locale: [it] > version: 10.3.0.0 alpha - (1) > Found support for locale: [ja_JP] > version: 10.3.0.0 alpha - (1) > Found support for locale: [ko_KR] > version: 10.3.0.0 alpha - (1) > Found support for locale: [pt_BR] > version: 10.3.0.0 alpha - (1) > Found support for
[jira] Updated: (DERBY-2014) NullPointerException with NULLIF in GROUP BY clause
[ http://issues.apache.org/jira/browse/DERBY-2014?page=all ] Yip Ng updated DERBY-2014: -- Attachment: derby2014-trunk-stat02.txt derby2014-trunk-diff02.txt Attaching patch derby2014-trunk-diff02.txt for DERBY-2014. This patch converts all the tests in the previous patch into junit. Also the javadoc for ValueNode.isEquivalent() method has been updated. Please review. (I hope the javadoc is clear, if not, please let me know.) > NullPointerException with NULLIF in GROUP BY clause > --- > > Key: DERBY-2014 > URL: http://issues.apache.org/jira/browse/DERBY-2014 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2014-trunk-diff01.txt, derby2014-trunk-diff02.txt, > derby2014-trunk-stat01.txt, derby2014-trunk-stat02.txt > > > A NPE occurs when NULLIF is used in the GROUP BY clause. > ij> create table t1 (c1 int); > 0 rows inserted/updated/deleted > ij> insert into t1 values 1,2,2,3; > 4 rows inserted/updated/deleted > ij> select nullif(c1,c1) from t1 group by nullif(c1,c1); > ERROR XJ001: Java exception: ': java.lang.NullPointerException'. > Stacktrace: > java.lang.NullPointerException > at > org.apache.derby.impl.sql.compile.ConstantNode.isEquivalent(ConstantNode.java:285) > at > org.apache.derby.impl.sql.compile.CastNode.isEquivalent(CastNode.java:1044) > at > org.apache.derby.impl.sql.compile.ConditionalNode.isEquivalent(ConditionalNode.java:518) > at > org.apache.derby.impl.sql.compile.GroupByList.findGroupingColumn(GroupByList.java:244) > at > org.apache.derby.impl.sql.compile.VerifyAggregateExpressionsVisitor.skipChildren(VerifyAggregateExpressionsVisitor.java:146) > at > org.apache.derby.impl.sql.compile.ConditionalNode.accept(ConditionalNode.java:484) > at > org.apache.derby.impl.sql.compile.ResultColumn.accept(ResultColumn.java:1515) > at > org.apache.derby.impl.sql.compile.QueryTreeNodeVector.accept(QueryTreeNodeVector.java:159) > at > org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:619) > at > org.apache.derby.impl.sql.compile.FromSubquery.bindExpressions(FromSubquery.java:262) > at > org.apache.derby.impl.sql.compile.FromList.bindExpressions(FromList.java:337) > at > org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:500) > at > org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:249) > at > org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:162) > at > org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java:253) > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:345) > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:119) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:745) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:568) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:321) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:517) > at > org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:370) > at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:268) > at org.apache.derby.impl.tools.ij.Main.go(Main.java:204) > at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170) > at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) > at org.apache.derby.tools.ij.main(ij.java:71) > sysinfo: > -- Java Information -- > Java Version:1.4.2_12 > Java Vendor: Sun Microsystems Inc. > Java home: C:\jdk142\jre > Java classpath: classes;. > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: yip > Java user home: C:\Documents and Settings\Administrator > Java user dir: C:\derby\trunk > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\derby\trunk\classes] 10.3.0.0 alpha - (1) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] > version: 10.3.0.0 alpha - (1) > Found support for locale: [es] > version: 10.3.0.0 alpha - (1) > Found support for locale: [fr] > version: 10.3.0.0 alph
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446781 ] Daniel John Debrunner commented on DERBY-2006: -- So I guess junitreport is the intended top-level target? junit-all runs all the tests but does not reproduce a report junitreport depends on junit-all and then runs a report > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446778 ] Daniel John Debrunner commented on DERBY-2006: -- Just seems it requires CLASSPATH to be set to include the derby code and junit.jar. At least doing that is getting me further! > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Mamta Satoor as a committer for the Apache Derby project
Mike Matrigali wrote: This vote is for establishing Mamta Satoor (email: [EMAIL PROTECTED]) as a committer for Derby. Please vote +1 if you approve of Mamta as a committer. Voting will close 5pm PST Thursday, November 9th. Since joining the project, Mamta has submitted many high quality, well documented patches. Most recently she worked on the Grant/Revoke feature in the 10.2 release. She has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe her expertise will be valuable going forward as a derby committer. /mikem +1 Manjula
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446776 ] Daniel John Debrunner commented on DERBY-2006: -- Dumb question, but what are the requirements to be able to run this task. I executed ant junit-all and got BUILD FAILED C:\_work\svn_linq\trunk\build.xml:1631: Could not create task or type of type: j unit. Ant could not find the task or a class this task relies upon. > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
+1CraigAndrew McIntyre wrote:I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED])as a committer for Derby.Myrna is very active in all areas of testing, has contributed fixes inother areas as well, and contributes to discussions on a wide varietyof issues. Her contributions are of a consistently high quality, andhas contributed improvements to the documentation as well as the code.To her credit, Myrna accumulated the highest number of fixed JIRAentries for any non-committer in the time between the 10.1 and 10.2releases. :-)Please vote +1 if you approve of Myrna as a committer. I will closethe voting at 10am PST on Tuesday, November 7th. Craig Russell[EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (DERBY-2038) lang/releaseCompileLocks.sql and lang/closed.java fail under JDK 1.6 in insane mode
lang/releaseCompileLocks.sql and lang/closed.java fail under JDK 1.6 in insane mode --- Key: DERBY-2038 URL: http://issues.apache.org/jira/browse/DERBY-2038 Project: Derby Issue Type: Bug Components: Regression Test Failure, Test Affects Versions: 10.3.0.0 Environment: JDK 1.6, insane build of Derby Reporter: Knut Anders Hatlen Priority: Minor These tests fail on all platforms with JDK 1.6 when run against an insane build of Derby. They don't fail when run against a sane build. See for instance http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/sparc/469556-derbyall_diff.txt * Diff file derbyall/derbylang/closed.diff *** Start: closed jdk1.6.0-rc derbyall:derbylang 2006-11-01 05:42:42 *** 17 del < ... 10 more 17a17 > ... 11 more 25 del < ... 10 more 25a25 > ... 11 more Test Failed. *** End: closed jdk1.6.0-rc derbyall:derbylang 2006-11-01 05:42:55 *** * Diff file derbyall/derbylang/releaseCompileLocks.diff *** Start: releaseCompileLocks jdk1.6.0-rc derbyall:derbylang 2006-11-01 06:11:35 *** 50 del < ... 28 more 50a50 > ... 29 more 70 del < ... 28 more 70a70 > ... 29 more Test Failed. The problem seems to be that the number of stack trace elements printed is different for sane and insane builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=all ] Andrew McIntyre resolved DERBY-2006. Fix Version/s: 10.3.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Committed _v6 patch to trunk with revision 470604. > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=all ] Andrew McIntyre reassigned DERBY-2006: -- Assignee: Andrew McIntyre > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Assigned To: Andrew McIntyre > Fix For: 10.3.0.0 > > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. +1
Re: [jira] Updated: (DERBY-801) Allow parallel access to data files.
Anders Morken (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
Attachment: DERBY-801-6.patch
DERBY-801-6.patch remedies the noise from the iosInProgress sanity checking by checking the committed drop state before croaking.
I've run jdbcapi/LobLengthTest.junit 100 times in a row now without seeing any problems,
and I used to see the problem once every four or five runs without this patch.
RAFContainer4.java |7 ++-
1 files changed, 6 insertions(+), 1 deletion(-)
Thanks for continuing to improve the fix for this problem, Anders.
I'm not sure checking for the committed drop state in the readPage method is something
we want to do - flushing the cache into a black hole is one thing, trying to read data that
is supposed to be gone is another - I think I'd want to know if we had some logic that permitted
reading from a dropped container. =)
I doubt reading from a commit dropped container happen through the
readPage() call in parallel to drops. Locks/Latches/flags should
make sure that does not occur. I think only time we may read from the
dropped container may be during recovery, if there is a crash just
before stub was created for the dropped container, if container marked
commit dropped , then I think only header is read , but that info is
read by reading directly few bytes from the first page.
I've sort of got a feeling that maybe we are masking a problem here -
should anyone (even the cache?) write to a dropped container?
Pages are discarded from cache before the container is stubbed. See
(removeContainer.pageCache.discard(identity .
Maybe we should remove
pages destined for a dying container from the cache when the
container is dropped? =)
I agree with removing/closing container does not seem to be the right
thing to do when I/O is in progress. Having said that, I am also
wondering if it is a over-kill to add more synchronization for this
case. May be catching for ClosedChannelException is good enough .
One more thing I alos noticed going through the code again is
DEBUG_PRINT("RAFContainer4"," .. statements. As Knut mentioned , they
of no use. No one looks at them unless a test fails. If those cases
should not happen , then throwing an ASSERT failure is better,
otherwise please remove those PRINT statements.
Thanks
-suresh
[jira] Created: (DERBY-2037) provide checking tool to flag possible errors in message translations
provide checking tool to flag possible errors in message translations - Key: DERBY-2037 URL: http://issues.apache.org/jira/browse/DERBY-2037 Project: Derby Issue Type: Test Components: Localization Affects Versions: 10.3.0.0 Reporter: Myrna van Lunteren Assigned To: Myrna van Lunteren Priority: Minor It would be useful to have a tool available that flags possible translation file issues, such as: - missing translations for (new) English messages - mismatched parameters between English and non-English messages - translation of keywords - quoting problems (i.e. use of double quotes when single quotes should be used, use of single quotes when double quotes should be used. This is based on what's described in the MessageFormat api doc) - mismatched characters such as < (when meaning smaller than), > (when meaning larger than), % etc. - identification of invalid characters, specifically characters in the range of 0x00-0x1f (which are ASCII) and 0x7f-0xff Note that such a tool cannot be definite (except about the missing messages) because the English messages are not following very strict formatting, and because what's acceptable syntax/grammar in one language may not work in another. A discussion about a first cut at such a tool can be found at: http://comments.gmane.org/gmane.comp.apache.db.derby.devel/32187 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2036) junit testing with j2ME / wctme 5.7 foundation fails with java.sql.SQLException: org.apache.derby.jdbc.EmbeddedDriver is not registered with the JDBC driver manager
junit testing with j2ME / wctme 5.7 foundation fails with java.sql.SQLException: org.apache.derby.jdbc.EmbeddedDriver is not registered with the JDBC driver manager Key: DERBY-2036 URL: http://issues.apache.org/jira/browse/DERBY-2036 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Environment: Running the junit tests with junit 3.8.1. junit.textui.TestRunner with wctme 5.7 jcl:foun10 Reporter: Myrna van Lunteren Running the junit tests (suites.All) with junit 3.8.1. as described in http://wiki.apache.org/db-derby/JunitVmIssues#head-0916dd3630b0667e49460439fbd041c720d93eaf fails with the following stack trace: EEE.EE.EFjava.sql.SQLException: org.apache.derby.jdbc.EmbeddedDriver is not registered with the JDBC driver manager at org.apache.derby.jdbc.EmbeddedSimpleDataSource.findDriver(EmbeddedSimpleDataSource.java:435) at org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) at org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) at org.apache.derbyTesting.junit.TestConfiguration.getConnection(TestConfiguration.java:626) at org.apache.derbyTesting.junit.TestConfiguration.getDefaultConnection(TestConfiguration.java:592) at org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(TestConfiguration.java:566) at org.apache.derbyTesting.junit.BaseJDBCTestSetup.getConnection(BaseJDBCTestSetup.java:74) at org.apache.derbyTesting.functionTests.tests.jdbcapi.SURDataModelSetup.setUp(SURDataModelSetup.java:137) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1785) junit tests fail with permission access problems when run with j9 jvms
[ http://issues.apache.org/jira/browse/DERBY-1785?page=all ] Myrna van Lunteren closed DERBY-1785. - Resolution: Fixed > junit tests fail with permission access problems when run with j9 jvms > -- > > Key: DERBY-1785 > URL: http://issues.apache.org/jira/browse/DERBY-1785 > Project: Derby > Issue Type: Test > Components: Test, Regression Test Failure >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: using ibm's j9 jvm as available with wssd5.6 or wctme5.7 > (jcl:Max or jcl:foundation configuration) >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Fix For: 10.2.2.0, 10.3.0.0 > > Attachments: DERBY-1785_102_20061007.diff, DERBY-1785_20061007.diff > > > The junit tests have been made to run with security manager. > Until now, using the org.apache.derbyTesting.functionTests.harness classes, > there was exception logic that stopped the j9 jvms from running with security > manager, but that's now changed for the junit tests. > For instance, the test store/bootAllTest.junit fails with the following error: > There was 1 error: > 1) > testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)java.security.AccessControlException: > Access denied (java.util.PropertyPermission framework read) > at > java.security.AccessController.checkPermission(AccessController.java:74) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) > at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:366) > at java.lang.System.getProperty(System.java:319) > at java.lang.System.getProperty(System.java:301) > at > org.apache.derbyTesting.functionTests.util.TestUtil$1.run(TestUtil.java:177) > at > java.security.AccessController.doPrivileged(AccessController.java:147) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getFramework(TestUtil.java:174) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getDataSourcePrefix(TestUtil.java:391) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getSimpleDataSource(TestUtil.java:330) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getDataSource(TestUtil.java:324) > at > org.apache.derbyTesting.functionTests.util.TestDataSourceFactory.getDataSource(TestDataSourceFactory.java:47) > at > org.apache.derbyTesting.junit.TestConfiguration.openConnection(TestConfiguration.java:296) > at > org.apache.derbyTesting.junit.BaseJDBCTestCase.openConnection(BaseJDBCTestCase.java:197) > at > org.apache.derbyTesting.functionTests.tests.store.BootAllTest.setUp(BootAllTest.java:58) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1785) junit tests fail with permission access problems when run with j9 jvms
[ http://issues.apache.org/jira/browse/DERBY-1785?page=comments#action_12446773 ] Myrna van Lunteren commented on DERBY-1785: --- I tried running with junit and wctme5.7 (foundation) according to the suggestions above, and I did not see the permission exception. So I guess this issue can be closed. I did see a bunch of other exceptions, starting with: EEE.EE.EFjava.sql.SQLException: org.apache.derby.jdbc.EmbeddedDriver is not registered with the JDBC driver manager at org.apache.derby.jdbc.EmbeddedSimpleDataSource.findDriver(EmbeddedSimpleDataSource.java:435) at org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:406) at org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(EmbeddedSimpleDataSource.java:373) at org.apache.derbyTesting.junit.TestConfiguration.getConnection(TestConfiguration.java:626) at org.apache.derbyTesting.junit.TestConfiguration.getDefaultConnection(TestConfiguration.java:592) at org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(TestConfiguration.java:566) at org.apache.derbyTesting.junit.BaseJDBCTestSetup.getConnection(BaseJDBCTestSetup.java:74) at org.apache.derbyTesting.functionTests.tests.jdbcapi.SURDataModelSetup.setUp(SURDataModelSetup.java:137) But I will open another issue to track that problem. > junit tests fail with permission access problems when run with j9 jvms > -- > > Key: DERBY-1785 > URL: http://issues.apache.org/jira/browse/DERBY-1785 > Project: Derby > Issue Type: Test > Components: Test, Regression Test Failure >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: using ibm's j9 jvm as available with wssd5.6 or wctme5.7 > (jcl:Max or jcl:foundation configuration) >Reporter: Myrna van Lunteren > Assigned To: Myrna van Lunteren >Priority: Minor > Fix For: 10.2.2.0, 10.3.0.0 > > Attachments: DERBY-1785_102_20061007.diff, DERBY-1785_20061007.diff > > > The junit tests have been made to run with security manager. > Until now, using the org.apache.derbyTesting.functionTests.harness classes, > there was exception logic that stopped the j9 jvms from running with security > manager, but that's now changed for the junit tests. > For instance, the test store/bootAllTest.junit fails with the following error: > There was 1 error: > 1) > testSettingBootAllPropertyWithHomePropertySet(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)java.security.AccessControlException: > Access denied (java.util.PropertyPermission framework read) > at > java.security.AccessController.checkPermission(AccessController.java:74) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) > at > java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:366) > at java.lang.System.getProperty(System.java:319) > at java.lang.System.getProperty(System.java:301) > at > org.apache.derbyTesting.functionTests.util.TestUtil$1.run(TestUtil.java:177) > at > java.security.AccessController.doPrivileged(AccessController.java:147) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getFramework(TestUtil.java:174) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getDataSourcePrefix(TestUtil.java:391) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getSimpleDataSource(TestUtil.java:330) > at > org.apache.derbyTesting.functionTests.util.TestUtil.getDataSource(TestUtil.java:324) > at > org.apache.derbyTesting.functionTests.util.TestDataSourceFactory.getDataSource(TestDataSourceFactory.java:47) > at > org.apache.derbyTesting.junit.TestConfiguration.openConnection(TestConfiguration.java:296) > at > org.apache.derbyTesting.junit.BaseJDBCTestCase.openConnection(BaseJDBCTestCase.java:197) > at > org.apache.derbyTesting.functionTests.tests.store.BootAllTest.setUp(BootAllTest.java:58) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: (DERBY-378) implementing import/export of large objects...
Suresh Thalamati wrote: Mike Matrigali wrote: Suresh Thalamati wrote: Daniel John Debrunner wrote: Suresh Thalamati wrote: BLOB: 1) Allow import/export of blob data only when they it is stored in an external file. 2) Write the blob data to the export file along with other data types during export, assuming the blob data does not contain any delimiters and throw an error if on import if it finds delimiters inside the data, by interpreting it using the same code-set as the other character data. I say option 1) and I assume it's for all binary data, not just BLOB, e.g. VARCHAR FOR BIT DATA etc. Seems like with binary data the chance of having a problematic character in the text file is close to 100%. Dan. Thanks for reading the proposal, Dan. I agree with you , chance of finding delimiter character inside a binary data is very high. I will go with the option 1. Your assumption is correct , it applies to all the binary data. I also agree, it seems like a reasonable first step to default binary export/import to external files. I am probably missing something here though. I thought for char data there is an algorithm that handles delimiter data within it. Why does that not work for binary data also? Is it a codeset issue? Yes. For character data, double delimiters are used if there are delimiter characters inside the data. i.e say if a column contains 'he said "derby is solid database" ' , then it is written to the export file as "he said ""derby is a solid database "" " . So on export of the data, data is modified before writing to the file. It may be possible to do the same thing by interpreting the binary data in specified code-set and add an extra delimiter for every delimiter found on export and do the reverse on import. But unlike the character data , if the binary data is changed and if user import it to some other application, the data may mean/look completely different if the added extra delimiter characters are not removed. Again I think the separate file/no delimiter solution is a good first approach, I just wanted to understand the issue. As you point out there are multiple usage scenario's here: 1) someone has a derby db and wants to export for use into another derby db. 2) someone has a derby db and wants to export for use in another application. 3) someone has some data from another app and wants to import into derby. I think the separate file solution works for #1. I don't know how well it works for option #2 and #3. But at least for #2 it results in the raw data without need to process it. Another thing to note here is in a character data user knows there might be delimiter characters inside and specify a delimiter character that is not in the data, if he/she does not want data to modified on export. Where as with binary data that is not possible at all. If you think modifying a binary data on export is ok, then it might be possible to use same concept as character data. My only concern here is if we export image of a "cat" and add delimiters to it by interpreting it as character data, it may look like a "tiger" if extra characters added is not removed :-) Thanks -suresh
[jira] Commented: (DERBY-801) Allow parallel access to data files.
[
http://issues.apache.org/jira/browse/DERBY-801?page=comments#action_12446767 ]
Knut Anders Hatlen commented on DERBY-801:
--
Thanks Anders. I committed DERBY-801-6.patch with revision 470573.
> I'm not sure checking for the committed drop state in the readPage
> method is something we want to do - flushing the cache into a black
> hole is one thing, trying to read data that is supposed to be gone
> is another
You are of course right about the error checking in readPage().
> I've sort of got a feeling that maybe we are masking a problem here
> - should anyone (even the cache?) write to a dropped container?
Actually, I think it's the other way around. We are not writing to a
dropped container, but dropping a container which we happen to be
writing to. Since the dropping of the container has been committed, we
know that we'll never need those pages, so there's no need to complete
the write operations. The alternative would be to let closeContainer()
wait until all write operations on the container have finished.
> Maybe we should remove pages destined for a dying container from the
> cache when the container is dropped?
After the container has been dropped, it shouldn't be a problem
because getCommittedDropState() returns true, so writePage() will
return immediately without trying to write the page. Also, the pages
will be marked as invalid so that the cache space can be reclaimed.
> Allow parallel access to data files.
>
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
>Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-v2.patch,
> DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch,
> NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2035) Setting the database class path takes effect for the current connection but not others until a database reboot.
Setting the database class path takes effect for the current connection but not others until a database reboot. --- Key: DERBY-2035 URL: http://issues.apache.org/jira/browse/DERBY-2035 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.6 Reporter: Daniel John Debrunner Priority: Minor After setting the derby.database.classpath as a database property the current connection sees its effects, such as being able to load classes from the jar added into the class path. However a newly opened connection does not see its effect. Shutting down and re-booting the database makes the change visible to all. The new test lang.DatabaseClassLoadingTest will have code that shows this bug commented with this bug number. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: > I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) > as a committer for Derby. +1 -jean
Re: [VOTE] Mamta Satoor as a committer for the Apache Derby project
Mike Matrigali wrote: > This vote is for establishing Mamta Satoor (email: [EMAIL PROTECTED]) as > a committer for Derby. +1 -jean
[jira] Commented: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=comments#action_12446754 ] Jean T. Anderson commented on DERBY-1980: - Thanks for being a pest, Army. :-) Fixed in 470574. > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2034) Tracking of bugs that lead to incorrect being stored or returned to the client
Tracking of bugs that lead to incorrect being stored or returned to the client -- Key: DERBY-2034 URL: http://issues.apache.org/jira/browse/DERBY-2034 Project: Derby Issue Type: Task Reporter: Daniel John Debrunner Priority: Trivial Just a placeholder to link bugs that cause an application to get incorrect data results. Queries that fail to compile are not linked here as an application would notice such failures and not use the statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=comments#action_12446751 ] A B commented on DERBY-1980: Not to be a pest, but I think the word "org" is still missing from the filename: > ls java/engine/apache/derby/loc/messages_en.properties ls: File or directory "java/engine/apache/derby/loc/messages_en.properties" is not found > ls java/engine/org/apache/derby/loc/messages_en.properties java/engine/org/apache/derby/loc/messages_en.properties > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=comments#action_12446748 ] Rick Hillegas commented on DERBY-1980: -- Andrew and Jean are right. The file which should not be editted is messages_en.properties. The confusion was sown by me: my original message on this topic contained the offending blooper. > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: (DERBY-378) implementing import/export of large objects...
Mike Matrigali wrote: Suresh Thalamati wrote: Daniel John Debrunner wrote: Suresh Thalamati wrote: BLOB: 1) Allow import/export of blob data only when they it is stored in an external file. 2) Write the blob data to the export file along with other data types during export, assuming the blob data does not contain any delimiters and throw an error if on import if it finds delimiters inside the data, by interpreting it using the same code-set as the other character data. I say option 1) and I assume it's for all binary data, not just BLOB, e.g. VARCHAR FOR BIT DATA etc. Seems like with binary data the chance of having a problematic character in the text file is close to 100%. Dan. Thanks for reading the proposal, Dan. I agree with you , chance of finding delimiter character inside a binary data is very high. I will go with the option 1. Your assumption is correct , it applies to all the binary data. I also agree, it seems like a reasonable first step to default binary export/import to external files. I am probably missing something here though. I thought for char data there is an algorithm that handles delimiter data within it. Why does that not work for binary data also? Is it a codeset issue? Yes. For character data, double delimiters are used if there are delimiter characters inside the data. i.e say if a column contains 'he said "derby is solid database" ' , then it is written to the export file as "he said ""derby is a solid database "" " . So on export of the data, data is modified before writing to the file. It may be possible to do the same thing by interpreting the binary data in specified code-set and add an extra delimiter for every delimiter found on export and do the reverse on import. But unlike the character data , if the binary data is changed and if user import it to some other application, the data may mean/look completely different if the added extra delimiter characters are not removed. Another thing to note here is in a character data user knows there might be delimiter characters inside and specify a delimiter character that is not in the data, if he/she does not want data to modified on export. Where as with binary data that is not possible at all. If you think modifying a binary data on export is ok, then it might be possible to use same concept as character data. My only concern here is if we export image of a "cat" and add delimiters to it by interpreting it as character data, it may look like a "tiger" if extra characters added is not removed :-) Thanks -suresh
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre <[EMAIL PROTECTED]> writes: > I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) > as a committer for Derby. +1 -- Knut Anders
[jira] Commented: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=comments#action_12446746 ] Jean T. Anderson commented on DERBY-1980: - Thanks for that correction, Andrew. It's fixed in revision 470562 and will be visible after the next web site sync. > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-801) Allow parallel access to data files.
[ http://issues.apache.org/jira/browse/DERBY-801?page=all ]
Anders Morken updated DERBY-801:
Attachment: DERBY-801-6.patch
DERBY-801-6.patch remedies the noise from the iosInProgress sanity checking by
checking the committed drop state before croaking. I've run
jdbcapi/LobLengthTest.junit 100 times in a row now without seeing any problems,
and I used to see the problem once every four or five runs without this patch.
RAFContainer4.java |7 ++-
1 files changed, 6 insertions(+), 1 deletion(-)
I'm not sure checking for the committed drop state in the readPage method is
something we want to do - flushing the cache into a black hole is one thing,
trying to read data that is supposed to be gone is another - I think I'd want
to know if we had some logic that permitted reading from a dropped container. =)
I've sort of got a feeling that maybe we are masking a problem here - should
anyone (even the cache?) write to a dropped container? Maybe we should remove
pages destined for a dying container from the cache when the container is
dropped? =)
> Allow parallel access to data files.
>
>
> Key: DERBY-801
> URL: http://issues.apache.org/jira/browse/DERBY-801
> Project: Derby
> Issue Type: Improvement
> Components: Performance, Store
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1
> Environment: Any
>Reporter: Øystein Grøvlen
> Assigned To: Anders Morken
> Attachments: DERBY-801-6.patch, DERBY-801-v2.patch,
> DERBY-801-v3.patch, DERBY-801-v4.patch, DERBY-801-v5.patch,
> NIO-RAFContainer-v1.patch
>
>
> Derby currently serializes accesses to a data file. For example, the
> implementation of RAFContainer.readPage is as follows:
> synchronized (this) { // 'this' is a FileContainer, i.e. a file object
> fileData.seek(pageOffset); // fileData is a RandomAccessFile
> fileData.readFully(pageData, 0, pageSize);
> }
> I have experiemented with a patch where I have introduced several file
> descriptors (RandomAccessFile objects) per RAFContainer. These are
> used for reading. The principle is that when all readers are busy, a
> readPage request will create a new reader. (There is a maximum number
> of readers.) With this patch, throughput was improved by 50% on
> linux. For more discussion on this, see
> http://www.nabble.com/Derby-I-O-issues-during-checkpointing-t473523.html
> The challenge with the suggested approach is to make a mechanism to
> limit the number of open file descpriptors. Mike Matrigali has
> suggested to use the existing CacheManager infrastructure for this
> purpose. For a discussion on that, see:
> http://www.nabble.com/new-uses-for-basic-services-cache---looking-for-advice-t756863.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote (2006-11-02 10:11:55): > Please vote +1 if you approve of Myrna as a committer. I will close > the voting at 10am PST on Tuesday, November 7th. +1 -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: Digital signature
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: Please vote +1 if you approve of Myrna as a committer. +1 Army
[jira] Commented: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=comments#action_12446741 ] Andrew McIntyre commented on DERBY-1980: The sentence further down the page should read: "Do not edit the java/engine/apache/derby/loc/messages_en.properties file." > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
+1 Henri Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby.
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. +1 Great benefit to the community. Dan.
Re: [VOTE] Myrna Van Lunteren as a committer
On 11/2/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED])as a committer for Derby.+1Yip Ng
[jira] Commented: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=comments#action_12446725 ] Jean T. Anderson commented on DERBY-1980: - Committed derby1980_5.diff revision 470517. Changes should be visible on the web site within an hour. Thanks for the patch, Laura. I think there's some confusion in the new messages page, but it will be easier for people to review when the changes are on the web site. This statement: "When you add internationalized messages to the Derby engine, add the messages to the xml descriptors file that is located in ..java/engine/org/apache/derby/loc/messages.xml." Seems to contradict this sentence further down the page: "Do not edit the java/engine/apache/derby/loc/messages.xml file. This file has been removed from code management and is now generated from messages.xml during the Derby build." Which file are messages supposed to be added to? > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
[ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12446719 ] Myrna van Lunteren commented on DERBY-2006: --- I ran after applying patch v6; I saw 3 failures (networkserver timeouts). I think this looks good and should be committed. Any further improvements can get added later. > Add JUnit and JUnitReport task as a target in Ant script > > > Key: DERBY-2006 > URL: http://issues.apache.org/jira/browse/DERBY-2006 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 > Environment: Any >Reporter: Yip Ng > Attachments: derby_2006_v1.diff, derby_2006_v2.diff, > derby_2006_v3.diff, derby_2006_v4.diff, derby_2006_v5.diff, > derby_2006_v6.diff, example_output.zip > > > Ant has an optional tasks called JUnit and JUnitReport that runs JUnit tests > and produces JUnit report respectively. It will be nice to have these > mechanism incorporated into the Ant script so one can easily kick off a JUnit > test and view the result. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=all ] Laura Stewart updated DERBY-1980: - Attachment: derby1980_5.diff derby1980_5.stat Recreated the diff and stat files from the src directory. > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_5.diff, derby1980_5.stat, derby1980_html1.zip, > derby1980_html3.zip, derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2001) Add DITA templates for the 3 topic types into the trunk
[ http://issues.apache.org/jira/browse/DERBY-2001?page=comments#action_12446714 ] Kim Haase commented on DERBY-2001: -- The reference template looks very good. Like the others, it lays out the correct sequence of tags and the most common usage. I notice it suggests to use a for syntax rather than , which seems wise. The element seems way too complicated; the descriptions and examples of its subelements in the DITA spec are hard to understand; and with these subelements, it is hard to tell from the source what the output will look like. Using a more wysiwyg tag keeps it simple. I would suggest that in these templates we use line breaks in logical places, to encourage writers of new topics to make them as readable as possible. For example, for the element, the draft shows the entire element contents on one line, with the only line break being the one required in the (though I'm not sure this will be clear here): SyntaxCREATE [ UNIQUE ] INDEX IndexName ON TableName (SimpleColumnName [ , SimpleColumnName] * ) It might make more sense to do something like this: Syntax CREATE [ UNIQUE ] INDEX IndexName ON TableName (SimpleColumnName [ , SimpleColumnName] * ) I expect you also meant the sections on paragraphs and tables to begin on a new line. I just noticed that in the SHORT DESCRIPTION section in each template, "for first" should be "for the first". > Add DITA templates for the 3 topic types into the trunk > --- > > Key: DERBY-2001 > URL: http://issues.apache.org/jira/browse/DERBY-2001 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Laura Stewart > Assigned To: Laura Stewart > Fix For: 10.2.1.8 > > Attachments: concept_template.dita, derby2001_1.diff, > derby2001_1.stat, reference_template.dita, task_template.dita > > > Create templates for each of the DITA topic types - concept, reference, task > Add these templates to the Derby trunk so that anyone can use them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
+1 David Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. Myrna is very active in all areas of testing, has contributed fixes in other areas as well, and contributes to discussions on a wide variety of issues. Her contributions are of a consistently high quality, and has contributed improvements to the documentation as well as the code. To her credit, Myrna accumulated the highest number of fixed JIRA entries for any non-committer in the time between the 10.1 and 10.2 releases. :-) Please vote +1 if you approve of Myrna as a committer. I will close the voting at 10am PST on Tuesday, November 7th. And, my vote: +1 andrew
[jira] Assigned: (DERBY-2033) Convert lang/dcl.sql test to JUnit
[ http://issues.apache.org/jira/browse/DERBY-2033?page=all ] Daniel John Debrunner reassigned DERBY-2033: Assignee: Daniel John Debrunner > Convert lang/dcl.sql test to JUnit > -- > > Key: DERBY-2033 > URL: http://issues.apache.org/jira/browse/DERBY-2033 > Project: Derby > Issue Type: Sub-task > Components: Test >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > Fix For: 10.3.0.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2033) Convert lang/dcl.sql test to JUnit
Convert lang/dcl.sql test to JUnit -- Key: DERBY-2033 URL: http://issues.apache.org/jira/browse/DERBY-2033 Project: Derby Issue Type: Sub-task Components: Test Reporter: Daniel John Debrunner Fix For: 10.3.0.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. +1 I think Myrna would be a good additions, she has contributed a lot of work in the testing area, and all of her patches that I have looked at have been good. As a committer I think she would be even more productive in keeping the tests running, clean and improving.
[jira] Closed: (DERBY-2021) Ensure all tests called by jdbcapi._Suite run in embedded and client as required.
[ http://issues.apache.org/jira/browse/DERBY-2021?page=all ] Daniel John Debrunner closed DERBY-2021. Resolution: Fixed ConcurrencyTest fixed by revision 470492 > Ensure all tests called by jdbcapi._Suite run in embedded and client as > required. > - > > Key: DERBY-2021 > URL: http://issues.apache.org/jira/browse/DERBY-2021 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > > These tests have not been updated to run in client and embedded when run > stand alone > ConcurrencyTest.suite() > ProcedureTest.suite() > SURQueryMixTest.suite() > SURTest.suite() > UpdateXXXTest.suite() > ResultSetCloseTest.suite() > DataSourcePropertiesTest.suite() > If a test is not to run in client that fact should be documented with the > reason why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: (DERBY-378) implementing import/export of large objects...
Suresh Thalamati wrote: Daniel John Debrunner wrote: Suresh Thalamati wrote: BLOB: 1) Allow import/export of blob data only when they it is stored in an external file. 2) Write the blob data to the export file along with other data types during export, assuming the blob data does not contain any delimiters and throw an error if on import if it finds delimiters inside the data, by interpreting it using the same code-set as the other character data. I say option 1) and I assume it's for all binary data, not just BLOB, e.g. VARCHAR FOR BIT DATA etc. Seems like with binary data the chance of having a problematic character in the text file is close to 100%. Dan. Thanks for reading the proposal, Dan. I agree with you , chance of finding delimiter character inside a binary data is very high. I will go with the option 1. Your assumption is correct , it applies to all the binary data. I also agree, it seems like a reasonable first step to default binary export/import to external files. I am probably missing something here though. I thought for char data there is an algorithm that handles delimiter data within it. Why does that not work for binary data also? Is it a codeset issue? Thanks -suresh
Re: [VOTE] Myrna Van Lunteren as a committer
+1 On 11/2/06, Sunitha Kambhampati <[EMAIL PROTECTED]> wrote: Andrew McIntyre wrote:> Please vote +1 if you approve of Myrna as a committer.+1 Sunitha.
Re: translation checker...
Andrew McIntyre wrote: A quick scan through Derby's translated message files, converted by me from various encodings using native2ascii, shows that all the characters above 128 have been converted to Unicode Escapes. Grep for \\u00[bcdef] in the directories with translated properties files to see examples. Looking more I now see that properties file format is more that just ISO8859-1 encoding with unicode escapes. The javadoc for Properties.store states much more about which characters are escaped including that: "Characters less than \u0020 and characters greater than \u007E are written as \u for the appropriate hexadecimal value . " This matches what Andrew sees in the Derby files. So any checks should be driven off that description only, and native2ascii and the JLS have no relevance. So checking for non ASCII byte values in the raw stream is the right general idea, but the details need to be more specific, e.g. I think any characters in the range 0x00-0x1f (which are ASCII) and 0x7f-0xff are invalid, and there may be others. Thanks, Dan.
Re: translation checker...
Andrew McIntyre wrote: Also, I do have vague years-old memories of doing testing of translated properties files and discovering that characters in the upper half of the ISO-8859-1 character set, while read properly from the properties file, were not displayed properly when output to the console. If the characters were read properly then there would be no difference in memory between an unicode escape encoded character and a valid upper-half ISO-8859-1 character. Sounds like an unrelated output encoding problem. Dan.
[jira] Commented: (DERBY-2021) Ensure all tests called by jdbcapi._Suite run in embedded and client as required.
[ http://issues.apache.org/jira/browse/DERBY-2021?page=comments#action_12446696 ] Daniel John Debrunner commented on DERBY-2021: -- SURQueryMixTest. and DataSourcePropertiesTest. fixed by revision 470476 Included fixing the bug in DataSourcePropertiesTest. so that it actually ran some tests. :-) > Ensure all tests called by jdbcapi._Suite run in embedded and client as > required. > - > > Key: DERBY-2021 > URL: http://issues.apache.org/jira/browse/DERBY-2021 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > > These tests have not been updated to run in client and embedded when run > stand alone > ConcurrencyTest.suite() > ProcedureTest.suite() > SURQueryMixTest.suite() > SURTest.suite() > UpdateXXXTest.suite() > ResultSetCloseTest.suite() > DataSourcePropertiesTest.suite() > If a test is not to run in client that fact should be documented with the > reason why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Re: translation checker...
On 11/2/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Hmmm, the documentation for native2ascii does not agree with the statement about that characters in the range 128-255 range are converted into Unicode Escapes. It says non-Latin 1 characters are converted, where Latin-1 is the common name for ISO8859-1. Then the native2ascii documentation doesn't agree with what native2ascii actually does. :-) A quick scan through Derby's translated message files, converted by me from various encodings using native2ascii, shows that all the characters above 128 have been converted to Unicode Escapes. Grep for \\u00[bcdef] in the directories with translated properties files to see examples. Also, I do have vague years-old memories of doing testing of translated properties files and discovering that characters in the upper half of the ISO-8859-1 character set, while read properly from the properties file, were not displayed properly when output to the console. These sorts of problems might be fixed now, might not, probably depends on your JVM. Since I've only ever tested with ASCII properties files since then, I wouldn't know for sure. :-) Anyway, I think what we really want to catch are files that haven't been run through native2ascii and are in some encoding that definitely won't work, like UTF-8 or SJIS. Bytes in the file with a value > 127 are one sign that that might be the case. There's probably a better way to figure out if you have a file not in a non-ASCII or ISO8859 encoding, but it may be more complicated than what we need. I'll go do some searching around that. andrew
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: Please vote +1 if you approve of Myrna as a committer. +1 Sunitha.
Re: [VOTE] Mamta Satoor as a committer for the Apache Derby project
+1 Kim Mike Matrigali wrote On 11/01/06 13:12,: > Please vote +1 if you approve of Mamta as a committer.
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. +1 -suresh
[jira] Updated: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=all ] Laura Stewart updated DERBY-1980: - Attachment: derby1980_4.diff derby1980_4.stat derby1980_html4.zip Identified a few minor issues. The latest updates are in the #4 files. > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_4.diff, > derby1980_4.stat, derby1980_html1.zip, derby1980_html3.zip, > derby1980_html4.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
Andrew McIntyre wrote: Please vote +1 if you approve of Myrna as a committer. I will close the voting at 10am PST on Tuesday, November 7th. +1 -- Øystein
[jira] Commented: (DERBY-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=comments#action_12446689 ] Kim Haase commented on DERBY-1948: -- Thank you very much for reviewing and committing this, Jean! > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Fix For: 10.3.0.0, 10.2.1.8 > > Attachments: DERBY-1948-2.diff, DERBY-1948-2.zip, DERBY-1948-3.diff, > DERBY-1948-3.zip, DERBY-1948.diff, DERBY-1948.zip > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2001) Add DITA templates for the 3 topic types into the trunk
[ http://issues.apache.org/jira/browse/DERBY-2001?page=all ] Laura Stewart updated DERBY-2001: - Attachment: derby2001_1.diff derby2001_1.stat Created a folder called "templates" under the trunk, per Andrews recommendation. In that folder are 2 documents - a concept template and a task template. After I resolve some issues with other people who write Derby documentation, I will post a patch with a reference template. > Add DITA templates for the 3 topic types into the trunk > --- > > Key: DERBY-2001 > URL: http://issues.apache.org/jira/browse/DERBY-2001 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Laura Stewart > Assigned To: Laura Stewart > Fix For: 10.2.1.8 > > Attachments: concept_template.dita, derby2001_1.diff, > derby2001_1.stat, reference_template.dita, task_template.dita > > > Create templates for each of the DITA topic types - concept, reference, task > Add these templates to the Derby trunk so that anyone can use them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
+1 Bryan Pendleton wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. Myrna does great work. +1 bryan
Re: [VOTE] Myrna Van Lunteren as a committer
+1 Andrew McIntyre wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. Myrna is very active in all areas of testing, has contributed fixes in other areas as well, and contributes to discussions on a wide variety of issues. Her contributions are of a consistently high quality, and has contributed improvements to the documentation as well as the code. To her credit, Myrna accumulated the highest number of fixed JIRA entries for any non-committer in the time between the 10.1 and 10.2 releases. :-) Please vote +1 if you approve of Myrna as a committer. I will close the voting at 10am PST on Tuesday, November 7th. And, my vote: +1 andrew
[jira] Updated: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=all ] Laura Stewart updated DERBY-1980: - Derby Info: [Patch Available] > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_html1.zip, > derby1980_html3.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=all ] Laura Stewart updated DERBY-1980: - Attachment: derby1980_3.diff derby1980_3.stat derby1980_html3.zip Added another page for Messages. Added a lot more content to the Writing Guidelines page. > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_3.diff, derby1980_3.stat, derby1980_html1.zip, > derby1980_html3.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-2032) MathTrigFunctionsTest can be improved to execute in under ten seconds instead of its current eighty seconds
[ http://issues.apache.org/jira/browse/DERBY-2032?page=all ]
Daniel John Debrunner closed DERBY-2032.
Fix Version/s: 10.3.0.0
Resolution: Fixed
Committed revision 470463
> MathTrigFunctionsTest can be improved to execute in under ten seconds instead
> of its current eighty seconds
> ---
>
> Key: DERBY-2032
> URL: http://issues.apache.org/jira/browse/DERBY-2032
> Project: Derby
> Issue Type: Improvement
> Components: Test
>Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
>Priority: Minor
> Fix For: 10.3.0.0
>
>
> Almost every fixture ends up comping a large number of different statements
> of the form
> VALUES TAN(34.2)
> VALUES {fn TAN(34.2)}
> with different "hrd-coded" values.
> Switching to prepared statements with a parameter marker significantly
> improves the test running time.
> Focus of the test is the math functions, not compilation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=all ] Laura Stewart updated DERBY-1980: - Component/s: Web Site (was: Documentation) Fix Version/s: (was: 10.2.2.0) Affects Version/s: (was: 10.2.1.8) > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Web Site >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_html1.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Myrna Van Lunteren as a committer
Please vote +1 if you approve of Myrna as a committer. I will close the voting at 10am PST on Tuesday, November 7th. And, my vote: +1 andrew +1. Well deserved. -Rajesh
Re: translation checker...
Myrna van Lunteren wrote: On 11/2/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Myrna van Lunteren wrote: > - investigate detecting the non-US-ASCII characters > - maybe changing to ISO-8859-1 instead of UTF8 I don't understand why non-US-ASCII characters need to be detected. Since the defined format of properties file is ISO-8859-1 then non-US-ASCII characters are valid. Much clearer for everyone if we stick to the defined format rather than changing it. Dan. I was basing this on Andrew's comment, you may have missed it...if not, can you please clarify which part you don't understand? "The javadoc for java.util.Properties says ISO8859-1 is used to encode characters in properties files. The JLS, 2nd Edition says all non-ASCII characters needing to be Unicode Escapes in section 3.3. I'm going with the JLS, since native2ascii converts valid ISO8859-1 characters in the 128-255 range into Unicode Escapes. So, maybe LocCompare should detect anything outside of the US-ASCII character set and report that as a problem." This suggests the characters may *not* be non-ASCII, and must be unicode escaped, or did I misinterpret? Hmmm, the documentation for native2ascii does not agree with the statement about that characters in the range 128-255 range are converted into Unicode Escapes. It says non-Latin 1 characters are converted, where Latin-1 is the common name for ISO8859-1. http://en.wikipedia.org/wiki/ISO_8859-1 Andrew refers to the JLS section 3.3 but I'm not sure what relevance that is. It's talking about processing Java source not properties files. Then I can't see in section 3.3 any text that would indicate "all non-ASCII characters needing to be Unicode Escapes". Dan.
Re: [VOTE] Myrna Van Lunteren as a committer
I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. Myrna does great work. +1 bryan
[VOTE] Myrna Van Lunteren as a committer
I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. Myrna is very active in all areas of testing, has contributed fixes in other areas as well, and contributes to discussions on a wide variety of issues. Her contributions are of a consistently high quality, and has contributed improvements to the documentation as well as the code. To her credit, Myrna accumulated the highest number of fixed JIRA entries for any non-committer in the time between the 10.1 and 10.2 releases. :-) Please vote +1 if you approve of Myrna as a committer. I will close the voting at 10am PST on Tuesday, November 7th. And, my vote: +1 andrew
[jira] Updated: (DERBY-2032) MathTrigFunctionsTest can be improved to execute in under ten seconds instead of its current eighty seconds
[ http://issues.apache.org/jira/browse/DERBY-2032?page=all ]
Daniel John Debrunner updated DERBY-2032:
-
Component/s: Test
> MathTrigFunctionsTest can be improved to execute in under ten seconds instead
> of its current eighty seconds
> ---
>
> Key: DERBY-2032
> URL: http://issues.apache.org/jira/browse/DERBY-2032
> Project: Derby
> Issue Type: Improvement
> Components: Test
>Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
>Priority: Minor
>
> Almost every fixture ends up comping a large number of different statements
> of the form
> VALUES TAN(34.2)
> VALUES {fn TAN(34.2)}
> with different "hrd-coded" values.
> Switching to prepared statements with a parameter marker significantly
> improves the test running time.
> Focus of the test is the math functions, not compilation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2032) MathTrigFunctionsTest can be improved to execute in under ten seconds instead of its current eighty seconds
MathTrigFunctionsTest can be improved to execute in under ten seconds instead
of its current eighty seconds
---
Key: DERBY-2032
URL: http://issues.apache.org/jira/browse/DERBY-2032
Project: Derby
Issue Type: Improvement
Reporter: Daniel John Debrunner
Assigned To: Daniel John Debrunner
Priority: Minor
Almost every fixture ends up comping a large number of different statements of
the form
VALUES TAN(34.2)
VALUES {fn TAN(34.2)}
with different "hrd-coded" values.
Switching to prepared statements with a parameter marker significantly improves
the test running time.
Focus of the test is the math functions, not compilation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=all ] Jean T. Anderson resolved DERBY-1948. - Fix Version/s: 10.2.1.8 10.3.0.0 Resolution: Fixed If these changes look good, please close. > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Fix For: 10.2.1.8, 10.3.0.0 > > Attachments: DERBY-1948-2.diff, DERBY-1948-2.zip, DERBY-1948-3.diff, > DERBY-1948-3.zip, DERBY-1948.diff, DERBY-1948.zip > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=all ] Jean T. Anderson updated DERBY-1948: Derby Info: (was: [Patch Available]) > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Attachments: DERBY-1948-2.diff, DERBY-1948-2.zip, DERBY-1948-3.diff, > DERBY-1948-3.zip, DERBY-1948.diff, DERBY-1948.zip > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=comments#action_1244 ] Jean T. Anderson commented on DERBY-1948: - DERBY-1948-3.diff looks good to me, committed to trunk revision 470439 and merged to 10.2 branch revision 470442. Thanks for the patch, Kim. > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Attachments: DERBY-1948-2.diff, DERBY-1948-2.zip, DERBY-1948-3.diff, > DERBY-1948-3.zip, DERBY-1948.diff, DERBY-1948.zip > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-2021) Ensure all tests called by jdbcapi._Suite run in embedded and client as required.
[ http://issues.apache.org/jira/browse/DERBY-2021?page=all ] Daniel John Debrunner reassigned DERBY-2021: Assignee: Daniel John Debrunner > Ensure all tests called by jdbcapi._Suite run in embedded and client as > required. > - > > Key: DERBY-2021 > URL: http://issues.apache.org/jira/browse/DERBY-2021 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > > These tests have not been updated to run in client and embedded when run > stand alone > ConcurrencyTest.suite() > ProcedureTest.suite() > SURQueryMixTest.suite() > SURTest.suite() > UpdateXXXTest.suite() > ResultSetCloseTest.suite() > DataSourcePropertiesTest.suite() > If a test is not to run in client that fact should be documented with the > reason why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1980) Web site - Documentation - Add a new page with writing guidelines
[ http://issues.apache.org/jira/browse/DERBY-1980?page=all ] Jean T. Anderson updated DERBY-1980: Derby Info: (was: [Patch Available]) > Web site - Documentation - Add a new page with writing guidelines > - > > Key: DERBY-1980 > URL: http://issues.apache.org/jira/browse/DERBY-1980 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.8 >Reporter: Laura Stewart > Assigned To: Laura Stewart > Fix For: 10.2.2.0 > > Attachments: derby1980_1.diff, derby1980_1.stat, derby1980_2.diff, > derby1980_2.stat, derby1980_html1.zip, guidelines.xml, site.xml > > > Update the Derby Documentation web pages by: > 1) Adding a new page with guidelines for writing documentation. This includes: > - A description of the topic types > - Templates for the topic types > - Guidelines for tagging (indexes, syntax diagrams) > - Guidelines for titles > - How to create links and work with Reltables > 2) Update the existing instructions forL > - downloading the source > - locating files > - editing existing topic files -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: translation checker...
On 11/2/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Myrna van Lunteren wrote: > - investigate detecting the non-US-ASCII characters > - maybe changing to ISO-8859-1 instead of UTF8 I don't understand why non-US-ASCII characters need to be detected. Since the defined format of properties file is ISO-8859-1 then non-US-ASCII characters are valid. Much clearer for everyone if we stick to the defined format rather than changing it. Dan. I was basing this on Andrew's comment, you may have missed it...if not, can you please clarify which part you don't understand? "The javadoc for java.util.Properties says ISO8859-1 is used to encode characters in properties files. The JLS, 2nd Edition says all non-ASCII characters needing to be Unicode Escapes in section 3.3. I'm going with the JLS, since native2ascii converts valid ISO8859-1 characters in the 128-255 range into Unicode Escapes. So, maybe LocCompare should detect anything outside of the US-ASCII character set and report that as a problem." This suggests the characters may *not* be non-ASCII, and must be unicode escaped, or did I misinterpret? I easily do without the extra work of detecting non-ASCII characters...But if that's a valuable thing, I will look into it. Or it could be a follow up task for another time. Myrna
Re: Tagging bugs - Re: [jira] Commented: (DERBY-2024) Remove JUnit utility method JDBC.vmSupportsJDBC2
On 11/2/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Andrew McIntyre (JIRA) wrote: > [ http://issues.apache.org/jira/browse/DERBY-2024?page=comments#action_12446453 ] > > Andrew McIntyre commented on DERBY-2024: > > > [JDK13CLEANUP] > > I've been marking bugs with that tag in comments to make it easy to query JIRA for tasks related to removing JDK 1.3.1 support. I'll be glad to continue that habit if others find it useful. Is this any better than the existing mechanism where they are all a sub-task of DERBY-1982? Well, it does allow tagging bugs that aren't directly related to removing JDK 1.3 support, but where the solution for the bug required use of a 1.3-specific API that has a better alternative API to use in 1.4, or where some undesirable concession was made to accommodate 1.3 behavior. See, e.g. http://issues.apache.org/jira/browse/DERBY-1462, where additional (undesirable) sedding was added to remove warnings that only occurred on 1.3. I had another example but can't find it because JIRA is being cranky right now. It is an interesting approach though because I've been wondering how to tag a bug as being in a certain category without having to add new Jira fields. For example all bugs that cause incorrect data to be returned to the application. Now seeing your tagging I see it could be done that way or I could enter a Jira issue of type Task and just link relevant bugs to it. I think the tags are nice for this purpose because it's a cross-cutting concern that doesn't fit squarely into the component / issue type scheme. But really, either way works. I like the tagging method because I can pull up JIRA and put 'Derby JDK13CLEANUP' into the search box and get all the related issues quickly. Just as quick, I suppose, to have everything linked / subtasked off of one issue and bookmark that. andrew
[jira] Commented: (DERBY-2021) Ensure all tests called by jdbcapi._Suite run in embedded and client as required.
[ http://issues.apache.org/jira/browse/DERBY-2021?page=comments#action_12446654 ] Daniel John Debrunner commented on DERBY-2021: -- SURtest fixed by revision 470418 > Ensure all tests called by jdbcapi._Suite run in embedded and client as > required. > - > > Key: DERBY-2021 > URL: http://issues.apache.org/jira/browse/DERBY-2021 > Project: Derby > Issue Type: Test > Components: Test >Reporter: Daniel John Debrunner > > These tests have not been updated to run in client and embedded when run > stand alone > ConcurrencyTest.suite() > ProcedureTest.suite() > SURQueryMixTest.suite() > SURTest.suite() > UpdateXXXTest.suite() > ResultSetCloseTest.suite() > DataSourcePropertiesTest.suite() > If a test is not to run in client that fact should be documented with the > reason why. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - Daily 469983 - Sun DBTG
[Auto-generated mail] *Daily* 469983/2006-11-01 18:00:09 MET *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 2532530 099.87% lin NA NA NANA sol NA NA NANA solN+1 2532530 0 100.72% sparc 2532530 0 151.09% win Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-469983.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/469983.html *Jvm: 1.5* 0522522 299.59% lin 0522522 2 107.79% sol 0522522 2 120.45% solN+1 1522521 2 100.21% sparc 0522522 2 159.23% win Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-469983.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/469983.html *Jvm: 1.4* 0516516 499.68% lin 0516516 4 103.35% sol NA NA NANA solN+1 0516516 4 100.12% sparc 0516516 490.90% win Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-469983.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/469983.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/469983.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Created: (DERBY-2031) Convert derbynet/testProtocol.java to JUnit
Convert derbynet/testProtocol.java to JUnit --- Key: DERBY-2031 URL: http://issues.apache.org/jira/browse/DERBY-2031 Project: Derby Issue Type: Improvement Components: Network Server, Test Affects Versions: 10.3.0.0 Reporter: Knut Anders Hatlen Priority: Minor testProtocol.java executes DRDA commands from a file written in a special-purpose language. The statements are very much like assertions, so it should be fairly easy to convert the test to JUnit. Suggested approach: Change the interpreter (TestProto.java) so that is uses Assert.fail() instead of System.err.println() and System.exit(), and BaseTestCase.println() instead of System.out.println(). It should also use TestConfiguration to get the host name and port number. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1970) Add framework for performance tests in derby using Junit.
[ http://issues.apache.org/jira/browse/DERBY-1970?page=comments#action_12446645 ] Sunitha Kambhampati commented on DERBY-1970: The initial framework patches are all committed, but I think there is more room for improvement, specially in the area of reporting. I was hoping to keep this issue open to attach any further patches for this. > Add framework for performance tests in derby using Junit. > - > > Key: DERBY-1970 > URL: http://issues.apache.org/jira/browse/DERBY-1970 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Sunitha Kambhampati > Assigned To: Sunitha Kambhampati > Attachments: derby1970.draft.1.diff.txt, derby1970.p1.diff.txt, > derby1970.p2.diff.txt, derby1970.p2.stat.txt, Derby1970_Notes.html, > Derby1970_Notes.html > > > Add a framework for performance tests to be added in derby. > Some goals are : > -- use Junit, thus will serve double duty as both functional tests as well as > performance tests. > -- builds upon the existing infrastructure available to run functional tests >* for example, getting connections is handled in a single way allowing > the performance tests to run with J2ME, DriverManager, DataSource, single leg > of an XA transaction etc. > -- be able to run using Junit directly. > -- easy for developers to add these tests and run them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Tagging bugs - Re: [jira] Commented: (DERBY-2024) Remove JUnit utility method JDBC.vmSupportsJDBC2
Andrew McIntyre (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-2024?page=comments#action_12446453 ] Andrew McIntyre commented on DERBY-2024: [JDK13CLEANUP] I've been marking bugs with that tag in comments to make it easy to query JIRA for tasks related to removing JDK 1.3.1 support. I'll be glad to continue that habit if others find it useful. Is this any better than the existing mechanism where they are all a sub-task of DERBY-1982? It is an interesting approach though because I've been wondering how to tag a bug as being in a certain category without having to add new Jira fields. For example all bugs that cause incorrect data to be returned to the application. Now seeing your tagging I see it could be done that way or I could enter a Jira issue of type Task and just link relevant bugs to it. Dan.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (11 issues) Subscriber: derby-dev Key Summary DERBY-801 Allow parallel access to data files. http://issues.apache.org/jira/browse/DERBY-801 DERBY-2030 'set schema sys' followed by 'show tables' does not show tables in sys schema http://issues.apache.org/jira/browse/DERBY-2030 DERBY-2006 Add JUnit and JUnitReport task as a target in Ant script http://issues.apache.org/jira/browse/DERBY-2006 DERBY-1693 Out of Memory Error with derby.language.logStatementText=true http://issues.apache.org/jira/browse/DERBY-1693 DERBY-1808 [PATCH] Inbuilt functions SIGN, SQRT, RAND, RANDOM, COSH, SINH and TANH http://issues.apache.org/jira/browse/DERBY-1808 DERBY-1980 Web site - Documentation - Add a new page with writing guidelines http://issues.apache.org/jira/browse/DERBY-1980 DERBY-2009 Modify links to reflect that Sun DBTG test reports have moved to dbtg.thresher.com http://issues.apache.org/jira/browse/DERBY-2009 DERBY-1948 10.2 'Working with Derby' manual errors. http://issues.apache.org/jira/browse/DERBY-1948 DERBY-1938 Add support for setObject(, null) http://issues.apache.org/jira/browse/DERBY-1938 DERBY-963 Allow user friendly string values for security mechanism in client connection url. http://issues.apache.org/jira/browse/DERBY-963 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646
Re: Adding a new test
Knut Anders Hatlen wrote: Julius Stroffek <[EMAIL PROTECTED]> writes: Hi All, I would like to create a new test to check a DERBY-1434. As I read that the old harness framework is (or will be in a short time) deprecated I decided to write a junit test. The test should check some properties of DRDA communication protocol. However, the protocol tests were not switched to junit yet. Should I than write an old harness test for now? Thank you for an advice. Hi Julo, It is perfectly OK to add a new test case to the derbynet/testProtocol test. That test is actually an assertion based test which should be fairly easy to convert into JUnit later, and I don't think adding a new test case to it will slow down the transition to JUnit. Sounds good, though if you have time looking at converting the existing test to JUnit would be beneficial for the community. Then you would be coming up to speed on the standard way rather than the old testing mechanism. Dan.
Re: translation checker...
Myrna van Lunteren wrote: - investigate detecting the non-US-ASCII characters - maybe changing to ISO-8859-1 instead of UTF8 I don't understand why non-US-ASCII characters need to be detected. Since the defined format of properties file is ISO-8859-1 then non-US-ASCII characters are valid. Much clearer for everyone if we stick to the defined format rather than changing it. Dan.
Re: Adding a new test
Julius Stroffek <[EMAIL PROTECTED]> writes: > Hi All, > > I would like to create a new test to check a DERBY-1434. As I read > that the old harness framework is (or will be in a short time) > deprecated I decided to write a junit test. The test should check some > properties of DRDA communication protocol. However, the protocol tests > were not switched to junit yet. Should I than write an old harness > test for now? Thank you for an advice. Hi Julo, It is perfectly OK to add a new test case to the derbynet/testProtocol test. That test is actually an assertion based test which should be fairly easy to convert into JUnit later, and I don't think adding a new test case to it will slow down the transition to JUnit. -- Knut Anders
