Re: DERBY-2006, adding ant task to generate html report. (was Re: Test count dropping?)
Andrew McIntyre wrote: On 10/26/06, Sunitha Kambhampati [EMAIL PROTECTED] wrote: Thanks Andrew for working on this. I applied the patch attached to derby-2006 and after adding junit.jar to the $ANT_HOME/lib path, I can run the junitreport task. Do you have junit.jar in tools/java? I was hoping this wouldn't be necessary. After applying the patch I did not see any path element in the build.xml pointing to tools.java/junit.jar, could that be the reason. All the jars in $ANT_HOME/lib are accessible to the ant, hence placing the junit.jar always works. But I do think the new ant task should utilize the junit.jar from the tools/java rather than placing it in the $ANT_HOME/lib. -Rajesh
Re: Functions in GROUP BY expressions? (related to DERBY-883)
Army wrote (2006-10-26 15:25:49): [...] // Doesn't work but seems like it could/should based on above queries... ij select sin(i) from t1 group by sin(i); ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid expression. If a SELECT list has a GROUP BY, the list may only contain valid grouping expressions and valid aggregate expressions. [...] To me it seems natural that this one doesn't work. To group by double or float values is not reasonable. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: Digital signature
Sun DBTG test reports have moved to dbtg.thresher.com/derby/test/
DERBY-2009 created to modify links to reflect that Sun DBTG test reports have moved to dbtg.thresher.com/derby/test/ Patch available. -- Ole Solberg, Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: [VOTE] Kristian Waagan as a committer
+1 Saurabh Vyas Rick Hillegas wrote: Please vote on whether we should make Kristian Waagan a Derby committer. Kristian contributed significantly to the Derby JDBC4 effort. In my opinion 1) His patches show consistently superior quality: they are well thought out, well documented, and well tested. 2) He cheerfully takes advice. 3) He supplies the community sound counsel. 4) In addition, his commitment to and knowledge of assertion-based testing has helped lead the community, by example, toward a simpler, faster, more scalable testing model. Regards, -Rick
Re: DERBY-1434 - Client can send incorrect database name to server after having made multiple connections to different databases.
Hi Bryan,
I'm sorry for missing your comments in creation of a patch - I came
back to this issue after a couple of days after reading your comments.
Thank you for reminding.
So reading your comments again I think the best way how to implement a
test is to add a check to DRDAConnThread object and throw an exception
when the server receives a different RDBNAM in PKGNAMCSN codepoint than
the default values of a connection. The test program then could be
the program specified in JIRA - when the client sends different package
name, the exception will be thrown ("RDBNAM Mismatch") and query
won't be processed. It is sufficient to add this check only to
parsePKGNAMCSN function.
A small extract from DRDA DDM:
-
With SQLAM level 7, the PKGNAMCSN is changed to an optional instance
variable. If specied,
the values are used as the default package name and consistency token
for the connection. If not
specied on the command, the PKGSN is required to identify the section
number. In this case,
the default package name, consistency token, and specied section
number are used for the
request. If PKGNAMCSN was never specied on the connection, a PRCCNVRM
is returned.
According to this specification I think it is possible to change
the default database name on a connection,
thus theoretically there might exist a request that would require to
change a database name through
the PKGNAMCSN codepoint. Thus the question is: Will we add a check or
will we allow a change of
the database name on a connection? It makes no sense to allow a
database name change for jdbc api...
because AFAIK this stuff is not supported by the jdbc api.
However, I would not recommend allowing a change of the connection just
now because connecting
with an old implementation of jdbc client to a new implementation of
server will not work when creating
multiple connections to different databases.
So, I will add these things to the patch:
1.) A check of the database name in PKGNAMCSN codepoint.
2.) A test program doing something similar as the d1434.java attached
to jira.
Would it be alright then?
And
thanks for the detailed analysis of the problem, Julius; it has been
quite illuminating to read your notes.
Thanks... ;-); I liked going through it...
Cheers,
Julo
Re: DERBY-1953 test patch.
Bryan Pendleton wrote (2006-10-26 17:43:45): Good. I was planning on committing it soon since Knut Anders has reviewed it. Hi Bernt, With derby-1770-tests.diff applied to the current head of trunk, I get a failure in the upgrade_10_1_10_3 test. I think that maybe the mode db2sql is still required when running in the 10.1 portion of the upgrade test, or something like that? Bryan is right. Changed UpgradeTester.java to take that into consideration. New patch uploaded. (This comment added to JIRA issue and new patch uploaded) I'll add this comment to the JIRA issue too, just copying the list cuz the Jira email is still down. thanks, bryan -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway pgpyHMSMPfw47.pgp Description: PGP signature
Re: Functions in GROUP BY expressions? (related to DERBY-883)
Bernt M. Johnsen wrote: [...] // Doesn't work but seems like it could/should based on above queries... ij select sin(i) from t1 group by sin(i); ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid expression. If a SELECT list has a GROUP BY, the list may only contain valid grouping expressions and valid aggregate expressions. [...] To me it seems natural that this one doesn't work. To group by double or float values is not reasonable. Thank you for the reply, Bernt. Perhaps this is the detail I was missing. When you say is not reasonable, can you elaborate on why that's the case (excuse me if that's a naive question)? Is it because the types are imprecise? I did notice that following works: ij create table td (d double); 0 rows inserted/updated/deleted ij insert into td values 2.08, 3.08; 2 rows inserted/updated/deleted ij select d from td group by d; D -- 2.08 3.08 If it is not reasonable to group by a double, then should this query work? Or should we be throwing the same error that we throw for sin(i)? Army
Re: [jira] Updated: (DERBY-1758) Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars.
Bryan Pendleton wrote: Hi Army, I put a few notes into the Jira issue, but basically I didn't encounter any problems with your second patch. Thank you for reviewing the patch, Bryan, and for the comments. I noticed that you wrote basically here and that you said in general in your comments for the Jira. Is there anything in particular about the patch that is prompting these qualifiers? Feel free to let me know if there's something you'd like to see changed--I'm open to making the patch better where possible. Is this patch ready for commit? If so, I'll go ahead and commit it. I haven't heard anything from anyone else about the patch, and so far as I know no one else is reviewing it. So yes, I think this patch is ready for commit (thanks for offering!). Note that if you do have some suggestions about how to make the patch better, we could still commit the current (_v2) patch and then I can post a follow-up to address your suggestions (similar to what was done for DERBY-1976). Thanks, as always, for being so willing to review and commit. I appreciate it! Army
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (17 issues) Subscriber: derby-dev Key Summary DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional http://issues.apache.org/jira/browse/DERBY-1953 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-2008 NullPointerException with 2-argument SUBSTR() call in GROUP BY clause. http://issues.apache.org/jira/browse/DERBY-2008 DERBY-1434 Client can send incorrect database name to server after having made multiple connections to different databases. http://issues.apache.org/jira/browse/DERBY-1434 DERBY-1970 Add framework for performance tests in derby using Junit. http://issues.apache.org/jira/browse/DERBY-1970 DERBY-1808 [PATCH] Inbuilt functions SIGN, SQRT, RAND, RANDOM, COSH, SINH and TANH http://issues.apache.org/jira/browse/DERBY-1808 DERBY-1758 Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars. http://issues.apache.org/jira/browse/DERBY-1758 DERBY-1979 convert jdbcapi/characterStreams.java to Junit http://issues.apache.org/jira/browse/DERBY-1979 DERBY-1693 Out of Memory Error with derby.language.logStatementText=true http://issues.apache.org/jira/browse/DERBY-1693 DERBY-1991 Misleading stack traces for exceptions raised by the JDBC 4.0 embedded driver http://issues.apache.org/jira/browse/DERBY-1991 DERBY-1948 10.2 'Working with Derby' manual errors. http://issues.apache.org/jira/browse/DERBY-1948 DERBY-1490 Provide ALTER TABLE RENAME COLUMN functionality http://issues.apache.org/jira/browse/DERBY-1490 DERBY-1969 Tools Guide: Spelling errors in doc for ij show command http://issues.apache.org/jira/browse/DERBY-1969 DERBY-1938 Add support for setObject(arg, null) http://issues.apache.org/jira/browse/DERBY-1938 DERBY-1930 Move JDBC implementation notes into the published javadoc http://issues.apache.org/jira/browse/DERBY-1930 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: Functions in GROUP BY expressions? (related to DERBY-883)
Army wrote: Bernt M. Johnsen wrote: [...] // Doesn't work but seems like it could/should based on above queries... ij select sin(i) from t1 group by sin(i); ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid expression. If a SELECT list has a GROUP BY, the list may only contain valid grouping expressions and valid aggregate expressions. [...] To me it seems natural that this one doesn't work. To group by double or float values is not reasonable. Thank you for the reply, Bernt. Perhaps this is the detail I was missing. When you say is not reasonable, can you elaborate on why that's the case (excuse me if that's a naive question)? Is it because the types are imprecise? I did notice that following works: ij create table td (d double); 0 rows inserted/updated/deleted ij insert into td values 2.08, 3.08; 2 rows inserted/updated/deleted ij select d from td group by d; D -- 2.08 3.08 If it is not reasonable to group by a double, then should this query work? Or should we be throwing the same error that we throw for sin(i)? No, you are correct Army, the grouping by functions does not work because at the moment Derby assumes all functions are non-deterministic. Grouping by DOUBLE should be allowed since they can be compared. It's probably not advisable, but Derby's SQL should allow it. Dan.
Re: [jira] Updated: (DERBY-1758) Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars.
noticed that you wrote basically here and that you said in general in your comments for the Jira. Is there anything in particular about the patch that is prompting these qualifiers? No, there isn't. I'm not sure why I was weaseling; I think I was just tired. :) I intend to commit the v2 patch this weekend. thanks, bryan
Regression Test Report - Daily 468048 - Sun DBTG
[Auto-generated mail] *Daily* 468048/2006-10-26 18:00:09 MEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 0672672 0 101.44% lin 0672672 0 105.87% sol 0672672 092.11% solN+1 0672672 0 102.72% sparc 1672671 0 152.30% win Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-468048.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/468048.html *Jvm: 1.5* 0661661 2 101.22% lin 0661661 2 109.28% sol 1661660 293.92% solN+1 1661660 2 102.33% sparc 1661660 2 161.98% win Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-468048.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/468048.html *Jvm: 1.4* 0655655 4 100.87% lin 0655655 4 105.25% sol 0655655 493.44% solN+1 0655655 4 102.25% sparc 1655654 492.28% win Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-468048.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/468048.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/468048.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Re: DERBY-1953 test patch.
Bryan is right. Changed UpgradeTester.java to take that into consideration. New patch uploaded. Thanks Bernt! With your latest patch, the Upgrade test passes for me. +1 to commit. 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_12445235 ] Henri Yandell commented on DERBY-2006: -- testing JIRA email. 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 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: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
I have inserted a table into one of the xml documents but now I am getting some errors when I try forrest site that indicate that some attributed (ALIGN and VALGN) are not declared. Is there a list of declared attributes that I can see, so that I know what is valid? Can the list be added to? -- Laura Stewart
[jira] Updated: (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 updated DERBY-2006: --- Derby Info: [Patch Available] 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 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 mail working again
Thanks to Henri Yandell and Noel Bergman, we once again have JIRA mail flowing again. Also, now that our From: address for JIRA mails is [EMAIL PROTECTED], if you respond to the personal mail that comes to you from JIRA, your reply should be added to the JIRA issue as a comment. At least that's supposed to work. Somebody should give that a try at some point. That's all for now, and thanks again to Noel and Hen... andrew
[jira] Commented: (DERBY-1490) Provide ALTER TABLE RENAME COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1490?page=comments#action_12445250 ] Bryan Pendleton commented on DERBY-1490: Does anyone anticipate having time to review this patch proposal? Provide ALTER TABLE RENAME COLUMN functionality --- Key: DERBY-1490 URL: http://issues.apache.org/jira/browse/DERBY-1490 Project: Derby Issue Type: New Feature Components: Documentation, SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.1.2.1, 10.1.3.1 Reporter: Bryan Pendleton Assigned To: Bryan Pendleton Attachments: derby1490_v1_needMoreTests.diff, renameColumn_v2_with_tests.diff Provide a way to rename a column in an existing table. Possible syntax could be: ALTER TABLE tablename RENAME COLUMN oldcolumn TO newcolumn; Feature should properly handle the possibility that the column is currently used in constraints, views, indexes, triggers, etc. -- 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-2011) DROP INDEX, TRIGGER and VIEW contain examples in the syntax section in the reference manual.
DROP INDEX, TRIGGER and VIEW contain examples in the syntax section in the reference manual. Key: DERBY-2011 URL: http://issues.apache.org/jira/browse/DERBY-2011 Project: Derby Issue Type: Bug Components: Documentation Reporter: Daniel John Debrunner Priority: Minor These examples are out of place in the synxtax section and as examples they are pretty poor, they look like syntax given the names, at least for the index and view ones. DROP INDEX has these lines in the syntax section DROP INDEX OrigIndex DROP INDEX DestIndex DROP TRIGGER has this DROP TRIGGER TRIG1 DROP VIEW has this DROP VIEW AnIdentifier -- 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-1758) Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars.
[ http://issues.apache.org/jira/browse/DERBY-1758?page=all ] Bryan Pendleton updated DERBY-1758: --- Derby Info: (was: [Patch Available]) Patch d1758_newJUnitTests_v2.patch committed to subversion as revision 468503. Cleared patch available flag. Army, there were two or three other submissions to JDBC.java after you attached your patch and before I committed. The merging seemed clean, but can you please check the results carefully and make sure that JDBC.java looks OK? Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars. -- Key: DERBY-1758 URL: http://issues.apache.org/jira/browse/DERBY-1758 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.2.1.6, 10.3.0.0, 10.2.2.0 Reporter: A B Attachments: d1758_newJUnitTests_v1.patch, d1758_newJUnitTests_v1.stat, d1758_newJUnitTests_v2.patch Due to the fact the XML support in Derby has external dependencies on Apache Xalan and a JAXP parser (such as, but not limited to, Apache Xerces), the tests for XML, which are all included in xmlSuite, are not currently run as part of derbyall. Changes for DERBY-688 (and DERBY-567 indirectly) have now made it so that JVMs which have Apache Xalan and a JAXP parser embedded in them can run the XML tests without requiring additional jars, assuming that the embedded version of Xalan is at least the minimum version required by Derby (which is currently 2.5). So given that, the xmlSuite should be enabled as part of derbyall for any JVMs that are capable of running them. Currently, this appears to mean only ibm142 and ibm15. Per comments in DERBY-688, enabling the XML suite could include the following tasks: 1. Enable the suite to run as part of derbyall but ONLY for JVMs that embed the required Xalan/JAXP classes. 2. Resolve the following diff in lang/xmlBinding.java that occurs on some platforms (ex. Linux): Inserted roughly 40k of data. 10 del Inserted roughly 40k of data. 10a9,10 Inserted roughly 39k of data. Inserted roughly 37k of data. 21 del 1, [ roughly 40k ] 22 del 2, [ roughly 40k ] 22a21,22 1, [ roughly 39k ] 2, [ roughly 37k ] 3. Add new tests to verify Derby behavior when XML classes are not present. Note that #3 may turn out to be its own Jira issue; the first two, however, should both be addressed as part of this issue since the xmlSuite will not run (and pass) on all platforms if either 1 or 2 is not addressed. -- 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-2008) NullPointerException with 2-argument SUBSTR() call in GROUP BY clause.
[
http://issues.apache.org/jira/browse/DERBY-2008?page=comments#action_12445255 ]
Yip Ng commented on DERBY-2008:
---
Patch available for review. [Testing jira email]
NullPointerException with 2-argument SUBSTR() call in GROUP BY clause.
--
Key: DERBY-2008
URL: http://issues.apache.org/jira/browse/DERBY-2008
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.2.1.6, 10.3.0.0
Reporter: A B
Assigned To: Yip Ng
Priority: Minor
Attachments: derby2008-trunk-diff01.txt, derby2008-trunk-stat01.txt
The following query, which fails with a syntax error in 10.1.3 (because
functions are not allowed in a GROUP BY expression for 10.1) fails with a
NullPointerException in 10.2 and in the codeline (10.3):
create table dt (vc varchar(30));
insert into dt values ('1928-09-21'), ('1903-12-08');
select substr(vc, 3) from dt group by substr(vc, 3);
Result (on trunk) is:
java.lang.NullPointerException
at
org.apache.derby.impl.sql.compile.TernaryOperatorNode.isEquivalent(TernaryOperatorNode.java:924)
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.TernaryOperatorNode.accept(TernaryOperatorNode.java:497)
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)
--
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-2011) DROP INDEX, TRIGGER and VIEW contain examples in the syntax section in the reference manual.
[ http://issues.apache.org/jira/browse/DERBY-2011?page=comments#action_12445259 ] Laura Stewart commented on DERBY-2011: -- The filenames for these topics are: DROP INDEX = rrefsqlj59893.html DROP TRIGGER = rrefsqlj42082.html DROP VIEW = rrefsqlj61102.html It would be good to add a section with the title Examples and use the examples from the CREATE statements for examples, unless someone has examples that they want to provide. DROP INDEX, TRIGGER and VIEW contain examples in the syntax section in the reference manual. Key: DERBY-2011 URL: http://issues.apache.org/jira/browse/DERBY-2011 Project: Derby Issue Type: Bug Components: Documentation Reporter: Daniel John Debrunner Priority: Minor These examples are out of place in the synxtax section and as examples they are pretty poor, they look like syntax given the names, at least for the index and view ones. DROP INDEX has these lines in the syntax section DROP INDEX OrigIndex DROP INDEX DestIndex DROP TRIGGER has this DROP TRIGGER TRIG1 DROP VIEW has this DROP VIEW AnIdentifier -- 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: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Also, is there a way to force a line break inside of a table in XML tagging? I tried using br/br but forrest site is returning errors... -- Laura Stewart
[jira] Commented: (DERBY-2007) Convert NIST suite to JUnit using the existing NistScripts JUnit test.
[ http://issues.apache.org/jira/browse/DERBY-2007?page=comments#action_12445263 ] Daniel John Debrunner commented on DERBY-2007: -- Committed revision 468514 switches the NIST suite over to JUnit, though more cleanup is required. Convert NIST suite to JUnit using the existing NistScripts JUnit test. -- Key: DERBY-2007 URL: http://issues.apache.org/jira/browse/DERBY-2007 Project: Derby Issue Type: Test Components: Test Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Fix For: 10.3.0.0 Need to work through the current failures when running NistScripts, which are due to blank lines and generated constraint names in the output. -- 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: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Laura Stewart wrote: I have inserted a table into one of the xml documents but now I am getting some errors when I try forrest site that indicate that some attributed (ALIGN and VALGN) are not declared. Is there a list of declared attributes that I can see, so that I know what is valid? Can the list be added to? Here are the docs for the forrest dtd (and howto's and faq's are on the left hand nav of this page): http://forrest.apache.org/dtdx/document-v20.dtdx.html 'td' doesn't include align and valign: http://forrest.apache.org/dtdx/document-v20.dtdx.html#td It might help to check the faqs at the forrest site -- perhaps the issue of adding to the dtd has come up before. -jean
Re: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Laura Stewart wrote: Also, is there a way to force a line break inside of a table in XML tagging? I tried using br/br but forrest site is returning errors... h http://forrest.apache.org/dtdx/document-v20.dtdx.html#td shows that br is allowed in a td. Is that where you were inserting the line break? Perhaps if you could post just the snippet that uses it here (with enough table context), other eyes can spot what forrest wants. -jean
[jira] Updated: (DERBY-1758) Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars.
[ http://issues.apache.org/jira/browse/DERBY-1758?page=all ] A B updated DERBY-1758: --- Attachment: d1758_followup_v1.patch Thank you for the commit, Bryan! I'm attaching another patch, d1758_followup_v1.patch, that moves the XML utility methods out of junit.JDBC and into a new class, junit.XML, per Dan's suggestion (thanks Dan). Note that I changed the haveClass() method in JDBC.java from private to protected so that it can be called from the junit.XML class. That was the easiest thing to do. Since checking the classpath is not a JDBC-specific operation, the other option is to move haveClass() to some other class in the junit package. If anyone indicates a preference for doing so and also indicates the class to which the method should be moved, I can do it this way. Otherwise I'll just leave it as it is (i.e. keep it in JDBC.java and make it protected). I ran suites.All with this patch applied using jdk142 with endorsed Xalan 2.5 jars and there was one error--an OOM error with testLongLobLength(). That was probably because I was running the suite in the background while running other apps. In any event, I don't think that's related to this change. As always, review comments and/or commit are appreciated. Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars. -- Key: DERBY-1758 URL: http://issues.apache.org/jira/browse/DERBY-1758 Project: Derby Issue Type: Task Components: Test Affects Versions: 10.2.1.6, 10.3.0.0, 10.2.2.0 Reporter: A B Attachments: d1758_followup_v1.patch, d1758_newJUnitTests_v1.patch, d1758_newJUnitTests_v1.stat, d1758_newJUnitTests_v2.patch Due to the fact the XML support in Derby has external dependencies on Apache Xalan and a JAXP parser (such as, but not limited to, Apache Xerces), the tests for XML, which are all included in xmlSuite, are not currently run as part of derbyall. Changes for DERBY-688 (and DERBY-567 indirectly) have now made it so that JVMs which have Apache Xalan and a JAXP parser embedded in them can run the XML tests without requiring additional jars, assuming that the embedded version of Xalan is at least the minimum version required by Derby (which is currently 2.5). So given that, the xmlSuite should be enabled as part of derbyall for any JVMs that are capable of running them. Currently, this appears to mean only ibm142 and ibm15. Per comments in DERBY-688, enabling the XML suite could include the following tasks: 1. Enable the suite to run as part of derbyall but ONLY for JVMs that embed the required Xalan/JAXP classes. 2. Resolve the following diff in lang/xmlBinding.java that occurs on some platforms (ex. Linux): Inserted roughly 40k of data. 10 del Inserted roughly 40k of data. 10a9,10 Inserted roughly 39k of data. Inserted roughly 37k of data. 21 del 1, [ roughly 40k ] 22 del 2, [ roughly 40k ] 22a21,22 1, [ roughly 39k ] 2, [ roughly 37k ] 3. Add new tests to verify Derby behavior when XML classes are not present. Note that #3 may turn out to be its own Jira issue; the first two, however, should both be addressed as part of this issue since the xmlSuite will not run (and pass) on all platforms if either 1 or 2 is not addressed. -- 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: Issues with Forrest/Derby Web site (Was: Re: Proposal - Doc Process Improvements)
Well, I finally got what I want to work. This will teach me to copy/paste from HTML (argh). I have an XML editor that I am using which checks to ensure that it is a well formed XML document and that there are no tagging errors. I'll be posting the updates to Jira issue 1980. Since I am adding a new page, do you think that it would be good to have svn stat? -- Laura Stewart
build problems with publishedapi javadoc target
I'm seeing build errors trying to build the javadoc target, publishedapi. I'm using ant 1.6.2. Any ideas? BUILD FAILED C:\_work\svn_linq\trunk\build.xml:597: The following error occurred while executing this line: C:\_work\svn_linq\trunk\build.xml:608: The following error occurred while executing this line: C:\_work\svn_linq\trunk\build.xml:674: The javadoc type doesn't support the executable attribute. Dan.
[jira] Commented: (DERBY-1930) Move JDBC implementation notes into the published javadoc
[ http://issues.apache.org/jira/browse/DERBY-1930?page=comments#action_12445280 ] Daniel John Debrunner commented on DERBY-1930: -- Applied patch and then made corrections indicated by Dag. Move JDBC implementation notes into the published javadoc - Key: DERBY-1930 URL: http://issues.apache.org/jira/browse/DERBY-1930 Project: Derby Issue Type: Improvement Components: Documentation, JDBC Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor Fix For: 10.3.0.0 Attachments: derby1930_diff.txt, package-summary.html, package-summary.html The information in Derby's JDBC implementation notes needs to be in the documentation. http://db.apache.org/derby/papers/JDBCImplementation.html At least one approach is to add it to the published Javadoc in the package.html for org.apache.derby.jdbc. This will make it easier for people to update and ensures that users of Derby have the information with a release. -- 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-1930) Move JDBC implementation notes into the published javadoc
[ http://issues.apache.org/jira/browse/DERBY-1930?page=all ] Daniel John Debrunner closed DERBY-1930. Resolution: Fixed Move JDBC implementation notes into the published javadoc - Key: DERBY-1930 URL: http://issues.apache.org/jira/browse/DERBY-1930 Project: Derby Issue Type: Improvement Components: Documentation, JDBC Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Priority: Minor Fix For: 10.3.0.0 Attachments: derby1930_diff.txt, package-summary.html, package-summary.html The information in Derby's JDBC implementation notes needs to be in the documentation. http://db.apache.org/derby/papers/JDBCImplementation.html At least one approach is to add it to the published Javadoc in the package.html for org.apache.derby.jdbc. This will make it easier for people to update and ensures that users of Derby have the information with a release. -- 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-1490) Provide ALTER TABLE RENAME COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1490?page=comments#action_12445290 ] A B commented on DERBY-1490: I reviewed the patch and functionally it looks good to me. I ran the new test cases in altertable.sql and they all passed. Just some minor things that jumped out at me while I was reviewing: - Two comments on the patch itself: 1. Test cases say FIXME for some of the trigger tests. This appears to be correlated with your comment #4 above, except that the Jira comment says that this behavior is pretty reasonable while the test itself suggests that there is something here to be fixed. Are we just waiting for community feedback in order to determine which conclusion (reasonable vs FIXME) is the most appropriate? 2. sqlgrammar.jj has the following diff: +if (oldColumnReference.getTableNameNode() == null) +throw StandardException.newException( +SQLState.LANG_OBJECT_DOES_NOT_EXIST, +RENAME COLUMN, (Missing Table)); From a user perspective this shows up as something like: ERROR 42Y55: 'RENAME COLUMN' cannot be performed on '(Missing Table)' because it does not exist. The string literal (Missing Table) is hardcoded into the error message because it is passed as an error argument. This means that someone who is using Derby in a different locale will see the phrase (Missing Table) in English; it will not be translated. I don't know what the Derby practice regarding message translation is, but my understanding is that it's generally best to restrict hard-coded error tokens to actual SQL syntax words, since syntax words are constant across locales. Thus it's fine to use RENAME COLUMN because that's an explicit part of the syntax and it does not change from locale to locale. But Missing Table is a locale-specific phrase and so it's best to avoid passing it as an error message argument. If needed, I think a new error message would be a cleaner way to go. Of course, after writing that I did a quick look in sqlgrammar.jj and I noticed two places where the English word MISSING is hard-coded as an error argument. So I guess it has been done before...but it still seems like something to avoid as a general rule. As an alternative, I wonder if you couldn't just pass the column name as an argument in this case? Ex. ij rename column renc_1 to b; ERROR 42Y55: 'RENAME COLUMN' cannot be performed on 'RENC_1' because it does not exist. The plus side to this is that the message is locale-independent and there is a clear indication of what part of the command is causing the error. The downside is that this error message does not really express what we want it to express--namely, that the syntax is missing a table name. So again, perhaps the best bet is to create a new error message that explicitly tells what the problem is...? -- In response to the questions you asked in your comment above: #1) Umm...don't know which is better. I think I'll plea undecided on this one :) #2) I think you've done a great job of covering the various test cases. Thanks for being so thorough! The only test case that I didn't see was one for trying to rename a column to itself, but when I tried that it threw the expected error (i.e. column already exists). I also tried renaming the column on a synonym, which failed as expected, and I verified that renaming a column in a table renames it (functionally) in the synonym, as well. So the tests look good to me. As for #3 and #4, I personally do not have any problems with the behavior as you describe. I do wonder, though, why it is that we allow renaming to occur when it breaks a trigger but do not allow it when it would break a view or a check constraint. Is this just because, as the altertable.sql test says, the trigger dependency information is not correctly updated? If that's the case, then is there a Jira issue for fixing that particular problem? Other minor nits that shouldn't block the patch: - There appears to be a mix of spaces and tabs in the new code, which makes the file a bit harder to read. In some cases the difference is between existing code and new code, which is probably okay. But there are also some places where the new code itself mixes spaces with tabs... - One line over 80 chars in sqlgrammar.jj... As I said, nothing major to report here--certainly not anything I would call a blocker for the patch. Functionally the patch looks solid to me. Thanks for taking the time to work on this feature! Provide ALTER TABLE RENAME COLUMN functionality --- Key: DERBY-1490 URL: http://issues.apache.org/jira/browse/DERBY-1490 Project: Derby Issue Type: New Feature
[jira] Updated: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Component/s: Documentation
Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: Documentation, SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
Attachments: derby-1770-tests-v2.diff, derby-1770-tests-v2.stat,
derby-1770-tests.diff, derby-1770-tests.stat, derby1953-trunk-diff01.txt,
derby1953-trunk-diff02.txt, derby1953-trunk-diff03.txt,
derby1953-trunk-diff04.txt, derby1953-trunk-stat01.txt,
derby1953-trunk-stat02.txt, derby1953-trunk-stat03.txt,
derby1953-trunk-stat04.txt
According to SQL:2003 standard, section 11.39 trigger definition, under
Syntax Rules item 8:
If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
STATEMENT is implicit.
[ FOR EACH { ROW | 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] Assigned: (DERBY-1868) Merge argument descriptors into SQLState strings so that SQLState documentation can be generated by a program
[ http://issues.apache.org/jira/browse/DERBY-1868?page=all ]
Rick Hillegas reassigned DERBY-1868:
Assignee: Rick Hillegas
Merge argument descriptors into SQLState strings so that SQLState
documentation can be generated by a program
-
Key: DERBY-1868
URL: http://issues.apache.org/jira/browse/DERBY-1868
Project: Derby
Issue Type: Improvement
Components: Build tools
Affects Versions: 10.2.1.6
Reporter: Rick Hillegas
Assigned To: Rick Hillegas
Fix For: 10.2.2.0
Attachments: derby-1868-lineEndings-v01.diff
See DERBY-1566. That JIRA introduced a program, written by David, which
generates human-readable tables of message strings for inclusion in the
Reference Guide. The tool doesn't patch in friendly arguments. That leaves
the message strings peppered with unfriendly placeholders like {0}. {1},
etc.. Laura painstakingly editted the tables, by hand substituting in
friendlier arguments like userName and tableName.
We need to move Laura's substitutions into the source code so that David's
program can automatically plug them in. This will save us a lot of grief when
we generate future releases. Dan and Andrew have proposed approaches to this
problem. Those approaches are discussed in DERBY-1566. Here is Andrew's
comment on Dan's proposal:
While Dan's suggestion here:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200608.mbox/[EMAIL
PROTECTED]
to generate the message file and doc from a single XML file would be ideal, a
simpler approach to implement would be to maintain the meanings of the
markers in another properties file, identified by message key and marker
number. So, e.g. the new properties file would contain:
01500.0=constraintName
01500.1=tableName
Then ErrorMessageGenerator could look up the value of the markers by SQLState
and MessageFormat marker number in the properties file, although this
approach would require maintaining two files instead of one.
I glossed this further: If we adopt Andrew's approach, I would recommend
co-locating the argument descriptiors in the same properties file which
contains the messages. This will help keep the argument descriptors from
drifting out of sync with the messages themselves--that is a substantial
advantage of Dan's approach.
--
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: build problems with publishedapi javadoc target
On 10/27/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: I'm seeing build errors trying to build the javadoc target, publishedapi. I'm using ant 1.6.2. Any ideas? The executable attribute for the javadoc task was added in Ant 1.6.3. We need to use the executable attribute to specify the JDK 1.6 executable when building the JDBC 4 javadoc. BUILDING.txt does specify to use Ant 1.6.3 or higher. andrew
[jira] Created: (DERBY-2012) The Syntax of the UPDATE and DELETE statements is not correct in the reference manual
The Syntax of the UPDATE and DELETE statements is not correct in the reference manual - Key: DERBY-2012 URL: http://issues.apache.org/jira/browse/DERBY-2012 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Christian d'Heureuse Priority: Minor The syntax description of the UPDATE and DELETE statements in the reference manual does not imply that an alias name may be specified for the table name. The statements are currently documented as: UPDATE table-Name SET ... DELETE FROM table-Name [ WHERE ... ] This should be changed to: UPDATE table-Name [ [ AS ] correlation-Name ] SET ... DELETE FROM table-Name [ [ AS ] correlation-Name ] [ WHERE ... ] (Table alias names for UPDATE and DELETE are important for the WHERE clauses, e.g. when the same table is used a second time within a subquery in the WHERE condition, e.g.: UPDATE table1 a SET ... WHERE EXISTS ( SELECT * FROM table1 b WHERE a.field1 = b.field2 ) -- 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-495) COALESCE
[ http://issues.apache.org/jira/browse/DERBY-495?page=comments#action_12445317 ] Christian d'Heureuse commented on DERBY-495: COALESCE is an important function and should be documented. In ISO/IEC 9075, the syntax for COALESCE is COALESCE ( expression [,expression] ) but Derby currently does not allow COALESCE with a single argument. As long as this is not fixed, the syntax documentation should be COALESCE ( expression, expression [,expression] ) In ISO 9075-2, COALESCE is defined as: COALESCE (V1, V2) is equivalent to the following case specification: CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END COALESCE (V1, V2, ..., Vn), for n ≥ 3, is equivalent to the following case specification: CASE WHEN V1 IS NOT NULL THEN V1 ELSE COALESCE (V2, ..., Vn) END This could be used for the documentation. I wouldn't document that VALUE is another name for the COALESCE function in Derby, because thats an inheritance from DB2 and not part of the SQL standard. COALESCE Key: DERBY-495 URL: http://issues.apache.org/jira/browse/DERBY-495 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.0.2.0 Environment: n/a Reporter: Paul Jenkins Priority: Minor The COALESCE function has been implemeted since 10.0.2.0 (at least) but isn't documented. -- 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
