Re: [VOTE] Army Brown as a committer
+1Andreas
[jira] Commented: (DERBY-803) derbynet/DerbyNetAutoStart.java test fails intermittently with org.apache.derby.iapi.services.context.ShutdownException
[ http://issues.apache.org/jira/browse/DERBY-803?page=comments#action_12441356 ] Andrew McIntyre commented on DERBY-803: --- Since this was a minor change to the test that fixed the problem, and this test is a bit of an annoyance for 10.1 testing, I merged Fernanda's test change to 10.1 with revision 462705. > derbynet/DerbyNetAutoStart.java test fails intermittently with > org.apache.derby.iapi.services.context.ShutdownException > --- > > Key: DERBY-803 > URL: http://issues.apache.org/jira/browse/DERBY-803 > Project: Derby > Issue Type: Test > Components: Network Server, Regression Test Failure >Affects Versions: 10.2.1.6, 10.3.0.0, 10.1.3.2 >Reporter: Kathey Marsden > Assigned To: Fernanda Pizzorno > Fix For: 10.2.1.6 > > Attachments: derby-803.diff, derby-803.stat, suggestion-803.diff, > suggestion-803.stat > > > DerbyNetAutoStart fails intermittently with the following diff: > This issue is likely related to DERBY-1020 > * Diff file > derbyall/derbynetmats/DerbyNet/derbynetmats/DerbyNetAutoStart.diff > *** Start: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats > 2006-01-05 23:39:40 *** > 1a2,3 > > org.apache.derby.iapi.services.context.ShutdownException: > > at org.apache.derby.impl.drda.Session.close(Unknown > > Source)agentThread[DRDAConnThread_3,5,derby.daemons] > Test Failed. > *** End: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats > 2006-01-05 23:41:10 *** -- 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: [testing]-How can i run tests from source rather than jar files
Thanks, it works :)2006/10/10, John Embretsen <[EMAIL PROTECTED]>: Sean Qiu wrote:> Hello everybody.>>> I want to run the test from source .java files rather than from .jar> So i can modify the code and get the result at once without build the> project. > What should i do for the purpose?Well, you will have to do _some_ building in order to test your changes,but you can avoid building the jar files every time you want to test alocal change by: * removing the derby*.jar (derby.jar, derbyclient.jar, etc.) files fromthe classpath.* adding the trunk/classes directory to the classpath instead.However, the required jars that are not part of Derby itself ( e.g.junit.jar, jakarta-oro-2.0.8.jar) must still be in the classpath.(See trunk/java/testing/readme.htm and trunk/BUILDING.txt for details).After making your changes to the source code, you can build the classes by running "ant all". Sometimes it is necessary to run "ant clobber" aswell, prior to running "ant all", to remove old leftovers.If you are only making test changes, "ant testing" is often sufficient, provided that you have run "ant all" at least once before.There may be subtle differences between running tests with the classfiles directly and running with the jars, so I personally recommend running tests with the jar files before submitting a patch or using thecode in production.--John
Re: [testing]Test fails
This time i remove all the derby*.jar out of the CLASSPATH and add the trunk/classes into it.The lang/supersimple.sql test is passed and the test suite derbylang is also successs.I will try the derbyall right now. But i still have no idea why i failed previously.Maybe the version difference caused the problem.And thanks all of you anyway. 2006/10/11, Bryan Pendleton < [EMAIL PROTECTED]>: Sean Qiu wrote:> Any suggestions> to address issues through the infomation provided by the output files?I'm actually not sure what's going on with your test. It looks like thesupersimple.out and supersimple.tmp files that you attached are in factidentical; the only exception is that your supersimple.tmp file containsan extra line at the beginning saying ij version 10.2which is I think fine, and should not cause the diff that you saw. So I'm afraid I don't know what is causing the test harness to reportthe diff that you are seeing.bryan
Re: [testing]Test fails
It is something about encode On 10/11/06, Leo Li <[EMAIL PROTECTED]> wrote: On 10/10/06, Bryan Pendleton < [EMAIL PROTECTED]> wrote: > We have just run the testcase for derby but it fails on windows.Can you tell (by inspection of the output and diff files on your machine) whether you are getting the same values in the output, but in a different order?If so, it sounds like the sort ordering is different on your machine thanis expected by the test.Is your Windows environment a simple English-language configuration? Or are you using a different locale or some other sort-related configuration? The platform is winXP with simple chinese language, I think it might be related to this issue because of the sorting order? thanks,bryan -- Leo LiChina Software Development Lab, IBM
[jira] Closed: (DERBY-1899) 10.2.1.5 source distribution is missing many files and includes some files that it should not.
[ http://issues.apache.org/jira/browse/DERBY-1899?page=all ] Andrew McIntyre closed DERBY-1899. -- > 10.2.1.5 source distribution is missing many files and includes some files > that it should not. > -- > > Key: DERBY-1899 > URL: http://issues.apache.org/jira/browse/DERBY-1899 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.2.1.6 >Reporter: Andrew McIntyre > Assigned To: Rick Hillegas > Fix For: 10.2.1.6 > > Attachments: derby-1899-v01.diff > > > The source distribution is missing the top-level bin and maven directories, > as well as BUILDING.txt, README, index.html, and published-api-overview.html. > Also, the tools directory is missing release/build.xml. > In addition, tools/testing/derby contains a complete set of the Derby 10.1 > jars, these should be removed from the -src distribution. -- 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-1846) Create a script that allows users to easily update their Derby jars with the JDBC4 classes.
[ http://issues.apache.org/jira/browse/DERBY-1846?page=all ] Andrew McIntyre closed DERBY-1846. -- > Create a script that allows users to easily update their Derby jars with the > JDBC4 classes. > --- > > Key: DERBY-1846 > URL: http://issues.apache.org/jira/browse/DERBY-1846 > Project: Derby > Issue Type: Improvement > Components: Demos/Scripts >Affects Versions: 10.2.1.6 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre > Fix For: 10.2.1.6 > > Attachments: derby-1846-netconnection.diff, derby-1846-v1.diff, > derby-1846-v2.diff, derby1846-batchFix_v1.diff, modules.properties, > output_batchFix_v1.txt > > > Since the resolution of the JDBC 4 licensing issue was to not ship a build > that includes Derby's JDBC 4 code, but continue to ship the Derby source > files for them, a script which automatically compiles and updates the Derby > jars with the JDBC 4 classes would be useful. -- 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-1805) Links to element ids inside a topic are broken in PDFs and HTML Books
[ http://issues.apache.org/jira/browse/DERBY-1805?page=all ] Andrew McIntyre closed DERBY-1805. -- > Links to element ids inside a topic are broken in PDFs and HTML Books > - > > Key: DERBY-1805 > URL: http://issues.apache.org/jira/browse/DERBY-1805 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6, 10.3.0.0 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: ditalinks-fix.diff > > > Links which point to ids of elements inside other topics and referenced using > the syntax are broken. One example > of this is the javax.sql.DataSource link contained in the text for the JNDI > support bullet found here: > http://db.apache.org/derby/docs/dev/ref/ref-single.html#N35B48 -- 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-1223) Update Getting Started to include instructions on setting JAVA_HOME variable.
[ http://issues.apache.org/jira/browse/DERBY-1223?page=all ] Andrew McIntyre closed DERBY-1223. -- > Update Getting Started to include instructions on setting JAVA_HOME variable. > - > > Key: DERBY-1223 > URL: http://issues.apache.org/jira/browse/DERBY-1223 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Andrew McIntyre > Assigned To: Laura Stewart >Priority: Minor > Fix For: 10.2.1.6 > > Attachments: derby1223.diff, derby1223_2.diff, derby1223_3.diff, > derby1223_4.diff, derby1223_5.diff, Derby1223_html.zip, derby1223_html2.zip, > derby1223_html3.zip, derby1223_html4.zip, derby1223_html5.zip, > Derby1223_ProposedChanges.txt > > > As of the fix for DERBY-1082, the scripts were made consistent to require > setting DERBY_HOME (or DERBY_INSTALL) and JAVA_HOME. The documentation on > setting up your environment in the Getting Started guide should be updated to > reflect that these variables should be set. -- 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-1215) elements in documentation need expanse attributes after switch to OASIS DTDs
[ http://issues.apache.org/jira/browse/DERBY-1215?page=all ] Andrew McIntyre closed DERBY-1215. -- > elements in documentation need expanse attributes after switch to > OASIS DTDs > > > Key: DERBY-1215 > URL: http://issues.apache.org/jira/browse/DERBY-1215 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Andrew McIntyre > Assigned To: Kim Haase >Priority: Minor > Fix For: 10.2.1.6, 10.3.0.0 > > Attachments: DERBY-1215.diff, DERBY-1215_diff.txt, > DERBY-1215_pt_BR.diff > > > With revision 393972, I switched the DITA files in the doc tree to reference > the OASIS DTDs instead of the old IBM DTDs. This has caused some warnings to > appear in the build output, e.g.: > [pipeline] [Error] ctunproper22250.dita:31:60: Attribute "expanse" must be > declared for element type "table". > [pipeline] [Error] ctuntransform36368.dita:32:37: Attribute "expanse" must > be declared for element type "table". > [pipeline] [Error] ctuntransform36368.dita:49:37: Attribute "expanse" must > be declared for element type "table". > [pipeline] [Error] ctunoptimz42065.dita:58:37: Attribute "expanse" must be > declared for element type "table". > [pipeline] [Error] ctunoptimz42065.dita:86:37: Attribute "expanse" must be > declared for element type "table". > [pipeline] [Error] ctunoptimz42065.dita:114:37: Attribute "expanse" must be > declared for element type "table". > This does not appear to have affected the build or appearance of the docs, it > is just that these DITA files no longer conform to the DTD. -- 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-1032) Create new scripts which follow common practice at Apache
[ http://issues.apache.org/jira/browse/DERBY-1032?page=all ] Andrew McIntyre closed DERBY-1032. -- > Create new scripts which follow common practice at Apache > - > > Key: DERBY-1032 > URL: http://issues.apache.org/jira/browse/DERBY-1032 > Project: Derby > Issue Type: Improvement > Components: Demos/Scripts >Affects Versions: 10.2.1.6 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.2.1.6 > > Attachments: derby-1032-addtodist.diff, derby-1032-addtodist2.diff, > derby-1032-bin-sh.tgz, derby-1032-v1.diff, derby-1032-v2.diff > > > Scripts for Derby should be written to follow common practice at Apache. This > means locating them in a bin directory, and self configuring from the minimum > amount of information necessary: installation location and in our case, the > location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. > If these variables are not set, we should report this to the user. Good > examples are available in Ant, Forrest, and Maven, and much of the same setup > code can be reused from those projects. -- 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-744) Problem setting sanity state to false by using 'ant -Dsane=false'
[ http://issues.apache.org/jira/browse/DERBY-744?page=all ] Andrew McIntyre closed DERBY-744. - > Problem setting sanity state to false by using 'ant -Dsane=false' > - > > Key: DERBY-744 > URL: http://issues.apache.org/jira/browse/DERBY-744 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.1.3.1, 10.1.2.1, 10.2.1.6 >Reporter: Andrew McIntyre > Assigned To: Andrew McIntyre >Priority: Minor > Fix For: 10.1.4.0, 10.2.1.6 > > Attachments: derby-744-v1.diff > > > Problem report from Kathey Marsden: > There seems to be some sort of problem with the sanity state. > After ant clobber, rm -rf jars, rm -rf snapshot no apparent problematic > files, ant -Dsane=false snapshot seemed to sometimes build the jars to > the sane jar directory and yield the following error. > > [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir >[mkdir] Created dir: D:\svn\opensource\10.1\snapshot > BUILD FAILED > D:\svn\opensource\10.1\build.xml:1287: > D:\svn\opensource\10.1\jars\insane not found. > A reliable workaround was to run > ant insane > before ant -Dsane=false snapshot. -- 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] Army Brown as a committer
On 10/10/06, Mike Matrigali <[EMAIL PROTECTED]> wrote: This vote is for establishing Army Brown as a committer for Derby. Please vote +1 if you approve of Army as a committer. +1 andrew
Re: [testing]Test fails
Sean Qiu wrote: Any suggestions to address issues through the infomation provided by the output files? I'm actually not sure what's going on with your test. It looks like the supersimple.out and supersimple.tmp files that you attached are in fact identical; the only exception is that your supersimple.tmp file contains an extra line at the beginning saying ij version 10.2 which is I think fine, and should not cause the diff that you saw. So I'm afraid I don't know what is causing the test harness to report the diff that you are seeing. bryan
Re: [VOTE] Army Brown as a committer
+1 On 10/10/06, Mike Matrigali <[EMAIL PROTECTED]> wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
Re: [testing]Test fails
My linux distribution is ubuntu.I am not quite sure about what is the sort-related configurations.Could you figure it out for me?2006/10/10, Bryan Pendleton < [EMAIL PROTECTED]>: > We have just run the testcase for derby but it fails on windows.Can you tell (by inspection of the output and diff files on your machine)whether you are getting the same values in the output, but in a different order? If so, it sounds like the sort ordering is different on your machine thanis expected by the test.Is your Windows environment a simple English-language configuration? Orare you using a different locale or some other sort-related configuration? thanks,bryan
Re: [VOTE] Army Brown as a committer
+1 Narayanan Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
ApacheCon hackathon feathercast
At the hackathon today the feathercast guys hooked me for an off-the-cuff derby feathercast, and it is now episode 15 at http://www.feathercast.org/ . I know I got some details wrong (arg!). feel free to post corrections to it. cheers, -jean
[jira] Commented: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=comments#action_12441319 ] Bryan Pendleton commented on DERBY-183: --- When I ran derbyall, lang/procedure.java failed in the DerbyNet and DerbyNetClient frameworks. There are multiple procedure.out files in the various frameworks. Unfortunately, I think that all of them have to be updated. The diff should be the same in all of them, since your test doesn't depend on any particular network or JVM features. To see the problem: java -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest lang/procedure.java To see all the procedure.out files that need to be updated, do: find trunk/java -name procedure.out > Parameter names required in CREATE FUNCTION > --- > > Key: DERBY-183 > URL: http://issues.apache.org/jira/browse/DERBY-183 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.0 >Reporter: Jack Klebanoff > Assigned To: James F. Adams >Priority: Minor > Attachments: Derby183.patch.txt, Derby183.patch2.txt > > > A statement like > create function s2.f2( char(8), integer) returns int > language java parameter style java external name 'myclass.mymethod' > fails with the message > ERROR 42X01: Syntax error: Encountered "char" at line 1, column 24 > However > create function s2.f2( p1 char(8), p2 integer) returns int > language java parameter style java external name 'myclass.mymethod' > is accepted. > The Derby documentation (at > http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), > the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- 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: [testing]Test fails
Sorry, I made a mistake. It passes on windows but fails on unbuntu.:) On 10/11/06, Leo Li <[EMAIL PROTECTED]> wrote: On 10/10/06, Bryan Pendleton < [EMAIL PROTECTED]> wrote: > We have just run the testcase for derby but it fails on windows.Can you tell (by inspection of the output and diff files on your machine) whether you are getting the same values in the output, but in a different order?If so, it sounds like the sort ordering is different on your machine thanis expected by the test.Is your Windows environment a simple English-language configuration? Or are you using a different locale or some other sort-related configuration? The platform is winXP with simple chinese language, I think it might be related to this issue because of the sorting order? thanks,bryan -- Leo LiChina Software Development Lab, IBM -- Leo LiChina Software Development Lab, IBM
Re: [testing]Test fails
On 10/10/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote: > We have just run the testcase for derby but it fails on windows.Can you tell (by inspection of the output and diff files on your machine) whether you are getting the same values in the output, but in a different order?If so, it sounds like the sort ordering is different on your machine thanis expected by the test.Is your Windows environment a simple English-language configuration? Or are you using a different locale or some other sort-related configuration? The platform is winXP with simple chinese language, I think it might be related to this issue because of the sorting order? thanks,bryan-- Leo LiChina Software Development Lab, IBM
Re: [VOTE] Army Brown as a committer
Manjula G Kutty <[EMAIL PROTECTED]> writes: > I'm happy to see him as a committer In deed! +1 Dag
[jira] Updated: (DERBY-803) derbynet/DerbyNetAutoStart.java test fails intermittently with org.apache.derby.iapi.services.context.ShutdownException
[ http://issues.apache.org/jira/browse/DERBY-803?page=all ] Sunitha Kambhampati updated DERBY-803: -- Affects Version/s: 10.1.3.2 This test fails on 10.1.3.2 also. Does it make sense for this fix to be backported to 10.1 codeline ? Thanks. > derbynet/DerbyNetAutoStart.java test fails intermittently with > org.apache.derby.iapi.services.context.ShutdownException > --- > > Key: DERBY-803 > URL: http://issues.apache.org/jira/browse/DERBY-803 > Project: Derby > Issue Type: Test > Components: Network Server, Regression Test Failure >Affects Versions: 10.2.1.6, 10.3.0.0, 10.1.3.2 >Reporter: Kathey Marsden > Assigned To: Fernanda Pizzorno > Fix For: 10.2.1.6 > > Attachments: derby-803.diff, derby-803.stat, suggestion-803.diff, > suggestion-803.stat > > > DerbyNetAutoStart fails intermittently with the following diff: > This issue is likely related to DERBY-1020 > * Diff file > derbyall/derbynetmats/DerbyNet/derbynetmats/DerbyNetAutoStart.diff > *** Start: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats > 2006-01-05 23:39:40 *** > 1a2,3 > > org.apache.derby.iapi.services.context.ShutdownException: > > at org.apache.derby.impl.drda.Session.close(Unknown > > Source)agentThread[DRDAConnThread_3,5,derby.daemons] > Test Failed. > *** End: DerbyNetAutoStart jdk1.4.2 DerbyNet derbynetmats:derbynetmats > 2006-01-05 23:41:10 *** -- 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-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441312 ]
Suresh Thalamati commented on DERBY-1953:
-
I reviewed the latest patch , it looks good. I will commit it, after running
the tests.
> 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: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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] Updated: (DERBY-1457) lang/triggerGeneral.sql fails intermittently
[ http://issues.apache.org/jira/browse/DERBY-1457?page=all ] Sunitha Kambhampati updated DERBY-1457: --- Environment: - IBM wsdd5.6 j9_13 - IBM 142: java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) -ibm 1.5 was: - IBM wsdd5.6 j9_13 - IBM 142: java version "1.4.2_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) Test also fails with ibm1.5 with 10.3.0.0 alpha - (453830) jars. > lang/triggerGeneral.sql fails intermittently > > > Key: DERBY-1457 > URL: http://issues.apache.org/jira/browse/DERBY-1457 > Project: Derby > Issue Type: Test > Components: Regression Test Failure >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: - IBM wsdd5.6 j9_13 > - IBM 142: > java version "1.4.2_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) > Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) > -ibm 1.5 >Reporter: Deepa Remesh >Priority: Minor > > This failure seems to be intermittent. The diff is: > *** Start: triggerGeneral jdk1.3.1 subset - 2.1 derbyall:derbylang 2006-06-26 > 09:18:19 *** > 941 del > < DERBY-388 Test Passed. > 941a941,950 > > ERROR 38000: The exception 'SQL Exception: A SAVEPOINT with the passed name > > already exists in the current transaction.' was thrown while evaluating an > > expression. > > ERROR 3B501: A SAVEPOINT with the passed name already exists in the current > > transaction. > > ij> -- Derby-85: It turns out that if a table t1 exists in a non-default > > schema > > -- and the default schema (e.g., "SOMEUSER") doesn't exist yet (because no > > -- objects have been created in that schema), then attempts to create a > > -- trigger on t1 using its qualified name will lead to a null pointer > > -- exception in the Derby engine. > > connect 'wombat;user=someuser'; > > ij(CONNECTION1)> autocommit off; > > ij(CONNECTION1)> create table myschema.mytable (i int); > 943,951d951 > < ij> -- Derby-85: It turns out that if a table t1 exists in a non-default > schema > < -- and the default schema (e.g., "SOMEUSER") doesn't exist yet (because no > < -- objects have been created in that schema), then attempts to create a > < -- trigger on t1 using its qualified name will lead to a null pointer > < -- exception in the Derby engine. > < connect 'wombat;user=someuser'; > < ij(CONNECTION1)> autocommit off; > < ij(CONNECTION1)> create table myschema.mytable (i int); > < 0 rows inserted/updated/deleted > Test Failed. > *** End: triggerGeneral jdk1.3.1 subset - 2.1 derbyall:derbylang 2006-06-26 > 09:18:52 *** > Stack trace of failure is: > ERROR 3B501: A SAVEPOINT with the passed name already exists in the current > transaction. > at java.lang.Throwable.(Throwable.java) > at java.lang.Throwable.(Throwable.java) > at > org.apache.derby.iapi.error.StandardException.(StandardException.java:83) > at > org.apache.derby.iapi.error.StandardException.(StandardException.java:72) > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:294) > at > org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Xact.java:1420) > at > org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(RAMTransaction.java:1997) > at > org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(GenericStatementContext.java:257) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java) > at > org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecutor.java) > at > org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:110) > at > org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator.java:277) > at > org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(UpdateResultSet.java:825) > at > org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:288) > at > org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java) > at > org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) > at > org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) > at > org.apache.derbyTesting.functionTests.tests.lang.userDefMethods.derby388(userDefMethods.java:137) > at > org.apache.derby.exe.ac46a08075x010cx1122x5cc3x187d3624a5.g0(Unknown > Source) > at java.lang.reflect.AccessibleObj
[jira] Updated: (DERBY-1785) junit tests fail with permission access problems when run with j9 jvms
[ http://issues.apache.org/jira/browse/DERBY-1785?page=all ] Mike Matrigali updated DERBY-1785: -- Derby Info: (was: [Patch Available]) > 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] Updated: (DERBY-1785) junit tests fail with permission access problems when run with j9 jvms
[ http://issues.apache.org/jira/browse/DERBY-1785?page=all ] Mike Matrigali updated DERBY-1785: -- committed patch DERBY-1785_102_20061007.diff to 10.2 branch. unchecking patch available as fix has now gone in to trunk and 10.2. m102_ibm142:59>svn commit Sendingjava\testing\org\apache\derbyTesting\functionTests\harness\RunTes t.java Sendingjava\testing\org\apache\derbyTesting\functionTests\harness\j9_fou ndation.java Transmitting file data .. Committed revision 462625. > 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: [VOTE] Army Brown as a committer
+1 Bryan Pendleton wrote: This vote is for establishing Army Brown as a committer for Derby. Army's work has been consistently excellent. He was one of the first people to help me when I started working on Derby. +1 thanks, bryan -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: [VOTE] Army Brown as a committer
This vote is for establishing Army Brown as a committer for Derby. Army's work has been consistently excellent. He was one of the first people to help me when I started working on Derby. +1 thanks, bryan
[jira] Updated: (DERBY-1785) junit tests fail with permission access problems when run with j9 jvms
[ http://issues.apache.org/jira/browse/DERBY-1785?page=all ] Mike Matrigali updated DERBY-1785: -- committed patch DERBY-1785_20061007.diff to the trunk: m3_ibm142:47>svn commit Sending java\testing\org\apache\derbyTesting\functionTests\harness\j9_foundation.java Transmitting file data . Committed revision 462607. > 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: [VOTE] Army Brown as a committer
Mike Matrigali wrote (2006-10-10 12:48:00): > Please vote +1 if you approve of Army as a committer. +1 -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: Digital signature
[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:
--
Derby Info: [Patch Available]
Note that this patch have doc impact on CREATE TRIGGER statement syntax which
is described in the ref manual.
> 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: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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] 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:
--
Attachment: derby1953-trunk-stat02.txt
derby1953-trunk-diff02.txt
Resubmitting patch derby1953-trunk-diff02.txt for DERBY-1953. It is basically
the same patch with more testcases. derbyall passes.
> 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: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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] 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:
--
Derby Info: (was: [Patch Available])
Found a minor problem with the patch. Unchecking patch available. Will
resubmit patch.
> 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: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-stat01.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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
Re: [VOTE] Army Brown as a committer
On 10/10/06, Mike Matrigali <[EMAIL PROTECTED]> wrote: Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. +1
Re: [VOTE] Army Brown as a committer
Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. +1 -suresh
[jira] Updated: (DERBY-1829) lang/procedureInTrigger.sql fails with wctme5.7 foundation with CNFE java.sql.DriverManager and other exceptions.
[ http://issues.apache.org/jira/browse/DERBY-1829?page=all ] Mike Matrigali updated DERBY-1829: -- Fix Version/s: 10.2.1.8 (was: 10.2.2.0) Derby Info: (was: [Patch Available]) This fix has been committed to the trunk and the 10.2 branch. I am unsetting patch available, I'll let myrna test and close the issue. > lang/procedureInTrigger.sql fails with wctme5.7 foundation with CNFE > java.sql.DriverManager and other exceptions. > -- > > Key: DERBY-1829 > URL: http://issues.apache.org/jira/browse/DERBY-1829 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: This is only with wctme5.7_foundation >Reporter: Sunitha Kambhampati > Assigned To: Myrna van Lunteren > Fix For: 10.3.0.0, 10.2.1.8 > > Attachments: DERBY-1829_20061009.diff, wctme5.7_derbyall_report.txt > > > Test failed with 10.3 jars 10.3.0.0 alpha - (439522). I am attaching the > report file from the test run wctme5.7_derbyall_report.txt . Please see this > file for the diff. > This test was added as part of DERBY-551 and checkin - r421281. -- 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-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=all ] Laura Stewart reassigned DERBY-1954: Assignee: Laura Stewart > Update sysinfo output documentation in Tools and Utilities Guide > > > Key: DERBY-1954 > URL: http://issues.apache.org/jira/browse/DERBY-1954 > Project: Derby > Issue Type: Bug > Components: Documentation >Reporter: Laura Stewart > Assigned To: Laura Stewart > > Section = sysinfo > File = rtoolssysinfo1002629.html > In the example section, the new text = > With derby.jar and derbytools.jar in your classpath the output from running > the sysinfo command is shown below. > $ java org.apache.derby.tools.sysinfo > -- 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-1954) Update sysinfo output documentation in Tools and Utilities Guide
Update sysinfo output documentation in Tools and Utilities Guide Key: DERBY-1954 URL: http://issues.apache.org/jira/browse/DERBY-1954 Project: Derby Issue Type: Bug Components: Documentation Reporter: Laura Stewart Section = sysinfo File = rtoolssysinfo1002629.html In the example section, the new text = With derby.jar and derbytools.jar in your classpath the output from running the sysinfo command is shown below. $ java org.apache.derby.tools.sysinfo -- 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] Army Brown as a committer
I'm happy to see him as a committer +1 Rajesh Kartha wrote: Excellent, +1. Regards, -Rajesh Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
Re: [VOTE] Army Brown as a committer
Mike Matrigali wrote: Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. +1 Sunitha.
Re: [VOTE] Army Brown as a committer
On 10/10/06, Mike Matrigali <[EMAIL PROTECTED]> wrote: This vote is for establishing Army Brown as a committer for Derby. Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. +1 I think more committers will be good, judging by the number of issues with patches available...Army is a clearly a good choice. Myrna
Re: [VOTE] Army Brown as a committer
+1 Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
Re: [VOTE] Army Brown as a committer
+1Yip Ng
Re: [VOTE] Army Brown as a committer
Mike Matrigali wrote: Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. +1 -- Kristian
Re: [jira] Commented: (DERBY-1948) 10.2 'Working with Derby' manual errors.
The output change is apparently the result of the fix to http://issues.apache.org/jira/browse/DERBY-515, and it appears on both UNIX and Windows platforms. Kim Micky Connor wrote On 10/10/06 14:05,: > Yes, I noticed that too, but thought it was just > OS variation. > > Kim Haase (JIRA) wrote: > >>[ >> http://issues.apache.org/jira/browse/DERBY-1948?page=comments#action_12441196 >> ] >> >>Kim Haase commented on DERBY-1948: >>-- >> >>These aren't the only errors; the output messages are not quite as described, >>either. >> >> >> >>>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 >>> >>>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'. >>> >> >>
Re: [VOTE] Army Brown as a committer
Excellent, +1. Regards, -Rajesh Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
[VOTE] Army Brown as a committer
This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
[jira] Commented: (DERBY-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=comments#action_12441260 ] Kristian Waagan commented on DERBY-1951: See the mail thread for DERBY-1845. You need to run a test using the NetworkServerTestSetup-decorator. I don't know which tests use it, but if you run suites.All directly with JUnit, you should see the effect. > Missing directory separator in path construction in > 'NetworkServerTestSetup.setUp' > -- > > Key: DERBY-1951 > URL: http://issues.apache.org/jira/browse/DERBY-1951 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan > Attachments: derby-1951-1a.diff, derby-1951-1b.diff > > > When constructing the path for the server output file, the directory > separator (typically '/') is omitted, causing a security violation when > running under the security manager. Here's a sample stack trace for a JUnit > run: > 1) AllPackagesjava.security.AccessControlException: access denied > (java.io.FilePermission /some/pathserverConsoleOutput.log write) >at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) >at > java.security.AccessController.checkPermission(AccessController.java:401) >at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) >at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) >at java.io.FileOutputStream.(FileOutputStream.java:169) >at java.io.FileOutputStream.(FileOutputStream.java:70) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 > ) >at java.security.AccessController.doPrivileged(Native Method) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 > ) >at junit.extensions.TestSetup$1.protect(TestSetup.java:18) >at junit.extensions.TestSetup.run(TestSetup.java:23) >at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) >at junit.extensions.TestSetup$1.protect(TestSetup.java:19) >at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-630) create trigger fails with null pointer exception
[ http://issues.apache.org/jira/browse/DERBY-630?page=comments#action_12441257 ] Yip Ng commented on DERBY-630: -- Anyone else have a chance to try out and review the patch for this issue? > create trigger fails with null pointer exception > > > Key: DERBY-630 > URL: http://issues.apache.org/jira/browse/DERBY-630 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.1.1.0 > Environment: windows 2000, sun jdk 1.5.0 >Reporter: mardacay > Assigned To: Yip Ng > Attachments: derby630-trunk-diff01.txt, derby630-trunk-stat01.txt > > > When i create a brand new database, and execute the following statements all > in one transaction or each of them in their own transaction, then it fails at > trigger creation with null pointer exception. if i exclude the schema names > from statement, then it runs fine. (If S1 is ommited from every statement > then it runs fine). Once the version without the schema names run fine, i can > run the version that has schema names, fine also. > create schema S1; > create table > S1.PRODUCT( > PRODUCT_ID VARCHAR(255) unique not null, > VERSION BIGINT > ); > > create table > S1.CATEGORY( > CAT_ID VARCHAR(255), > NAME varchar(255) not null, > VERSION BIGINT > ); > create table > S1.PROD_IN_CAT( > CAT_ID VARCHAR(255) not null, > PRODUCT_ID VARCHAR(255) not null, > VERSION BIGINT > ); > > create trigger S1.product_v > after update of version on S1.product > referencing new as n > for each row > mode db2sql > update S1.prod_in_cat set version = n.version where > S1.prod_in_cat.product_id=n.product_id; > java.lang.NullPointerException > at > org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown > Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown > Source)Stopping progress indicator for: Executing SQL > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) -- 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-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:
--
Summary: Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement
optional (was: Make FOR EACH clause in CREATE TRIGGER statement optional)
> 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: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-stat01.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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] Commented: (DERBY-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=comments#action_12441247 ] Bryan Pendleton commented on DERBY-1951: Looks great, thanks! What test can I run in my environment to observe the effects of your change? > Missing directory separator in path construction in > 'NetworkServerTestSetup.setUp' > -- > > Key: DERBY-1951 > URL: http://issues.apache.org/jira/browse/DERBY-1951 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan > Attachments: derby-1951-1a.diff, derby-1951-1b.diff > > > When constructing the path for the server output file, the directory > separator (typically '/') is omitted, causing a security violation when > running under the security manager. Here's a sample stack trace for a JUnit > run: > 1) AllPackagesjava.security.AccessControlException: access denied > (java.io.FilePermission /some/pathserverConsoleOutput.log write) >at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) >at > java.security.AccessController.checkPermission(AccessController.java:401) >at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) >at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) >at java.io.FileOutputStream.(FileOutputStream.java:169) >at java.io.FileOutputStream.(FileOutputStream.java:70) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 > ) >at java.security.AccessController.doPrivileged(Native Method) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 > ) >at junit.extensions.TestSetup$1.protect(TestSetup.java:18) >at junit.extensions.TestSetup.run(TestSetup.java:23) >at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) >at junit.extensions.TestSetup$1.protect(TestSetup.java:19) >at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-1770) Make "mode db2sql" an optional phrase in the "create trigger" statement
[ http://issues.apache.org/jira/browse/DERBY-1770?page=comments#action_12441246 ] Yip Ng commented on DERBY-1770: --- DERBY-1953 also addresses this jira case. > Make "mode db2sql" an optional phrase in the "create trigger" statement > --- > > Key: DERBY-1770 > URL: http://issues.apache.org/jira/browse/DERBY-1770 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.0.2.2 >Reporter: Rick Hillegas > Assigned To: Bernt M. Johnsen > > In order to declare a trigger, you have to include the phrase "mode db2sql". > This phrase in non-ANSI--it does not turn up in the CREATE TRIGGER production > from the ANSI spec, volume 2, section 11.39. It does turn up in the DB2 > reference manual with the following explanation: "This clause is used to > specify the mode of triggers. This is the only valid mode currently > supported." > This phrase should be made optional. This will strike a happy balance between > our goals of supporting the ANSI syntax while still maintaining compatibility > with previous versions of Derby. -- 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-1953) Make FOR EACH clause in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Derby Info: [Patch Available]
> Make FOR EACH clause in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-stat01.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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] Updated: (DERBY-1953) Make FOR EACH clause in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Attachment: derby1953-trunk-stat01.txt
derby1953-trunk-diff01.txt
Attaching patch derby1953-trunk-diff01.txt. This patch makes the FOR EACH
clause optional in CREATE TRIGGER statement. Since the changes are mainly in
the trigger definition of sqlgrammar.jj file and to make this backward
compatibile with previous releases of Derby, I also addressed DERBY-1770, Make
MODE DB2SQL optional. (Hope Bernt doesn't mind) derbylang passes. Running
derbyall now.
> Make FOR EACH clause in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-stat01.txt
>
>
> According to SQL:2003 standard, section 11.39 , 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] Updated: (DERBY-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=all ] Kristian Waagan updated DERBY-1951: --- Attachment: derby-1951-1b.diff You are right Bryan. Sorry, I must have been writing way too many shell scripts lately... 'derby-1951-1b.diff' replaces revision a, incorporating the suggestion Bryan made. Patch ready for more review, or a commit. > Missing directory separator in path construction in > 'NetworkServerTestSetup.setUp' > -- > > Key: DERBY-1951 > URL: http://issues.apache.org/jira/browse/DERBY-1951 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan > Attachments: derby-1951-1a.diff, derby-1951-1b.diff > > > When constructing the path for the server output file, the directory > separator (typically '/') is omitted, causing a security violation when > running under the security manager. Here's a sample stack trace for a JUnit > run: > 1) AllPackagesjava.security.AccessControlException: access denied > (java.io.FilePermission /some/pathserverConsoleOutput.log write) >at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) >at > java.security.AccessController.checkPermission(AccessController.java:401) >at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) >at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) >at java.io.FileOutputStream.(FileOutputStream.java:169) >at java.io.FileOutputStream.(FileOutputStream.java:70) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 > ) >at java.security.AccessController.doPrivileged(Native Method) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 > ) >at junit.extensions.TestSetup$1.protect(TestSetup.java:18) >at junit.extensions.TestSetup.run(TestSetup.java:23) >at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) >at junit.extensions.TestSetup$1.protect(TestSetup.java:19) >at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=all ] Laura Stewart updated DERBY-1839: - Attachment: derby1839_functions2.diff derby1839_functions2_html.zip Per further comments from Susan, updated the following files: Filename Title rrefsqlj93082 SUBSTR rreftimestampfunc TIMESTAMP rrefsecondfunc SECOND Additionally, the other files updated were: Filename Title rrefbuiltsmallint SMALLINT rrefsqlj29930 UCASE or UPPER > Doc Review Updates - Ref Manual > --- > > Key: DERBY-1839 > URL: http://issues.apache.org/jira/browse/DERBY-1839 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Laura Stewart > Assigned To: Laura Stewart > Fix For: 10.2.2.0 > > Attachments: 1839_SQLstatements.diff, derby1839_functions1.diff, > derby1839_functions1.zip, derby1839_functions2.diff, > derby1839_functions2_html.zip, derby1839_SQLstatement_4.diff, > derby1839_SQLstatements2.diff, derby1839_SQLstatements2_html.zip, > derby1839_SQLstatements3.diff, derby1839_SQLstatements3_html.zip, > derby1839_SQLstatements4_html.zip, derby1839_SQLstatements_html.zip, > derby1839_TANCEILfunctions.diff, derby1839_TANCEILfunctions_html.zip, > derby1839_XML+functions_1.diff, derby1839_XML+functions_2.diff, > derby1839_XML+functions_html1.zip, derby1839_XML+functions_html2.zip > > > This JIRA issue will be used to track all of the issues found in the 10.2 doc > review of the Reference Manual. -- 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: [jira] Commented: (DERBY-1948) 10.2 'Working with Derby' manual errors.
Yes, I noticed that too, but thought it was just OS variation. Kim Haase (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1948?page=comments#action_12441196 ] Kim Haase commented on DERBY-1948: -- These aren't the only errors; the output messages are not quite as described, either. 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 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'.
Re: [testing]Test fails
It looks like the test harness is running jdk1.4.2_07 not sun 1.5.6. I find it hard to do debug these things with just the diff, can you attach the actual output file you are getting (both the .tmp and the .out) Leo Li wrote: Hi, all: We have just run the testcase for derby but it fails on windows. The jdk we used is Sun 1.5.6. We runs: java org.apache.derbyTesting.functionTests.harness.RunTest lang/supersimple.sql Then gets: -- listing properties -- derby.locks.deadlockTimeout=3 derby.locks.waitTimeout=3 test harness reporting jvm version: *** Start: supersimple jdk1.4.2_07 2006-10-10 16:32:31 *** 24 del < SI |I |BI |R |F |D |N5_2 |DEC10_3 |CH20 |VC |LVC |BLOBCOL |CLOBCOL 25 del <
[jira] Created: (DERBY-1953) Make FOR EACH clause in CREATE TRIGGER statement optional
Make FOR EACH clause in CREATE TRIGGER statement optional
-
Key: DERBY-1953
URL: http://issues.apache.org/jira/browse/DERBY-1953
Project: Derby
Issue Type: Improvement
Components: SQL
Affects Versions: 10.2.1.6
Environment: Any
Reporter: Yip Ng
Assigned To: Yip Ng
Priority: Minor
According to SQL:2003 standard, section 11.39 , 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] Commented: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=comments#action_12441215 ] Bryan Pendleton commented on DERBY-183: --- Hi James, thanks for the updated patch, and for the clear explanation of the LOOKAHEAD behaviors. The tests look good to me. They demonstrate the problem: they fail without the code changes, and they succeed when the code changes are applied. It is always good to have tests such as these. I had no trouble applying your patch and running the two modified tests. +1 from me to commit; is anyone else reviewing this change? > Parameter names required in CREATE FUNCTION > --- > > Key: DERBY-183 > URL: http://issues.apache.org/jira/browse/DERBY-183 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.0 >Reporter: Jack Klebanoff > Assigned To: James F. Adams >Priority: Minor > Attachments: Derby183.patch.txt, Derby183.patch2.txt > > > A statement like > create function s2.f2( char(8), integer) returns int > language java parameter style java external name 'myclass.mymethod' > fails with the message > ERROR 42X01: Syntax error: Encountered "char" at line 1, column 24 > However > create function s2.f2( p1 char(8), p2 integer) returns int > language java parameter style java external name 'myclass.mymethod' > is accepted. > The Derby documentation (at > http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), > the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- 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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[
http://issues.apache.org/jira/browse/DERBY-1951?page=comments#action_12441211 ]
Bryan Pendleton commented on DERBY-1951:
Your patch seems reasonable to me. If it were me, I would probably write the
additional lines
of code to omit the "extra" separator, something like:
String fileName = System.getProperty("derby.system.home");
if (!fileName.endsWith(FILESEPARATOR))
fileName = fileName + FILESEPARATOR;
fileName = fileName + "serverConsoleOutput.log";
The reason I would do this is that it doesn't seem like that much more code,
and it avoids
the possibility that somebody down the road in the future will be crawling
through things
and see something like /home/bpendleton/derby//serverConsoleOutput.log and
think,
even if just for a second, that "something is missing between 'derby' and
'serverConsoleOutput.log'".
Writing the extra code to avoid this now seems like it might save people time
in the
future by making the fileName string self-evidently correct.
> Missing directory separator in path construction in
> 'NetworkServerTestSetup.setUp'
> --
>
> Key: DERBY-1951
> URL: http://issues.apache.org/jira/browse/DERBY-1951
> Project: Derby
> Issue Type: Bug
> Components: Test
>Affects Versions: 10.3.0.0
>Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
> Attachments: derby-1951-1a.diff
>
>
> When constructing the path for the server output file, the directory
> separator (typically '/') is omitted, causing a security violation when
> running under the security manager. Here's a sample stack trace for a JUnit
> run:
> 1) AllPackagesjava.security.AccessControlException: access denied
> (java.io.FilePermission /some/pathserverConsoleOutput.log write)
>at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
>at
> java.security.AccessController.checkPermission(AccessController.java:401)
>at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
>at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
>at java.io.FileOutputStream.(FileOutputStream.java:169)
>at java.io.FileOutputStream.(FileOutputStream.java:70)
>at
> org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72
> )
>at java.security.AccessController.doPrivileged(Native Method)
>at
> org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65
> )
>at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
>at junit.extensions.TestSetup.run(TestSetup.java:23)
>at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>at junit.extensions.TestSetup.run(TestSetup.java:23)
--
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-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?page=comments#action_12441210 ]
Julius Stroffek commented on DERBY-1434:
Two machines works fine. It seems that this behaviour does not have any
influence on functionality.
The databaseName parameter from the PKGNAMCBytes is never used by the server.
The database is assigned to DRDAConnThread instance only in these functions on
the server:
org.apache.derby.impl.drda.DRDAConnThread.parseACCRDB()
org.apache.derby.impl.drda.DRDAConnThread.parseACCSEC()
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK()
Thus, this behaviour should not cause using a wrong database (unless multiple
databases are used in one session - which is AFAIK not possible). The
PKGNAMCSN is used in OPNQRY (used by PreparedStatement) to identify a statement
in a org.apache.derby.impl.drda.Database.stmTable (by hashcode). However, the
statement was even created with wrong PKGNAMCSN, so the hashes and even
PKGNAMCSN of stored statement match.
I observed a strange behaviour, when I changed the d1434.java (attached as
d1434_v2.java) to insert multiple records in a database. The code in go method
looks like (and behaves as described in comment).
st.execute("create table FIRSTDB_T1 (i int, j int, k int)"); // generates new
PKGNAMCSN (but the same as before)
st.execute("insert into FIRSTDB_T1 values (21, 22, 23)");// uses already
generated PKGNAMCSN
st.execute("insert into FIRSTDB_T1 values (22, 23, 24)");// generates new
PKGNAMCSN (but the same as before)
st.execute("insert into FIRSTDB_T1 values (23, 24, 25)");// uses already
generated PKGNAMCSN
st.execute("insert into FIRSTDB_T1 values (24, 25, 26)");// generates new
PKGNAMCSN (but the same as before)
st2.execute("create table SECONDDB_T1 (i int, j int, k int)"); // uses already
generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (11, 12, 13)");// uses already
generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (12, 13, 14)");// uses already
generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (13, 14, 15)");// uses already
generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (14, 15, 16)");// uses already
generated PKGNAMCSN
> Client can send incorrect database name to server after having made multiple
> connections to different databases.
>
>
> Key: DERBY-1434
> URL: http://issues.apache.org/jira/browse/DERBY-1434
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6, 10.1.3.1
>Reporter: A B
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, Server2.trace
>
>
> I have a simple program that connects to a database using the Derby Client,
> executes a simple query, then connects to a different database using a
> different Connection object and executes another simple query on that second
> connection. The queries both execute without error, so it appears that the
> connections are correct--i.e. each query will only work on one of the
> databases, and both queries work, therefore each must be getting executed
> against the correct database.
> But in looking at the client and server traces, I noticed that for the query
> on the second database, the client is actually sending the name of the
> *first* database as RDBNAM, which (I think?) is wrong--it should be sending
> the name of the second database, since the query is being executed on the
> second Connection object.
> This behavior does not appear to occur for JCC.
--
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-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?page=all ] Julius Stroffek updated DERBY-1434: --- Attachment: d1434_v2.java > Client can send incorrect database name to server after having made multiple > connections to different databases. > > > Key: DERBY-1434 > URL: http://issues.apache.org/jira/browse/DERBY-1434 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.2.1.6, 10.1.3.1 >Reporter: A B > Assigned To: Julius Stroffek > Fix For: 10.2.2.0 > > Attachments: _driver_1, d1434.java, d1434_v2.java, Server2.trace > > > I have a simple program that connects to a database using the Derby Client, > executes a simple query, then connects to a different database using a > different Connection object and executes another simple query on that second > connection. The queries both execute without error, so it appears that the > connections are correct--i.e. each query will only work on one of the > databases, and both queries work, therefore each must be getting executed > against the correct database. > But in looking at the client and server traces, I noticed that for the query > on the second database, the client is actually sending the name of the > *first* database as RDBNAM, which (I think?) is wrong--it should be sending > the name of the second database, since the query is being executed on the > second Connection object. > This behavior does not appear to occur for JCC. -- 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-1295) Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode
[ http://issues.apache.org/jira/browse/DERBY-1295?page=all ] Dag H. Wanvik closed DERBY-1295. > Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due > to positioning in autocommit mode > - > > Key: DERBY-1295 > URL: http://issues.apache.org/jira/browse/DERBY-1295 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Dag H. Wanvik > Assigned To: Fernanda Pizzorno >Priority: Minor > Fix For: 10.2.1.6 > > Attachments: derby-1295.diff, derby-1295.stat, derby-1295v2.diff, > derby-1295v2.stat, derby-1295v3.diff, derby-1295v3.stat, Main.java > > > The new JDBC 4 specification allows implementations to automatically > close result sets of type FORWARD_ONLY when ResultSet#next returns > false: > (quote from JDBC preliminary spec): > > 16.2.5 Closing a ResultSet Object > > : > > NOTE: Some JDBC driver implementations may also implicitly close the > > ResultSet when the ResultSet type is TYPE_FORWARD_ONLY and the next > > method of ResultSet returns false. > This implies that other result set type are not free to do this. > Currently, Derby will also implicitly close result sets of type > TYPE_SCROLL_INSENSITIVE, if autocommit is enabled. > Quote from Derby Developer's Guide, subsection "Using autocommit": > > > Using auto-commit > > > > A new connection to a Derby database is in auto-commit mode by > > default, as specified by the JDBC standard. Auto-commit mode means > > that when a statement is completed, the method commit is called on > > that statement automatically. Auto-commit in effect makes every SQL > > statement a transaction. The commit occurs when the statement > > completes or the next statement is executed, whichever comes > > first. In the case of a statement returning a ResultSet , the > > statement completes when the last row of the ResultSet has been > > > retrieved or the ResultSet has been closed explicitly. > This seems to indicate that result set always closes when the last row > has been seen, however, it seems the implementation only does this > when autocommit is enabled. I will attach a repro. > Anyway, this should be corrected for JDBC4 compliancy. Scrollable > result sets should never close implicitly due to positioning, > autocommit or not. -- 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-1926) Provide documentation for ALTER TABLE DROP COLUMN
[ http://issues.apache.org/jira/browse/DERBY-1926?page=all ] Bryan Pendleton updated DERBY-1926: --- Derby Info: [Patch Available] > Provide documentation for ALTER TABLE DROP COLUMN > - > > Key: DERBY-1926 > URL: http://issues.apache.org/jira/browse/DERBY-1926 > Project: Derby > Issue Type: New Feature > Components: Documentation >Affects Versions: 10.3.0.0 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton >Priority: Minor > Attachments: dropCol1.diff > > > The documentation will need to be updated after DERBY-1489 is committed. The > reference manual will need to describe how to use the new ALTER TABLE DROP > COLUMN feature to drop a column from a table. > The documentation for the ALTER TABLE command is becoming somewhat unwieldy, > so perhaps there is a way to restructure the page to make it easier and more > approachable. > In the documentation, it will be important to clearly describe the RESTRICT > and CASCADE behaviors, as users may be confused by what things cause RESTRICT > to refuse to drop a column. The comments in AlterTableConstantAction.java may > help. > Specifically, the documentation should note these possibly unexpected > behaviors: > - If a column is present in one or more indexes, these indexes by themselves > do not cause >RESTRICT to refuse to drop a column. Instead, the column will simply be > dropped from >the index, and if that was the last column in that index, the entire index > will be dropped. > - Explicitly named CHECK constraints will cause RESTRICT to refuse to drop a > column, as >will PRIMARY KEY, FOREIGN KEY, and UNIQUE constrants. However, an unnamed > simple >NOT NULL constraint on a column will NOT cause RESTRICT to refuse to drop > it. -- 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-1926) Provide documentation for ALTER TABLE DROP COLUMN
[ http://issues.apache.org/jira/browse/DERBY-1926?page=all ] Bryan Pendleton updated DERBY-1926: --- Attachment: dropCol1.diff Attached is dropCol1.diff, a proposed doc patch for the ALTER TABLE page in the reference guide. > Provide documentation for ALTER TABLE DROP COLUMN > - > > Key: DERBY-1926 > URL: http://issues.apache.org/jira/browse/DERBY-1926 > Project: Derby > Issue Type: New Feature > Components: Documentation >Affects Versions: 10.3.0.0 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton >Priority: Minor > Attachments: dropCol1.diff > > > The documentation will need to be updated after DERBY-1489 is committed. The > reference manual will need to describe how to use the new ALTER TABLE DROP > COLUMN feature to drop a column from a table. > The documentation for the ALTER TABLE command is becoming somewhat unwieldy, > so perhaps there is a way to restructure the page to make it easier and more > approachable. > In the documentation, it will be important to clearly describe the RESTRICT > and CASCADE behaviors, as users may be confused by what things cause RESTRICT > to refuse to drop a column. The comments in AlterTableConstantAction.java may > help. > Specifically, the documentation should note these possibly unexpected > behaviors: > - If a column is present in one or more indexes, these indexes by themselves > do not cause >RESTRICT to refuse to drop a column. Instead, the column will simply be > dropped from >the index, and if that was the last column in that index, the entire index > will be dropped. > - Explicitly named CHECK constraints will cause RESTRICT to refuse to drop a > column, as >will PRIMARY KEY, FOREIGN KEY, and UNIQUE constrants. However, an unnamed > simple >NOT NULL constraint on a column will NOT cause RESTRICT to refuse to drop > it. -- 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-1322) Missing resets of isOnInsertRow state in net client when navigating away via other than ResultSet#next
[ http://issues.apache.org/jira/browse/DERBY-1322?page=all ] Dag H. Wanvik closed DERBY-1322. > Missing resets of isOnInsertRow state in net client when navigating away via > other than ResultSet#next > -- > > Key: DERBY-1322 > URL: http://issues.apache.org/jira/browse/DERBY-1322 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.1.6 >Reporter: Dag H. Wanvik > Assigned To: Fernanda Pizzorno >Priority: Minor > Fix For: 10.2.1.6 > > Attachments: derby-1322.diff, derby-1322.stat, derby-1322v2.diff, > derby-1322v2.stat, Repro.java > > > Please see the enclosed repro program. > When attempting the deleteRow, it will fail with SQL state 24000 "no > current row", since the first() call doesn't properly reset the > IsOnInsertRow_ state. By inspection of ../am/ResultSet.java I found > the other positioning calls beside next and moveToCurrentRow to suffer > the same problem. -- 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-1338) Client tests DerbyNetNewServer and NSinSameVM fail with NoClassDefFoundError: DRDAProtocolExceptionInfo when run from classes dir
[ http://issues.apache.org/jira/browse/DERBY-1338?page=all ] Dag H. Wanvik closed DERBY-1338. > Client tests DerbyNetNewServer and NSinSameVM fail with NoClassDefFoundError: > DRDAProtocolExceptionInfo when run from classes dir > - > > Key: DERBY-1338 > URL: http://issues.apache.org/jira/browse/DERBY-1338 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.2.1.6 > Environment: Sun JDK 1.4.2, Sun JDK 1.5 on Solaris >Reporter: Dag H. Wanvik > Assigned To: Dag H. Wanvik >Priority: Minor > Fix For: 10.2.1.6 > > Attachments: derby-1338.diff, derby-1338.stat > > > When run from Sun JDK 1.4.2 and Sun JDK 1.5, these two tests fail when run > from the > classes directory. They work, though, when run from jars. > Running NSinSameVM in my sandbox: > bash-3.00$ java -Dframework=DerbyNetClient > org.apache.derbyTesting.functionTests.harness.RunTest > derbynet/NSinSameJVM.java > *** Start: NSinSameJVM jdk1.4.2_05 DerbyNetClient 2006-05-22 14:49:05 *** > Initialize for framework: DerbyNetClient > startServer = false. Bypass server startup > 6 add > > java.lang.NoClassDefFoundError: > > org/apache/derby/impl/drda/DRDAProtocolExceptionInfo > Test Failed. > *** End: NSinSameJVM jdk1.4.2_05 DerbyNetClient 2006-05-22 14:49:27 *** > I get similar behavior for DerbyNetNewServer. I ran this on a Solaris > 10/i86x box. Davis has seen it too, see > initial discusson on this thread: > http://www.nabble.com/forum/ViewPost.jtp?post=4477600&framed=y -- 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-1382) client: lobs fails silently with result sets of type TYPE_SCROLL_INSENSITIVE
[ http://issues.apache.org/jira/browse/DERBY-1382?page=all ] Dag H. Wanvik closed DERBY-1382. > client: lobs fails silently with result sets of type TYPE_SCROLL_INSENSITIVE > > > Key: DERBY-1382 > URL: http://issues.apache.org/jira/browse/DERBY-1382 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.1.3.1, 10.1.1.0, 10.1.2.1, 10.2.1.6 >Reporter: Dag H. Wanvik > Assigned To: Fernanda Pizzorno > Fix For: 10.2.1.6 > > Attachments: derby-1382-doc.diff, derby-1382.diff, derby-1382.stat, > Main.java > > > The documentation for 10.1 > (http://db.apache.org/derby/docs/10.1/adminguide/cadminappsclientdiffs.html) > states: > "Scrollable cursors (ResultSet.TYPE_SCROLL_SENSITIVE or > ResultSet.TYPE_SCROLL_INSENSITIVE) are not supported using the > network client if the result set contains LOB > data. TYPE_FORWARD_ONLY must be specified for result sets containing > LOB data." > Unfortunately, this is not signalled when one tries to use it, it just fails > silently, > cf. repro program. Either this should be implemented, or we should throw a > not implemented exception. For JDBC4 compliancy, it needs to be fixed, I > think. -- 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-1833) Remove messages made unused by implementation of DERBY-690 and DERBY-775
[ http://issues.apache.org/jira/browse/DERBY-1833?page=all ] Dag H. Wanvik closed DERBY-1833. > Remove messages made unused by implementation of DERBY-690 and DERBY-775 > > > Key: DERBY-1833 > URL: http://issues.apache.org/jira/browse/DERBY-1833 > Project: Derby > Issue Type: Improvement > Components: Documentation, JDBC >Affects Versions: 10.2.1.6 >Reporter: Dag H. Wanvik > Assigned To: Dag H. Wanvik >Priority: Minor > Fix For: 10.3.0.0, 10.2.1.6 > > Attachments: DERBY-1833.diff, DERBY-1833.diff, DERBY-1833.diff, > DERBY-1833.diff, DERBY-1833.stat, DERBY-1833.stat, DERBY-1833.stat, > DERBY-1833.stat > > > The implementation of scrollable insensitive result sets > made some warning messages redundant. They should be removed. > 01J09 > 01J11 > 01J03 > For XJ125 we should consider removing "sensitive" from text since it is > not currently supported: > > XJ125.S=This method should only be called on ResultSet objects that > > are scrollable (type TYPE_SCROLL_SENSITIVE or > > TYPE_SCROLL_INSENSITIVE). > -> > > XJ125.S=This method should only be called on ResultSet objects that > > are scrollable (type TYPE_SCROLL_INSENSITIVE). -- 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_12441196 ] Kim Haase commented on DERBY-1948: -- These aren't the only errors; the output messages are not quite as described, either. > 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 > > 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-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=all ] Kim Haase reassigned DERBY-1948: Assignee: Kim Haase > 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 > > 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
Discussion: Feedback needed on the Documentation Review process
For the 10.2 Documentation Review process, a wiki was used to log comments and track the status of those comments. http://wiki.apache.org/db-derby/TenTwoDocReview The purpose of the review is to take a comprehensive look at the documentation. Because most documentation updates are made for an isolated bug or feature, the new content isn't always looked at from a broader, library perspective. The end of cycle documentation review enables the community to take a look at the documentation as a whole. As someone who implemented a large number of the comments, I am interested in hearing feedback on the process: What worked well and what needs to be improved in the documentation review process? Was the wiki a good way to conduct the reviews? Did you understand how to log your comments? There were only a few people that participated in the review. What prevented more people from participating? Is the end of cycle the best time to perform the comprehensive review? Should the comprehensive review be performed at the beginning of a feature cycle? In the middle of a feature cycle? Please provide your feedback so that the documentation review process can be improved. Thanks! -- Laura Stewart
[jira] Commented: (DERBY-1936) Create sample application that demonstrates Derby running offline in browser and synchronizing with backend
[ http://issues.apache.org/jira/browse/DERBY-1936?page=comments#action_12441187 ] Daniel John Debrunner commented on DERBY-1936: -- Just for the record this application depends on two third party downloads (and I assume is is coded against those apis): 1.7 GOOGLE CALENDAR DATA API JAVA CLIENT http://code.google.com/apis/gdata/download/gdata.java.zip http://code.google.com/apis/gdata/calendar.html Licence is ALv2, see COPYING file in downloaded archive 1.8 JSON FOR JAVA http://www.json.org/java/json.zip Licence is in http://www.json.org/license.html I think the licence is BSD-like, so I see no issues in having code in Derby's SVN that works against JSON APIs. I don't believe we could have the JSON jar itself in the Derby achives since it does impose a restriction on its use, "The Software shall be used for Good, not Evil.". Thanks for the contribution David. > Create sample application that demonstrates Derby running offline in browser > and synchronizing with backend > --- > > Key: DERBY-1936 > URL: http://issues.apache.org/jira/browse/DERBY-1936 > Project: Derby > Issue Type: New Feature > Components: Demos/Scripts >Reporter: David Van Couvering > Assigned To: David Van Couvering >Priority: Minor > Fix For: 10.2.2.0 > > Attachments: localcal.diff > > > This is a placeholder for the LocalCalendar application I have written which > demonstrates the embedded/offline capabilities of Derby through a > sample application that lets you manage GoogleCalendar events offline and > synchronize when you come back online -- 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
Discussion: What prevents you from updating derby documentation?
The Derby Documentation page that describes how to setup your environment, update the files, and submit patches. http://db.apache.org/derby/manuals/dita.html Yet there are very few contributors who actually update the documentation. WHY? What prevents you from updating the documentation when you update the code? Please add your suggestions for the things that you would like to see updated/added to make it easier to for people to update the Derby documentation. Here are a few of my recommendations: 1) The instructions on the Derby Documentation page need to be more comprehensive... there are missing steps or assumptions made about a contributors knowledge. 1.a. The instructions for downloading and unzipping the DITA toolkit are for the first time that you do it. If you already have it downloaded and unzipped, the steps are missing for what you should do. 2) For new information, there aren't any "templates" for the topic types: concepts, reference, task. There also isn't a good description of how to decide which type to use. 3) There are no guidelines for how to tag the text. -- Laura Stewart
[jira] Resolved: (DERBY-1950) Invalid 39004 message when function has primitive type parameter but null is passed into String type parameter
[ http://issues.apache.org/jira/browse/DERBY-1950?page=all ] Daniel John Debrunner resolved DERBY-1950. -- Resolution: Invalid Derby Info: (was: [Regression]) As indicated by reported. > Invalid 39004 message when function has primitive type parameter but null is > passed into String type parameter > -- > > Key: DERBY-1950 > URL: http://issues.apache.org/jira/browse/DERBY-1950 > Project: Derby > Issue Type: Bug >Affects Versions: 10.1.3.1 > Environment: N/A >Reporter: Oleksandr Alesinskyy >Priority: Minor > > create function countDelimitersBefore( > str varchar(512), > delimiter char(1), > pos integer) > returns integer > language java parameter style java > external name 'de.ntec.common.util.DBStringUtils.countDelimitersBefore'; > select countDelimitersBefore(someColumn,'/',1) from someTable; > where value of SomeColumn is NULL inappropriatly results in > SQL State = 39004 SQL Code = -1 SQL Message = A NULL value cannot be passed > to a method which takes a parameter of primitive type 'int'. Exception > message = org.apache.derby.client.am.SqlException: A NULL value cannot be > passed to a method which takes a parameter of primitive type 'int'. > As far as I can see in 10.2.1.6 this bug is fixed. -- 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-1001) Rewrite 'store/encryptionKey.sql' to a JUnit test
[ http://issues.apache.org/jira/browse/DERBY-1001?page=comments#action_12441172 ] Daniel John Debrunner commented on DERBY-1001: -- I would say b) is the correct solution. Any call in derby that could result in a security manager check/exception needs to be in a privileged block. However, I don't understand your concern to b) when you say "since the files Derby needs to read may be anywhere". Could you explain more? Thanks. > Rewrite 'store/encryptionKey.sql' to a JUnit test > - > > Key: DERBY-1001 > URL: http://issues.apache.org/jira/browse/DERBY-1001 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.2.1.6 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan >Priority: Minor > > This test has failed on Solaris10 for a long time, due to issues with the > default security provider on this OS. See DERBY-788 for details. > I consider rewriting this test as interresting because it allows us to see > how things can be done in "the JUnit way". > 1) Run test with multiple encryption algorithms with minimal test code > duplication. > 2) Special handling of exceptions for specific providers (PCKS11-Solaris). > The rewritten test might cause some discussion on how we want to handle the > issues mentioned above. -- 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 - 454410 - Sun DBTG
[Auto-generated mail] ** 454410/2006-10-09 18:00:07 MEST ** Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 1686685 0 106.20% lin 1686685 0 110.81% sol 1686685 097.06% solN+1 1686685 0 107.46% sparc 1686685 0 160.72% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.6/Limited/testSummary-454410.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.6/454410.html *Jvm: 1.5* 0674674 2 105.22% lin 0674674 2 113.85% sol 0674674 296.67% solN+1 0674674 2 106.41% sparc 0674674 2 170.34% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.5/Limited/testSummary-454410.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.5/454410.html *Jvm: 1.4* 0668668 4 105.37% lin 0668668 4 109.27% sol 0668668 497.52% solN+1 1668667 4 106.27% sparc 0668668 497.50% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.4/Limited/testSummary-454410.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.4/454410.html --- Changes in http://www.multinet.no/~solberg/public/Apache/Daily/UpdateInfo/454410.txt ( All results in http://www.multinet.no/~solberg/public/Apache/Daily/index.html )
[jira] Created: (DERBY-1952) Remove the running of JUnit tests from the old derby test harness to allow faster conversion to a pure-Junit world.
Remove the running of JUnit tests from the old derby test harness to allow faster conversion to a pure-Junit world. --- Key: DERBY-1952 URL: http://issues.apache.org/jira/browse/DERBY-1952 Project: Derby Issue Type: Test Components: Test Reporter: Daniel John Debrunner Assigned To: Daniel John Debrunner Assuming we had a top-level JUnit suite that ran all the Junit tests successfully (with the same configuration coverage as they are run today in derbyall) switch to a dual testing environment until all the tests were converted to JUnit. This would include removing all the JUnit tests from the old harness suite files. That is if one wanted to run all the tests one would have to run: derbyall with the old harness suites.All using JUnit test runners directly. Discussion thread is: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200610.mbox/[EMAIL PROTECTED] Since no objections have been raised I will make progress on this. -- 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] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (12 issues) Subscriber: derby-dev Key Summary DERBY-183 Parameter names required in CREATE FUNCTION http://issues.apache.org/jira/browse/DERBY-183 DERBY-1951 Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' http://issues.apache.org/jira/browse/DERBY-1951 DERBY-1938 Add support for setObject(, null) http://issues.apache.org/jira/browse/DERBY-1938 DERBY-1829 lang/procedureInTrigger.sql fails with wctme5.7 foundation with CNFE java.sql.DriverManager and other exceptions. http://issues.apache.org/jira/browse/DERBY-1829 DERBY-1893 Convert largedata/lobLengthTests.java to junit http://issues.apache.org/jira/browse/DERBY-1893 DERBY-1785 junit tests fail with permission access problems when run with j9 jvms http://issues.apache.org/jira/browse/DERBY-1785 DERBY-1930 Move JDBC implementation notes into the published javadoc http://issues.apache.org/jira/browse/DERBY-1930 DERBY-1918 INCREMENT of IDENTITY column described as allowing a value of zero in reference manual http://issues.apache.org/jira/browse/DERBY-1918 DERBY-630 create trigger fails with null pointer exception http://issues.apache.org/jira/browse/DERBY-630 DERBY-963 Allow user friendly string values for security mechanism in client connection url. http://issues.apache.org/jira/browse/DERBY-963 DERBY-1808 [PATCH] Inbuilt functions SIGN, SQRT, RAND, RANDOM, COSH, SINH and TANH http://issues.apache.org/jira/browse/DERBY-1808 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646
Re: [jira] Commented: (DERBY-1845) OutOfMemoryError when running "All" suite directly using JUnit
On 10/10/06, Kristian Waagan <[EMAIL PROTECTED]> wrote: Hello Deepa, Yes, I'm also seeing this. I think there is a bug in NetworkServerTestSetup.setUp(), where the path is constructed without a directory separator between the rundir and the filename (line 68). When fixing this, I got the results posted below (sorry for the long stack traces). I'll look for a suitable Jira for the bug, or create a new one if necessary. Thanks Kristian for looking into this. Deepa
Re: derby web site broken links (was Re: to-do list on website should go)
> On 10/2/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote: >> Andrew McIntyre wrote: >> ... >> > I'm very much in agreement with keeping broken links to a minimum. I >> > had done a good job of eliminating most of the broken links on the >> > website, but I see from Vadim's stats that the number of broken links >> > have shot back up: >> > >> > http://people.apache.org/~vgritsenko/stats/projects/derby.html >> > >> > And since I can't get to the error logs on ajax, I have no idea what >> > is causing them, although it happened around Sept. 1, whatever it was. >> >> The logs are getting copied to /x1/logarchive/www/ on people.apache.org. >> >> There are 47 broken links for September > > Weird. Any idea why Vadim's stats show us getting thousands of broken > links a day? thousands *daily* now? I wasn't seeing thousands before. I'm at the hackathon -- when you get to ApacheCon, let's take a closer look at it. At the very least, it sounds like we could add more info to the derby web site on how (and what) to monitor on the derby web site. -jean
Re: [testing]Test fails
We have just run the testcase for derby but it fails on windows. Can you tell (by inspection of the output and diff files on your machine) whether you are getting the same values in the output, but in a different order? If so, it sounds like the sort ordering is different on your machine than is expected by the test. Is your Windows environment a simple English-language configuration? Or are you using a different locale or some other sort-related configuration? thanks, bryan
[jira] Commented: (DERBY-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=comments#action_12441151 ] Tomohito Nakayama commented on DERBY-1942: -- Reading the spcec, java.sql.Time is not compatible to JDBC TIMESTAMP. > There exists difference between behavior of setNull(Types.TIME) and > setTiime(null). > > > Key: DERBY-1942 > URL: http://issues.apache.org/jira/browse/DERBY-1942 > Project: Derby > Issue Type: Bug > Components: JDBC >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > > The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is > regarded as error. > However, the result of setTime(null) for TIMESTAMP typed variable is not > regarded as error . > see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- 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-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?page=comments#action_12441150 ] Julius Stroffek commented on DERBY-1434: Just posting the message below to the right place: --- When client creates multiple connections to different databases (through the JDBC driver), the DRDA protocol 'always' (I'm not sure if always but i have not found any situation when it does not) sends the same PKGNAMCSN block as the one used for a first created connection. The reason of this behaviour is in a creation of the Section object in SectionManager using it's method 'getDynamicSection'. It creates the section by calling the getSection(freeSections[Non]Hold_, packageNameWith[No]Hold__, cursorNamePrefixWith[No]Hold__, resultSetHoldability) which later calls the init method of the Section class with the parameter isGenerated = false. Due to this the buffer which is used to store the PKGNAMCSN is initialized to the value stored in Agent.SectionManager.holdPKGNAMCBytes - this field is declared static so the value is shared among all created connections. The reusing of the value from the buffer is probably only a performance improvement and if the value in a Section object (created with isGenerated = false) is not initialized it is generated on demand and also stored to SectionManager.holdPKGNAMCBytes. I would suggest removing the static modifier from the fields noHoldPKGNAMCBytes and holdPKGNAMCBytes of the org.apache.derby.client.am.SectionManager class. Each Connection objects holds its own Agent object which holds its own SectionManager object. Thus, the PKGNAMCSN blocks will be generated once for each Connection object. Is this right? However, the description of DRDA protocol looks like a PKGNAMCSN block is important to identify the correct server's sql executional package (I'm not an expert, it's only my opinion). How it is possible that sending a wrong PKGNAMCSN does not affect the database behavior? In the demonstration program on JIRA both connections connect to the same server instance. Might connecting these connections to different machines (or only server instances) lead to improper behavior? Why requests with the wrong PKGNAMCSN still work? I'll try two different machines tomorrow (approx. in 16 hours) and let you know. > Client can send incorrect database name to server after having made multiple > connections to different databases. > > > Key: DERBY-1434 > URL: http://issues.apache.org/jira/browse/DERBY-1434 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.2.1.6, 10.1.3.1 >Reporter: A B > Assigned To: Julius Stroffek > Fix For: 10.2.2.0 > > Attachments: _driver_1, d1434.java, Server2.trace > > > I have a simple program that connects to a database using the Derby Client, > executes a simple query, then connects to a different database using a > different Connection object and executes another simple query on that second > connection. The queries both execute without error, so it appears that the > connections are correct--i.e. each query will only work on one of the > databases, and both queries work, therefore each must be getting executed > against the correct database. > But in looking at the client and server traces, I noticed that for the query > on the second database, the client is actually sending the name of the > *first* database as RDBNAM, which (I think?) is wrong--it should be sending > the name of the second database, since the query is being executed on the > second Connection object. > This behavior does not appear to occur for JCC. -- 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-854) DatabaseMetaData methods fail on read-only database
[
http://issues.apache.org/jira/browse/DERBY-854?page=comments#action_12441147 ]
Sunitha Kambhampati commented on DERBY-854:
---
I tried the repro against the BirtSample.jar and cannot reproduce this failure
with 10.1.3 jars. I can reproduce this failure with 10.1.2.1 jars. So it
looks like this issue got solved somewhere in between 10.1.2.1 and 10.1.3.
Gary and Joakim, can you try with the 10.1.3
(http://db.apache.org/derby/releases/release-10.1.3.1.cgi) or the latest
release 10.2.1.6 jars and confirm this fixes the issue for you. Thanks.
> DatabaseMetaData methods fail on read-only database
> ---
>
> Key: DERBY-854
> URL: http://issues.apache.org/jira/browse/DERBY-854
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.1.2.1
> Environment: Win XP SP2 / Intel
>Reporter: Alex Miller
> Attachments: BirtSample.jar, TestGetDBMetaData.java
>
>
> I am using a read-only db in a zip file with Derby in embedded mode. I ran
> an importer against it which basically just harvests info from
> DatabaseMetaData and got an error on several methods like this one. The
> method in question here is DatabaseMetaData.getTableTypes(). The same thing
> seems to happen on other methods I've tried as well (getCatalogs,
> getProcedures, etc).
> Program:
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
> Connection conn =
> DriverManager.getConnection("jdbc:derby:jar:(d:\\derby\\bqt\\zipped\\bqt-mini.zip)bqt");
> DatabaseMetaData dbmd = conn.getMetaData();
> ResultSet rs = dbmd.getTableTypes();
> ERROR 40XD1: Container was opened in read-only mode.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at org.apache.derby.impl.store.raw.data.BaseContainer.use(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
> Source)
> at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown
> Source)
> at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.RowChangerImpl.openForUpdate(Unknown Source)
> at org.apache.derby.impl.sql.execute.RowChangerImpl.open(Unknown
> Source)
> at org.apache.derby.impl.sql.catalog.TabInfoImpl.deleteRows(Unknown
> Source)
> at org.apache.derby.impl.sql.catalog.TabInfoImpl.deleteRow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.dropDependentsStoredDependencies(Unknown
> Source)
> at
> org.apache.derby.impl.sql.depend.BasicDependencyManager.clearDependencies(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(Unknown
> Source)
> at org.apache.derby.impl.sql.compile.ExecSPSNode.generate(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.(Unknown
> Source)
> at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.prepareMetaDataStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.prepareSPS(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaData.getPreparedQuery(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedDatabaseMetaD
[jira] Updated: (DERBY-183) Parameter names required in CREATE FUNCTION
[ http://issues.apache.org/jira/browse/DERBY-183?page=all ] James F. Adams updated DERBY-183: - Attachment: Derby183.patch2.txt I have attached an updated patch (Derby183.patch2.txt) that modifies the following files: java/engine/org/apache/derby/impl/sql/compile/CreateAliasNode.java java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure.java java/testing/org/apache/derbyTesting/functionTests/master/procedure.out java/testing/org/apache/derbyTesting/functionTests/util/ProcedureTest.java java/testing/org/apache/derbyTesting/functionTests/tests/lang/functions.sql java/testing/org/apache/derbyTesting/functionTests/master/functions.out Tests have been added to lang/functions.sql and lang/procedure.java. I added a comment to sqlgrammar.jj to explain the need for the LOOKAHEAD(2). The parameter name is made optional by surrounding its production with []. This changes the grammar from: parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) typeDescriptor = dataTypeDDL() to: [ parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) ] typeDescriptor = dataTypeDDL() This results in a choice conflict because certain tokens satisfy both identifier() and dataTypeDDL(). An additional token of lookahead resolves this conflict. This results in: [ LOOKAHEAD(2) parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) ] typeDescriptor = dataTypeDDL() Expressing this in an alternate form such as: ( parameterName = identifier(Limits.MAX_IDENTIFIER_LENGTH, true) typeDescriptor = dataTypeDDL() ) | typeDescriptor = dataTypeDDL() still results in a choice conflict so I opted for the more compact form. > Parameter names required in CREATE FUNCTION > --- > > Key: DERBY-183 > URL: http://issues.apache.org/jira/browse/DERBY-183 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.0.2.0 >Reporter: Jack Klebanoff > Assigned To: James F. Adams >Priority: Minor > Attachments: Derby183.patch.txt, Derby183.patch2.txt > > > A statement like > create function s2.f2( char(8), integer) returns int > language java parameter style java external name 'myclass.mymethod' > fails with the message > ERROR 42X01: Syntax error: Encountered "char" at line 1, column 24 > However > create function s2.f2( p1 char(8), p2 integer) returns int > language java parameter style java external name 'myclass.mymethod' > is accepted. > The Derby documentation (at > http://incubator.apache.org/derby/manuals/reference/sqlj27.html#CREATE+PROCEDURE+Statement), > the SQL2003 standard, and DB2 all agree that the parameter name is optional. -- 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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=all ] Kristian Waagan updated DERBY-1951: --- Attachment: derby-1951-1a.diff 'derby-1951-1a.diff' fixes a bug that can be seend depending on the specification of 'derby.system.home'. If it does not end with a file separator, which is the case if specifed as 'pwd' on Unix system, an invalid path is constructed for the server log file. Note that after this patch is applied, other errors and failurs will emerge when running the 'All' JUnit suite (Tests run: 1760, Failures: 4, Errors: 3). Patch is ready for review/commit. I have made the insertion of the file separator unconditional, in the belief that multiple file separators will be handled by the JVM/OS. This can easily be changed if required. > Missing directory separator in path construction in > 'NetworkServerTestSetup.setUp' > -- > > Key: DERBY-1951 > URL: http://issues.apache.org/jira/browse/DERBY-1951 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan > Attachments: derby-1951-1a.diff > > > When constructing the path for the server output file, the directory > separator (typically '/') is omitted, causing a security violation when > running under the security manager. Here's a sample stack trace for a JUnit > run: > 1) AllPackagesjava.security.AccessControlException: access denied > (java.io.FilePermission /some/pathserverConsoleOutput.log write) >at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) >at > java.security.AccessController.checkPermission(AccessController.java:401) >at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) >at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) >at java.io.FileOutputStream.(FileOutputStream.java:169) >at java.io.FileOutputStream.(FileOutputStream.java:70) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 > ) >at java.security.AccessController.doPrivileged(Native Method) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 > ) >at junit.extensions.TestSetup$1.protect(TestSetup.java:18) >at junit.extensions.TestSetup.run(TestSetup.java:23) >at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) >at junit.extensions.TestSetup$1.protect(TestSetup.java:19) >at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
[ http://issues.apache.org/jira/browse/DERBY-1951?page=all ] Kristian Waagan updated DERBY-1951: --- Derby Info: [Patch Available] > Missing directory separator in path construction in > 'NetworkServerTestSetup.setUp' > -- > > Key: DERBY-1951 > URL: http://issues.apache.org/jira/browse/DERBY-1951 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan > Attachments: derby-1951-1a.diff > > > When constructing the path for the server output file, the directory > separator (typically '/') is omitted, causing a security violation when > running under the security manager. Here's a sample stack trace for a JUnit > run: > 1) AllPackagesjava.security.AccessControlException: access denied > (java.io.FilePermission /some/pathserverConsoleOutput.log write) >at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) >at > java.security.AccessController.checkPermission(AccessController.java:401) >at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) >at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) >at java.io.FileOutputStream.(FileOutputStream.java:169) >at java.io.FileOutputStream.(FileOutputStream.java:70) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 > ) >at java.security.AccessController.doPrivileged(Native Method) >at > org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 > ) >at junit.extensions.TestSetup$1.protect(TestSetup.java:18) >at junit.extensions.TestSetup.run(TestSetup.java:23) >at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) >at junit.extensions.TestSetup$1.protect(TestSetup.java:19) >at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-1951) Missing directory separator in path construction in 'NetworkServerTestSetup.setUp'
Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' -- Key: DERBY-1951 URL: http://issues.apache.org/jira/browse/DERBY-1951 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.0.0 Reporter: Kristian Waagan Assigned To: Kristian Waagan When constructing the path for the server output file, the directory separator (typically '/') is omitted, causing a security violation when running under the security manager. Here's a sample stack trace for a JUnit run: 1) AllPackagesjava.security.AccessControlException: access denied (java.io.FilePermission /some/pathserverConsoleOutput.log write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) at java.io.FileOutputStream.(FileOutputStream.java:169) at java.io.FileOutputStream.(FileOutputStream.java:70) at org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 ) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 ) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) -- 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-1610) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12441136 ] Tomohito Nakayama commented on DERBY-1610: -- Thank you for clean up those. I have a concern for checkTypeForSetAsciiStream, checkTypeForSetBlob, checkTypeForSetClob. I think static method is better than instance methods, because information handled in the static method is clearer ... > Resolve difference of type compatibility between Embedded and > NetworkServer/NetworkDriver > - > > Key: DERBY-1610 > URL: http://issues.apache.org/jira/browse/DERBY-1610 > Project: Derby > Issue Type: Bug > Components: Network Server, Network Client >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > Attachments: derby-1610-jdk16.diff, DERBY-1610.diff, > DERBY-1610_2.diff, DERBY-1610_3.diff, DERBY-1610_4.diff, DERBY-1610_5.diff, > DERBY-1610_6.patch, DERBY-1610_7.patch, DERBY-1610_7_regressionfix.patch, > DERBY-1610_7_regressionfix_2.patch, DERBY-1610_7_regressionfix_2_2.patch, > DERBY-1610_7_regressionfix_2_3.patch, parameterMapping.diff, > parameterMapping.diff, > parameterMapping.diff.betweenEmbedded_and_NetworkServerNetworkClient, > parameterMapping.out.7.diff, parameterMapping.out.diff, > parameterMapping_3.diff, TestNullChar.java, TestTypeCompatibility.java, > XCL12.diff > > > There exists difference of type compatibility between Embedded and > NetworkServer/NetworkClient. > This issue tries to resolve it. -- 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-1916) convert jdbcapi/BLOBDataModelSetup.java to junit
[ http://issues.apache.org/jira/browse/DERBY-1916?page=all ] Fernanda Pizzorno closed DERBY-1916. Resolution: Fixed jdbcapi/BLOBDataModelSetup.java is already Junit > convert jdbcapi/BLOBDataModelSetup.java to junit > > > Key: DERBY-1916 > URL: http://issues.apache.org/jira/browse/DERBY-1916 > Project: Derby > Issue Type: Sub-task >Reporter: Anurag Shekhar > Assigned To: Anurag Shekhar >Priority: Minor > -- 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: [jira] Commented: (DERBY-1845) OutOfMemoryError when running "All" suite directly using JUnit
Deepa Remesh wrote: On 10/9/06, Knut Anders Hatlen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1845?page=comments#action_12440846 ] Knut Anders Hatlen commented on DERBY-1845: --- Is this still a problem after DERBY-1910? I believe this issue is same as DERBY-1910 and should be resolved now. However, I have not been able to verify this. When I run the "All" suite directly using junit, I am getting a new error at the point where it tries to run the client tests; 1) AllPackagesjava.security.AccessControlException: access denied (java.io.FilePermission C:\deepa\j unit_testserverConsoleOutput.log write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkWrite(SecurityManager.java:954) at java.io.FileOutputStream.(FileOutputStream.java:169) at java.io.FileOutputStream.(FileOutputStream.java:70) at org.apache.derbyTesting.junit.NetworkServerTestSetup$1.run(NetworkServerTestSetup.java:72 ) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:65 ) at junit.extensions.TestSetup$1.protect(TestSetup.java:18) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) I have not seen this error before and wondering if it is caused by something in my environment. Is anyone else seeing this? Hello Deepa, Yes, I'm also seeing this. I think there is a bug in NetworkServerTestSetup.setUp(), where the path is constructed without a directory separator between the rundir and the filename (line 68). When fixing this, I got the results posted below (sorry for the long stack traces). I'll look for a suitable Jira for the bug, or create a new one if necessary. Time: 280.066 There were 3 errors: 1) grantRevokeAfterSettingSQLAuthProperty(org.apache.derbyTesting.functionTests. tests.lang.SQLAuthorizationPropTest)java.sql.SQLException: A network protocol er ror was encountered and the connection has been terminated: the requested comman d encountered an unarchitected and implementation-specific condition for which t here was no architected message at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExc eptionFactory.java:46) at org.apache.derby.client.am.SqlException.getSQLException(SqlException. java:345) at org.apache.derby.client.am.Statement.execute(Statement.java:826) at org.apache.derbyTesting.functionTests.tests.lang.SQLAuthorizationProp Test.grantRevokeAfterSettingSQLAuthProperty(SQLAuthorizationPropTest.java:125) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 76) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) Caused by: org.apache.derby.client.am.DisconnectException: A network protocol er ror was encountered and the connection has been terminated: the requested comman d encountered an unarchitected and implementation-specific condition for which t here was no architected message at org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConne ctionReply.java:888) at org.apache.derby.client.net.NetStatementReply.parseExecuteImmediateEr ror(NetStatementReply.java:562) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMreply(Net StatementReply.java:210) at org.apache.derby.client.net.NetStatementReply.readExecuteImmediate(Ne tStatementReply.java:58) at org.apache.derby.client.net.StatementReply.readExecuteImmediate(State mentReply.java:45) at org.apache.derby.client.net.NetStatement.readExecuteImmediate_(NetSta tement.java:125) at org.apache.derby.client.am.Statement.
[jira] Updated: (DERBY-1610) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver
[ http://issues.apache.org/jira/browse/DERBY-1610?page=all ] Knut Anders Hatlen updated DERBY-1610: -- Attachment: derby-1610-jdk16.diff Attaching a patch which fixes the failures in the jdbc40 suite (see http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.6/testlog/solN+1/454410-derbyall_diff.txt). Description of the patch (derby-1610-jdk16.diff): * Check for unsupported types before checking incompatibilities since JDBC 4.0 specifies that SQLFeatureNotSupportedException should be raised for certain types if they are unsupported. * Change timing of calls to checkForClosedStatement() to make ClosedObjectTest get the expected SQLState when the statement is closed. * Add type checking to the JDBC 4.0 length-less blob/clob overloads. * Since the type checking already checks for closed statement and invalid parameter index, remove those tests from checkSetterPreconditions(). Since the only code that is left in checkSetterPreconditions() after the removal of those checks is a call to checkForEscapedCallWithResult(), replace all calls to checkSetterPreconditions() with calls to checkForEscapedCallWithResult(). I have run derbynetclientmats with no failures. The jdbc40 suite also runs cleanly (196 failures without the patch). > Resolve difference of type compatibility between Embedded and > NetworkServer/NetworkDriver > - > > Key: DERBY-1610 > URL: http://issues.apache.org/jira/browse/DERBY-1610 > Project: Derby > Issue Type: Bug > Components: Network Server, Network Client >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > Attachments: derby-1610-jdk16.diff, DERBY-1610.diff, > DERBY-1610_2.diff, DERBY-1610_3.diff, DERBY-1610_4.diff, DERBY-1610_5.diff, > DERBY-1610_6.patch, DERBY-1610_7.patch, DERBY-1610_7_regressionfix.patch, > DERBY-1610_7_regressionfix_2.patch, DERBY-1610_7_regressionfix_2_2.patch, > DERBY-1610_7_regressionfix_2_3.patch, parameterMapping.diff, > parameterMapping.diff, > parameterMapping.diff.betweenEmbedded_and_NetworkServerNetworkClient, > parameterMapping.out.7.diff, parameterMapping.out.diff, > parameterMapping_3.diff, TestNullChar.java, TestTypeCompatibility.java, > XCL12.diff > > > There exists difference of type compatibility between Embedded and > NetworkServer/NetworkClient. > This issue tries to resolve it. -- 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: [junit] Making progess faster towards a pure Junit world
Daniel John Debrunner wrote: I'd like to make progress faster towards a pure JUnit set of tests for Derby but I believe the fact we need to setup the tests and the JUnit utility classes to run under the harness slows down progress as well as adding complications. An example of how it slows down is that any change to a test or JUnit utility class requires that the contributor runs the tests multiple ways to ensure no regressions. Assuming we had a top-level JUnit suite that ran all the Junit tests successfully (with the same configuration coverage as they are run today in derbyall) then could we switch to a dual testing environment until all the tests were converted to JUnit? This would include removing all the JUnit tests from the old harness suite files. That is if one wanted to run all the tests one would have to run: derbyall with the old harness suites.All using JUnit test runners directly. Is this an issue for people? Hi, For me this is not an issue. I might even be able to run the two in parallel by changing the port number for the JUnit run. I'm happy to see that there is activity on converting tests to JUnit. We still have a long way to go though, so keep up the good work! (BTW: I have some problems with the security manager, and if people have any ideas, I'd like to hear them; http://issues.apache.org/jira/browse/DERBY-1001) -- Kristian What about the folks that do nightly testing? Has any JUnit related work been done on the scripts used to report nightly tests. Are those scripts going to be added to Derby's svn so that others can help make progress on this issue? Thanks, Dan.
Re: [testing]-How can i run tests from source rather than jar files
Sean Qiu wrote: Hello everybody. I want to run the test from source .java files rather than from .jar So i can modify the code and get the result at once without build the project. What should i do for the purpose? Well, you will have to do _some_ building in order to test your changes, but you can avoid building the jar files every time you want to test a local change by: * removing the derby*.jar (derby.jar, derbyclient.jar, etc.) files from the classpath. * adding the trunk/classes directory to the classpath instead. However, the required jars that are not part of Derby itself (e.g. junit.jar, jakarta-oro-2.0.8.jar) must still be in the classpath. (See trunk/java/testing/readme.htm and trunk/BUILDING.txt for details). After making your changes to the source code, you can build the classes by running "ant all". Sometimes it is necessary to run "ant clobber" as well, prior to running "ant all", to remove old leftovers. If you are only making test changes, "ant testing" is often sufficient, provided that you have run "ant all" at least once before. There may be subtle differences between running tests with the class files directly and running with the jars, so I personally recommend running tests with the jar files before submitting a patch or using the code in production. -- John
[jira] Assigned: (DERBY-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=all ] Tomohito Nakayama reassigned DERBY-1942: Assignee: Tomohito Nakayama > There exists difference between behavior of setNull(Types.TIME) and > setTiime(null). > > > Key: DERBY-1942 > URL: http://issues.apache.org/jira/browse/DERBY-1942 > Project: Derby > Issue Type: Bug > Components: JDBC >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > > The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is > regarded as error. > However, the result of setTime(null) for TIMESTAMP typed variable is not > regarded as error . > see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- 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-1751) derbynet/testSecMec.java fails with ShutdownException in DerbyNetClient framework
[ http://issues.apache.org/jira/browse/DERBY-1751?page=all ] John H. Embretsen closed DERBY-1751. I have not observed any related failures lately (although I have not seen any test results from Solaris Zones platforms yet, and the platform is not available to me at the moment) so I have confidene that this issue has been fixed. I am closing the issue, thanks for resolving! > derbynet/testSecMec.java fails with ShutdownException in DerbyNetClient > framework > - > > Key: DERBY-1751 > URL: http://issues.apache.org/jira/browse/DERBY-1751 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.2.1.6 > Environment: JVM: Sun JDK 6 (build 1.6.0-rc-b95) > OS: Solaris 10 (sparc) local zones > Hardware: Sun Fire V210 Server, 2 x 1000 MHz CPU >Reporter: John H. Embretsen > Assigned To: Fernanda Pizzorno >Priority: Minor > Fix For: 10.2.2.0, 10.3.0.0 > > Attachments: derby-1751.diff, derby-1751.stat, derby-1751v2.diff, > derby.log > > > During 10.2.1.0 beta testing this test failed with > org.apache.derby.iapi.services.context.ShutdownException on 2 of 4 platforms > running Solaris zones: > Platform "sparc_zone2": > > derbynetclientmats/derbynetmats/DerbyNetClient/derbynetmats/testSecMec.diff > Platform "sparc_zone3": > > derbynetclientmats/derbynetmats/DerbyNetClient/derbynetmats/testSecMec.diff > > derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/testSecMec.diff > The test did not fail on other platforms, which may indicate timing > sensitivity (tests are run concurrently in 4 zones (1 global, 3 local) on one > single machine). Here is one of the diffs (from platform "sparc_zone2"): > * Diff file > derbynetclientmats/derbynetmats/DerbyNetClient/derbynetmats/testSecMec.diff > *** Start: testSecMec jdk1.6.0-rc DerbyNetClient derbynetmats:derbynetmats > 2006-08-14 21:31:48 *** > 308a309,312 > > java.sql.SQLException: Java exception: ': > > org.apache.derby.iapi.services.context.ShutdownException'. > > ... 14 more-- > > Testing with derby.drda.securityMechanism=INVALID_VALUE > > EXPECTED EXCEPTION DRDA_InvalidValue.U:Invalid value, INVALID_VALUE, for > > derby.drda.securityMechanism. > 310,312d313 > < Testing with derby.drda.securityMechanism=INVALID_VALUE > < EXPECTED EXCEPTION DRDA_InvalidValue.U:Invalid value, INVALID_VALUE, for > derby.drda.securityMechanism. > < - > Test Failed. > *** End: testSecMec jdk1.6.0-rc DerbyNetClient derbynetmats:derbynetmats > 2006-08-14 21:32:54 *** > The failure occurred in the DerbyNetClient framework when shutting down the > database for the second (and last) time in the method > testUSRSSBPWD_with_BUILTIN(). This test method was added August 9, 2006 > (DERBY-528). > Attatching derby.log from the failure in derbynetclientmats/derbynetmats on > sparc_zone2. -- 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-1950) Invalid 39004 message when function has primitive type parameter but null is passed into String type parameter
Invalid 39004 message when function has primitive type parameter but null is passed into String type parameter -- Key: DERBY-1950 URL: http://issues.apache.org/jira/browse/DERBY-1950 Project: Derby Issue Type: Bug Affects Versions: 10.1.3.1 Environment: N/A Reporter: Oleksandr Alesinskyy Priority: Minor create function countDelimitersBefore( str varchar(512), delimiter char(1), pos integer) returns integer language java parameter style java external name 'de.ntec.common.util.DBStringUtils.countDelimitersBefore'; select countDelimitersBefore(someColumn,'/',1) from someTable; where value of SomeColumn is NULL inappropriatly results in SQL State = 39004 SQL Code = -1 SQL Message = A NULL value cannot be passed to a method which takes a parameter of primitive type 'int'. Exception message = org.apache.derby.client.am.SqlException: A NULL value cannot be passed to a method which takes a parameter of primitive type 'int'. As far as I can see in 10.2.1.6 this bug is fixed. -- 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
