Re: [VOTE] Bryan Pendleton as a committer
Kathey Marsden [EMAIL PROTECTED] writes: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. +1 -- Knut Anders
Re: [VOTE] Bryan Pendleton as a committer
KM == Kathey Marsden [EMAIL PROTECTED] writes: KM This vote is for establishing Bryan Pendleton as a committer for Derby. +1 -- Øystein
Re: [VOTE] Bryan Pendleton as a committer
Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. +1 -- Kristian
Re: [VOTE] Bryan Pendleton as a committer
Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. +1 -- John
Re: Holistic getting started approach
Jean T. Anderson wrote: (3) It's hard to find the downloads I'm surprised by the number of requests I get which are where are the downloads? Even though downloads are on the home tab, they clearly aren't visible. So make downloads its own tab? The real estate of a web browser can accommodate only so many tabs, so we have to choose carefully. I'm hoping to free up some time soon to look more closely at each of these areas. That is somewhat surprising, yes. One alternative approach that might help (if adding a new Downloads tab is too much), is to add a Downloads section (with links to the real downloads page) high up on the main page (somewhere around News and Derby Project Charter). Those headings are among the firsts things I notice when I go to http://db.apache.org/derby/. Just a thought. -- John
Re: Features of the JUnit test execution harness
Myrna van Lunteren wrote: On 2/2/06, *Andreas Korneliussen* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I think the work currently done on DERBY-874 was mainly to improve the DerbyJUnitTest's JavaDoc, and to log exceptions. So I would not throw that away. However I do propose to change DerbyJUnitTest to move out everything about configuration into a separate class. cool. thx for the reply. I now noticed that the wiki says all suggestions are to be put on the list, so here I go rather than plopping them directly on the wiki: Great feature list. What I think is important is that we provide a common mechanism to get access to the configuration of the test. If someone then need to do some framework/version specific logic, they have a mechanism to get i.e the framework enum, and can write logic based on that. I think the following could qualify as 'more details' to the jvm, framework, version specific logic: 1. jvm-specific: 1.1. not all parameters are consistent for all jvms. Think here of jit settings / configurations, memory settings. For j2ME testing, that jvm doesn't come with a DriverManager implementation, so already from the start you know you have to go with DataSources. So I guess what you are saying is that if the test framework provides a common mechanism to give a Connection to a derby database, it should go through a DataSource, instead of using DriverManager ? 1.2. Different versions of a vendor's jvm also may have slightly different implementations resulting in slightly different behavior - e.g. of the order of rows, for instance, or rounding of certain numeric values. 1.3. Some behavior will be only supported by later versions... 2. version specific. This really falls back to the discussion on ...(can't find right now, raman's working on it, I think)... re mixed version testing. I think the conclusion was that the harness needs a way to cope with results from newer servers and clients - if they differ from results with same versions as the harness. 3. framework specific The tests needs to be able to cope with the following 3.1. different client drivers (e.g. DerbyClient, IBM Universal JDBC Driver) 3.2. server may need to be started by harness, or not 3.3. server may be on the localhost, or be running on a remote machine. certain individual tests may not be able to run in with this mechanism... 3.4 should be able to have the harness start the server in a differrent jvm. 4. one thing the current harness has no way of doing is to cope with different OSs. For instance, sometimes there are slight differences in behaviour of the same jvm version on different OSs. Like slightly different error messages (although this may be irrelevant if we're not gathering comparing output). I think the following details would be useful (in addition to the above and item 1 on the wiki): - there must be a way to skip individual tests without causing an error but with an informational message for certain configurations. eg. absence of optional jars (specifically thinking of db2jcc.jar), unsupported functionality with older jvms..., or when there is a problem that's being worked on, or that's been referred to some other organization ( e.g. in the case of jvm bugs, OS bugs...). - some way to compare runtimestatistics. Currently this is done by comparing the output, I have a hard time thinking of another mechanism. I am not sure which runtimestatistics you think of. Which output ? Output from a SQL statement ? Thanks --Andreas
[jira] Created: (DERBY-918) introduce a new test type to run junit tests from the current harness
introduce a new test type to run junit tests from the current harness - Key: DERBY-918 URL: http://issues.apache.org/jira/browse/DERBY-918 Project: Derby Type: Improvement Components: Test Environment: All Reporter: Andreas Korneliussen Assigned to: Andreas Korneliussen It seems to me that for including a new JUnit test into i.e derby-all we need to make a new java class with a main() method, which parses a command line and set up the testsuite and run it, just like any java program. Basically we are running the junit tests as test type java. Instead of having to do this for every junit test going into a derby test suite, I would propose a different strategy. I propose to introduce a new test type called junit (current test types are: sql,sql2,unit,java,multi,demo - unit is not junit) Then you can use: java org.apache.derbyTesting.functionTests.harness.RunTest TestCaseClassName.junit to run a Junit test - instead of: java org.apache.derbyTesting.functionTests.harness.RunTest AnotherClassWithMainMethod.java When starting a test of type junit, the RunTest class may simply use the junit.textui.TestRunner class, which has a main method which takes a TestCase class name as parameter. The junit.textui.TestRunner runs the tests defined by the suite() method of the TestCase class. I think this strategy will make it easier to integrate new JUnit tests into the current test suites, since it save you the trouble of creating a java class with a main method for every test. -- 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] Bryan Pendleton as a committer
+1 Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. Voting will close 5pm PST Thursday, Feb 9. Since joining the project, Bryan has submitted many high quality patches to correct several long standing, difficult DRDA protocol issues with Network Server. He has submitted fixes for: DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569 His supporting documentation of his patches has received universal high acclaim and has educated many of us in the finer points of DRDA protocol. He is an inspiration to others to write better comments and explanations of their patches. He has also reviewed many patches, answered numerous questions and provided an independent, highly qualified technical voice to the project. He will be a tremendous asset as a committer with Derby. Kathey
Re: [VOTE] Bryan Pendleton as a committer
+1 Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. Voting will close 5pm PST Thursday, Feb 9. Since joining the project, Bryan has submitted many high quality patches to correct several long standing, difficult DRDA protocol issues with Network Server. He has submitted fixes for: DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569 His supporting documentation of his patches has received universal high acclaim and has educated many of us in the finer points of DRDA protocol. He is an inspiration to others to write better comments and explanations of their patches. He has also reviewed many patches, answered numerous questions and provided an independent, highly qualified technical voice to the project. He will be a tremendous asset as a committer with Derby. Kathey -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
[jira] Updated: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
[ http://issues.apache.org/jira/browse/DERBY-856?page=all ] V.Narayanan updated DERBY-856: -- Attachment: setCharacterStreamInternal_3.diff Hi, 1) I have made the changes and am reattaching the patch again. 2) I ran derbyall and noticed failures. I noticed a failure in jdbcapi/LobTest.java. So I ran derbyall on a workspace on which I had'nt applied this patch and I observed the same failure. I then concluded that this failure was not due to me applying my patch. 3) I am attaching the diff file setCharacterStreamInternal_3.diff as the new diff file. thanx Narayanan modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat, setCharacterStreamInternal_3.diff A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. -- 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-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
[ http://issues.apache.org/jira/browse/DERBY-856?page=all ] V.Narayanan updated DERBY-856: -- Attachment: LOBTest.diff Hi, I am also attaching the LobTests.diff (The diff file of the failed test jdbcapi/LobTest.java) as part of the patch submission. thanx Narayanan modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: LOBTest.diff, setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat, setCharacterStreamInternal_3.diff A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. -- 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-821) Client driver: Implicitly close exhausted result sets on the server
[ http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12365076 ] Philip Wilder commented on DERBY-821: - Thank you for the clarification Knut. I apologize for my misinterpretation. Keep up the good work :-) Client driver: Implicitly close exhausted result sets on the server --- Key: DERBY-821 URL: http://issues.apache.org/jira/browse/DERBY-821 Project: Derby Type: Improvement Components: Network Client, Network Server, Performance Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-821.diff, DERBY-821.stat, changes-no-object-tags.html, changes.html Forward-only result sets that are exhausted should be implicitly closed on the server. This way, ResultSet.close() does not have to send an explicit close message generating unnecessary network traffic. The DRDA protocol supports this. From the description of OPNQRY (open query): The qryclsimp parameter controls whether the target server implicitly closes a non-scrollable query upon end of data (SQLSTATE 02000) in association with the cursor type. -- 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: DerbyDB truncates the values inserted in a numeric field instead of approximating them
Hi Jacopo, Jacopo == Jacopo Cappellato [EMAIL PROTECTED] wrote: Jacopo Is there a way to configure the way approximations are done? Is it Jacopo something that should be fixed? I checked the SQL specification and it says that whether rounding or truncation is used is implementation defined, so Derby is SQL compliant when it chooses to do truncation. I guess if you want to use different data base back-ends, your milage might vary in any case, so it could be advisable to handle this in process in the application (not assuming anything about how the db handles this). Dag Jacopo Jacopo Hi all, Jacopo my name is Jacopo Cappellato, I'm one of the developers of the OFBiz Jacopo project (www.ofbiz.org), that will soon start the incubation process. Jacopo Jacopo OFBiz is using DerbyDb as the default db and it works pretty well even Jacopo if we have found some minor issues. Jacopo Jacopo One of these is the way numbers are approximated when inserted in Jacopo numeric fields. Jacopo Jacopo Namely, DerbyDB truncates the values inserted in a numeric field instead Jacopo of approximating them Jacopo (http://db.apache.org/derby/docs/10.0/manuals/reference/sqlj132.html). Jacopo Jacopo Since the general approach in OFBiz is that of using db approximations Jacopo (instead of doing them in the code), this is not a good thing because Jacopo other databases (e.g. MaxDB/SapDB) perform approximations instead of Jacopo truncations in the same situations. Jacopo Jacopo So switching from DerbyDB to another one could lead to different Jacopo calculations. Jacopo Jacopo Is there a way to configure the way approximations are done? Is it Jacopo something that should be fixed? Jacopo Jacopo Thanks, Jacopo Jacopo Jacopo Jacopo -- Dag H. Wanvik Sun Microsystems, Database Technology Group (DBTG) Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43496/+47 73842196, Fax: +47 73842101
Re: [VOTE] Bryan Pendleton as a committer
Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. +1 -- Ole Solberg, Database Technology Group, Sun Microsystems, Trondheim, Norway
Re: DerbyDB truncates the values inserted in a numeric field instead of approximating them
Jacopo Cappellato wrote: Hi all, my name is Jacopo Cappellato, I'm one of the developers of the OFBiz project (www.ofbiz.org), that will soon start the incubation process. Welcome, I've watching the vote on the incubator list. OFBiz is using DerbyDb as the default db and it works pretty well even if we have found some minor issues. That's great, please inform this list of any issues with Derby as you find them. One of these is the way numbers are approximated when inserted in numeric fields. Namely, DerbyDB truncates the values inserted in a numeric field instead of approximating them (http://db.apache.org/derby/docs/10.0/manuals/reference/sqlj132.html). Since the general approach in OFBiz is that of using db approximations (instead of doing them in the code), this is not a good thing because other databases (e.g. MaxDB/SapDB) perform approximations instead of truncations in the same situations. DECIMAL are exact numeric types, which means they do not approximate values or calculations. They are designed for financial and scientific applications where exact calculations are required. You don't want your bank approximating the addition of your pay check into your existing balance. :-) MySQL's DECIMAL implementation has always been wrong and they have finally fixed it in version 5. Since OFBiz is a business application suite/framework, what sort of ERP, CRM, E-Business / E-Commerce, etc. requires approximations? Seems like a set of applications that require exactness. So switching from DerbyDB to another one could lead to different calculations. Switching from Derby to databases that handle DECIMAL's incorrectly can lead to different calculations. My advice, don't switch to those broken databases. :-) Is there a way to configure the way approximations are done? Is it something that should be fixed? No it should not be fixed. Note that MySQL has fixed their broken DECIMAL implementation in version 5.0. I never understood how people could be using MySQL and DECIMAL, I hope no banks were. If you want approximate numeric values, then REAL and DOUBLE are the SQL datatypes you require. Dan.
[jira] Resolved: (DERBY-891) derby_tests.policy file contains references to csinfo and db2j - should get cleaned up
[ http://issues.apache.org/jira/browse/DERBY-891?page=all ] Daniel John Debrunner resolved DERBY-891: - Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 374683 - thanks for the patch derby_tests.policy file contains references to csinfo and db2j - should get cleaned up -- Key: DERBY-891 URL: http://issues.apache.org/jira/browse/DERBY-891 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Myrna van Lunteren Assignee: Myrna van Lunteren Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-891_013106.diff, DERBY-891_013106.stat, DERBY-891_020206.diff, DERBY-891_020206.stat The derby_tests.policy file uses references to csinfo and db2j. These are left-overs from pre-contribution and rename to apache and should get cleaned up. I suspect that the db2j references can simply be taken out, but that should get double-checked. The csinfo references are used in jvm.java. There referenced in the testing/README.htm. I propose to change the name of these properties as follows: csinfo.codejar - URL to the jar files when they are in the classpath change to derby.codejar csinfo.codeclasses - URL to the classes directory when it is in the classpath change to derby.codeclasses csinfo.codedir - File location of either csinfo.codejar or csinfo.codejar. the comment said : // Only required due to a BUG. Need to figure out which 'BUG' that is and document better change to derby.codedir csinfo.trustedhost change to derby.clienthost document: - specifies the clients ip address/hostName. csinfo.serverhost change to derby.serverhost document: -Host name or ip where network server is started. -- 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: DerbyDB truncates the values inserted in a numeric field instead of approximating them
Daniel, Dag, thanks for your answers: they are really helpful. Well, right now we are now using NUMERIC(18,2) field types for currency amount fields... so that values are stored in the db with the exact number of decimal we need (0k, we are actually in the process of reviewing this approach). Do you think we should use a different field type? (e.g. DECIMAL) Again, thanks, Jacopo Daniel John Debrunner wrote: Jacopo Cappellato wrote: Hi all, my name is Jacopo Cappellato, I'm one of the developers of the OFBiz project (www.ofbiz.org), that will soon start the incubation process. Welcome, I've watching the vote on the incubator list. OFBiz is using DerbyDb as the default db and it works pretty well even if we have found some minor issues. That's great, please inform this list of any issues with Derby as you find them. One of these is the way numbers are approximated when inserted in numeric fields. Namely, DerbyDB truncates the values inserted in a numeric field instead of approximating them (http://db.apache.org/derby/docs/10.0/manuals/reference/sqlj132.html). Since the general approach in OFBiz is that of using db approximations (instead of doing them in the code), this is not a good thing because other databases (e.g. MaxDB/SapDB) perform approximations instead of truncations in the same situations. DECIMAL are exact numeric types, which means they do not approximate values or calculations. They are designed for financial and scientific applications where exact calculations are required. You don't want your bank approximating the addition of your pay check into your existing balance. :-) MySQL's DECIMAL implementation has always been wrong and they have finally fixed it in version 5. Since OFBiz is a business application suite/framework, what sort of ERP, CRM, E-Business / E-Commerce, etc. requires approximations? Seems like a set of applications that require exactness. So switching from DerbyDB to another one could lead to different calculations. Switching from Derby to databases that handle DECIMAL's incorrectly can lead to different calculations. My advice, don't switch to those broken databases. :-) Is there a way to configure the way approximations are done? Is it something that should be fixed? No it should not be fixed. Note that MySQL has fixed their broken DECIMAL implementation in version 5.0. I never understood how people could be using MySQL and DECIMAL, I hope no banks were. If you want approximate numeric values, then REAL and DOUBLE are the SQL datatypes you require. Dan.
Re: DerbyDB truncates the values inserted in a numeric field instead of approximating them
Jacopo Cappellato wrote: Daniel, Dag, thanks for your answers: they are really helpful. Well, right now we are now using NUMERIC(18,2) field types for currency amount fields... so that values are stored in the db with the exact number of decimal we need (0k, we are actually in the process of reviewing this approach). Do you think we should use a different field type? (e.g. DECIMAL) DECIMAL and NUMERIC are the same in Derby. So it looks like you are using the correct type. One option is to increase the scale of the number (digits after the decimal point), e.g. NUMERIC(20,4) which would then hold two extra digits that would be lost in the assignment to NUMERIC(18.2). Maybe this is what you meant by approximation, the ability to control the rounding as Dag said? Dan. [ The SQL standard allows DECIMAL (I think) to have greater precision than defined while NUMERIC must match its defined precision. ]
Re: DerbyDB truncates the values inserted in a numeric field instead of approximating them
Daniel, Daniel John Debrunner wrote: DECIMAL and NUMERIC are the same in Derby. So it looks like you are using the correct type. One option is to increase the scale of the number (digits after the decimal point), e.g. NUMERIC(20,4) which would then hold two extra digits that would be lost in the assignment to NUMERIC(18.2). Maybe this is what you meant by approximation, the ability to control the rounding as Dag said? Yes, exactly (and sorry for my bad English). Right now, we are not using (in general) the NUMERIC(20,4) approach to avoid having to deal with amount rounding in the code... just leaving to the db this task. But in order to do this correctly with all the dbs we need to control the rounding algorithm of the db. If, as pointed out by Dag, this is not covered by the SQL spec, we'll have to cahnge this approach. Regards, Jacopo Dan. [ The SQL standard allows DECIMAL (I think) to have greater precision than defined while NUMERIC must match its defined precision. ]
[jira] Resolved: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
[ http://issues.apache.org/jira/browse/DERBY-856?page=all ] Daniel John Debrunner resolved DERBY-856: - Resolution: Fixed Committed revision 374696. Thanks for the patch modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: LOBTest.diff, setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat, setCharacterStreamInternal_3.diff A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. -- 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: Features of the JUnit test execution harness
So I guess what you are saying is that if the test framework provides a common mechanism to give a Connection to a derby database, it should go through a DataSource, instead of using DriverManager ? I think we will need both mechanisms to get connection - using DataSource and DriverManager. J2ME/CDC/Foundation Profile is based on JSR169 for JDBC, which does not have java.sql.DriverManager class. So, here we need a mechanism to get a connection using javax.sql.DataSource. Using DataSource to get connection will not work in case of j9 vms (not foundation profile). In this case, database_enabler.jar is used for JDBC support and this does not have javax.sql.DataSource class. I'd appreciate if someone else familiar in this area can confirm this. Thanks, Deepa
Re: Features of the JUnit test execution harness
Deepa Remesh wrote: So I guess what you are saying is that if the test framework provides a common mechanism to give a Connection to a derby database, it should go through a DataSource, instead of using DriverManager ? I think we will need both mechanisms to get connection - using DataSource and DriverManager. J2ME/CDC/Foundation Profile is based on JSR169 for JDBC, which does not have java.sql.DriverManager class. So, here we need a mechanism to get a connection using javax.sql.DataSource. Using DataSource to get connection will not work in case of j9 vms (not foundation profile). In this case, database_enabler.jar is used for JDBC support and this does not have javax.sql.DataSource class. I'd appreciate if someone else familiar in this area can confirm this. Correct, the other j9 profile is implementing the standard JDBC 2.1 api and does not supply the optional JDBC 2.0 extensions which include DataSource etc. Derby currently does support this environment and so the test harness needs to as well. In addition we will need to test getting connections from DriverManager, so it needs to be supported in some way. Ideally the majority of tests should be written to be indepedent of how a connection is obtained, which is how it is today. Then all of the tests could be run with a conneciton from a DataSource, the DriverManager, a Driver, a PooledConnection or a XAConnection. Dan.
Re: Holistic getting started approach
John Embretsen wrote: Jean T. Anderson wrote: (3) It's hard to find the downloads I'm surprised by the number of requests I get which are where are the downloads? Even though downloads are on the home tab, they clearly aren't visible. So make downloads its own tab? The real estate of a web browser can accommodate only so many tabs, so we have to choose carefully. I'm hoping to free up some time soon to look more closely at each of these areas. That is somewhat surprising, yes. One alternative approach that might help (if adding a new Downloads tab is too much), is to add a Downloads section (with links to the real downloads page) high up on the main page (somewhere around News and Derby Project Charter). Those headings are among the firsts things I notice when I go to http://db.apache.org/derby/. Just a thought. That home page is another thing that could use serious redesign, :-) something simpler that links to the charter. Torque has a home page that provides a synopsis and a link to the most current release: http://db.apache.org/torque/ . (Moving that up after their What is Torque? section would make it instantly visible.) And I like the way JDO has the news on the home page (http://db.apache.org/jdo/). So maybe a revamped Derby home page could have something like: What is Derby? (brief description and link to charter) Downloads News -jean
[jira] Created: (DERBY-920) small delta's to replace cloudscape etc with derby in comments/code
small delta's to replace cloudscape etc with derby in comments/code --- Key: DERBY-920 URL: http://issues.apache.org/jira/browse/DERBY-920 Project: Derby Type: Task Environment: N/A Reporter: scott hutinger Priority: Trivial Smaller delta's to modify older source code comments which in some cases should be updated. Many cases older owners of the source should be kept intact, as it refers to past or future tenses in a context where changes are not needed/wanted. Smaller delta's so this might happen some day :-) -- 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-920) small delta's to replace cloudscape etc with derby in comments/code
[ http://issues.apache.org/jira/browse/DERBY-920?page=all ] scott hutinger updated DERBY-920: - Attachment: sysinfo-main.diff.gz A bit larger delta, mainly for sysinfo/main.java, but has a couple build.xml files also. This shouldn't get in the way of real modifications of the code. small delta's to replace cloudscape etc with derby in comments/code --- Key: DERBY-920 URL: http://issues.apache.org/jira/browse/DERBY-920 Project: Derby Type: Task Environment: N/A Reporter: scott hutinger Priority: Trivial Attachments: sysinfo-main.diff.gz Smaller delta's to modify older source code comments which in some cases should be updated. Many cases older owners of the source should be kept intact, as it refers to past or future tenses in a context where changes are not needed/wanted. Smaller delta's so this might happen some day :-) -- 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-898) setAutoCommit(false) is not working properly for local connection with ClientXADataSource
[ http://issues.apache.org/jira/browse/DERBY-898?page=all ]
Kathey Marsden updated DERBY-898:
-
Attachment: DERBY-898.diff
DERBY-898 setAutoCommit(false) is not working properly with connections
objtained with ClientXADataSource.
The problem in this case was that the server side connection was set to
autocommit true. Even when the client has autocommit on, the server side
connection should be autocommit false and let the client drive the commits.
- Changes server side connection for network server XA to autocommit false.
- Adds connections obtained from an XADataSource to the savepointJdbc30 test to
verify that autocommit is being set properly and also verify that DERBY-899 (a
dup of this issue) is fixed.
I will commit to 10.1 later today.
setAutoCommit(false) is not working properly for local connection with
ClientXADataSource
-
Key: DERBY-898
URL: http://issues.apache.org/jira/browse/DERBY-898
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.1.0, 10.1.1.1
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Priority: Critical
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3
Attachments: DERBY-898.diff
Network Server is not honoring local
transaction rollback using ClientXADataSource. Run the following standalone
JDBC code.
The output shows that after rolling back the local transaction,
the inserted data is still present.
final org.apache.derby.jdbc.ClientXADataSource ds =
new org.apache.derby.jdbc.ClientXADataSource();
ds.setServerName(localhost);
ds.setPortNumber(1527);
ds.setDatabaseName(WOMBAT);
ds.setTraceLevel(-1);
ds.setSecurityMechanism(ds.CLEAR_TEXT_PASSWORD_SECURITY);
ds.setUser(dbuser1);
ds.setPassword(dbpwd1);
//ds.setLogWriter(new
java.io.PrintWriter(System.out));
XAConnection xaConn = ds.getXAConnection();
Connection conn = xaConn.getConnection();
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_R
EAD);
conn.setAutoCommit(true);
System.out.println(Database product: +
conn.getMetaData().getDatabaseProductName());
System.out.println(Database version: +
conn.getMetaData().getDatabaseProductVersion());
System.out.println(Driver name: +
conn.getMetaData().getDriverName());
System.out.println(Driver version:+
conn.getMetaData().getDriverVersion());
Statement stmt = conn.createStatement();
try { stmt.execute(drop table cmtest); }
catch (SQLException sqlX) {} // ok, didn't exist
stmt.execute(CREATE TABLE cmtest (id integer not null
primary key, name varchar(60)));
stmt.close();
conn.setAutoCommit(false);
PreparedStatement pstmt = conn.prepareStatement(
INSERT INTO cmtest (id, name) VALUES(?,?),
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
pstmt.setInt(1, 13);
pstmt.setString(2, blah1);
pstmt.executeUpdate();
pstmt.setInt(1, 2);
pstmt.setString(2, blah2);
pstmt.executeUpdate();
conn.rollback();
PreparedStatement pstmt2 = conn.prepareStatement(
SELECT * FROM cmtest WHERE id = ?,
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
pstmt2.setInt(1, 13);
ResultSet rset = pstmt2.executeQuery();
if (rset.next())
{
System.out.println(Test fails. First insert was
not rolled back.);
System.out.println(The data is still present. It
is: + rset.getObject(1) +
, + rset.getObject(2));
}
else
System.out.println(Test passes. First insert was
rolled back.);
Here's the output,
Database product: Apache Derby
Database version: 10.1.2.2
Driver name: Apache Derby Network Client JDBC Driver
Driver version: 10.1.2.2
Test fails. First insert was not rolled back.
The data is still present. It is: 13, blah1
On some brief investigation I see that the Network Server embedded connection
is in autocomit mode so is autocommitting the transaction before the
rollback. Network server should always have autocommit false and let the
client drive the commit.
--
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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365094 ] Eric Radzinski commented on DERBY-761: -- If somebody can provide a complete list of reserved words, I'll update the reference guide. The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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: javadoc errors
Thanks, Kathey. I synced and picked up your fixes. There was an outstanding javadoc problem in SystemProcedures.java, which I have just scrubbed and committed. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: I just synced an empty client with the mainline. When I run ant derbydocs I don't see the errors you're seeing. However, I see the following new javadoc warnings: [javadoc] C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:59: warning - @return tag has no arguments. [snip] I will fix.
Re: javadoc errors
Rick Hillegas wrote: Thanks, Kathey. I synced and picked up your fixes. There was an outstanding javadoc problem in SystemProcedures.java, which I have just scrubbed and committed. Thanks Rick. What do you run to scrub the javadoc?
Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue
You are seeing the same results as Oystein reported as part of DERBY-799. If no one submits a patch for DERBY-799 I will probably submit something simple before the next candidate release is cut. Something on the order of sleeping in between I/O's to stop checkpoint from flooding I/O. Kristian Waagan wrote: Mike Matrigali wrote: Long answer above, some comments inline below. I think runtime performance would be optimal in this case, runtime performance is in no way helped by having checkpoints - only either not affected or hindered. As has been noted checkpoints can cause drastic downward spikes in some disk bound applications, hopefully we will some changes into 10.2 to smooth those spikes down. But the reality is the more checkpoints on a system that is disk i/o bound the more the app is going to slow down, if you are not disk i/o bound then the checkpoints may have little affect. Thank you for the explanations Mike. I run a TPC-B like load against Derby and plotted some performance metrics for two different configurations; one where the default checkpointing interval was used, and one where it was set to maximum. I ran for 1 hour, and for the second case, I don't think a checkpoint was started (the test took a long time to exit when the database was shut down, as almost 100 MB of log had to be handled). Please have a look at the attached figures, and see if they are as you expected. Yes TPC-B on a fast/multi-processor machine is probably the worst case scenario for the current default checkpoint settings. The default aims more at typical xact throughput apps rather than extreme highen as you are measuring. The hope was that anyone trying to run such extreme app would be able to set the checkpoint interval to a reasonable setting. Discussion on the list and the above bug continues about ways to avoid the spikes. The amount of log probably was not much of a factor for shutdown speed. Assuming you were doing a clean shutdown, I expect the time was just waiting for all the pages in the cache to go to disk and be sync'd. What bothers me in particular, are the spikes for the run with default checkpointing interval. As you can see, the throughput drops to (nearly) zero for 10 second periods, which is pretty bad. The checkpoint should not interfere with user activity in such a way. I have talked to some people about this, and we suspect there might be some kind of OS/filesystem issue that we're running into. This might be caused by the way the checkpoint writes pages to disk - write all dirty pages to disk, then sync at the very end. Depending on the underlying OS/filesystem/caches, the effects may vary. My runs were done on Solaris with the UFS filesystem. I also attatched a second graph where I used directio (option 'forcedirectio' when mounting). I believe there was some info posted onto the list about previous analysis about what was causing the 10 second drops. I seem to remember it was even somewhat jvm specific. Unfortunately I do not have logs for disk io activity for these runs. The data and logs were stored on different physical disks (used 'logDevice'). The database was approx 17 GB, the page cache 0.5 GB. Embedded Derby, 16 clients/connections. with any performance analysis the following kinds of info is interesting: o sysinfo ouput (gets jvm, version, and some other stuff) o description of machine (mostly I look for #processors and speed/type of processors) o description of disks (scsi vs ide, is write cache enabled?, are multiple disks raided to look like one disk to derby?) Any comments on the graphs attached? -- Kristian There are only 2 reasons for checkpoints: 1) decrease recovery time after a system crash. 2) make it possible to delete log file information (if you don't have rollforward recovery backups). Without a checkpoint derby must keep all log files, thus space needed in the log directory will always grow. The background writer thread should handle this, it should not consider this an extreme case. If there were no background writer and no checkpoints then the following would happen: 1) the page cache grows to whatever maximum size it has gotten to 2) requests for a new page then use clock to determine what page to throw out. 3) if the page picked to throw out is dirty, then it is first written to the OS with no sync requested. It is up to the OS whether this is handled async or not. Most modern OS's will make this be an async operation unless the OS cache is full and then it will turn into a wait for some i/o (maybe some other i/o to free OS resource). The downside is that a user select at this point may end up waiting on a synchronous write of some page. 4) if the page to throw out is not dirty, then it can just be thrown out without any possible I/O wait. 5) In both cases 3 and 4 the user thread of course has to wait on the I/O to read the page into the cache. Depending on the OS cache this may
[jira] Updated: (DERBY-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=all ] Eric Radzinski updated DERBY-570: - Attachment: derby570.diff rrefsqlj30118.html The attached patch adds the requested line ot the LONG VARCHAR FOR BIT DATA topic. HTML file is included for review. wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570.diff, rrefsqlj30118.html The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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] Bryan Pendleton as a committer
+1 Kathey Marsden wrote: This vote is for establishing Bryan Pendleton as a committer for Derby. Please vote +1 if you approve of Bryan as a committer. Voting will close 5pm PST Thursday, Feb 9. Since joining the project, Bryan has submitted many high quality patches to correct several long standing, difficult DRDA protocol issues with Network Server. He has submitted fixes for: DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569 His supporting documentation of his patches has received universal high acclaim and has educated many of us in the finer points of DRDA protocol. He is an inspiration to others to write better comments and explanations of their patches. He has also reviewed many patches, answered numerous questions and provided an independent, highly qualified technical voice to the project. He will be a tremendous asset as a committer with Derby. Kathey
Re: Features of the JUnit test execution harness
Deepa Remesh wrote: So I guess what you are saying is that if the test framework provides a common mechanism to give a Connection to a derby database, it should go through a DataSource, instead of using DriverManager ? I think we will need both mechanisms to get connection - using DataSource and DriverManager. J2ME/CDC/Foundation Profile is based on JSR169 for JDBC, which does not have java.sql.DriverManager class. So, here we need a mechanism to get a connection using javax.sql.DataSource. Using DataSource to get connection will not work in case of j9 vms (not foundation profile). In this case, database_enabler.jar is used for JDBC support and this does not have javax.sql.DataSource class. I'd appreciate if someone else familiar in this area can confirm this. Thanks, Deepa I'm not familiar with this area, but wouldn't it in general be best to have a single method in the harness that returns a valid connection? If the test is running in a J2ME/CDC/Foundation environment, it uses DataSource to get a connection, if it is in a j9 environment then it should use whatever is supported there. For most tests, how the connection is obtained is irrelevant, as long as it works! I see that a few tests, for instance a test that is testing the different ways to get connections, would have the need to override such a standard method, but that's something that can be added when these tests are to be written in JUnit-style. However, depending on JVM and (un)available jars, some of the test cases in such a suite would have to be skipped anyway. Instead of learning the harness how to get connections in X different ways, I would consider just extracting the required connection information (driver/framework prefix, database name, server, port etc) from the harness and then code how I get the connection in my test *if this is required*. The harness should only have to know about a minimal set of ways to get connections. With minimal set, I mean it has to know about one way to get a connection for all jvms/platforms (that we support or have the itch for). It does not need to know all the ways for all jvms/platforms. From the previous mails, the harness would have to know how to use DataSource and DriverManager. Are there jvms/platforms where neither of these will be able to produce a connection? -- Kristian
[jira] Commented: (DERBY-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=comments#action_12365100 ] Daniel John Debrunner commented on DERBY-570: - I think the layout of the LONG VARCHAR FOR BIT DATA should match the other types, for example see LONG VARCHAR http://db.apache.org/derby/docs/10.1/ref/rrefsqlj15147.html See the syntax, Java type and JDBC type are sections with bold headings. The compile time type for LONG VARCHAR FOR BIT DATA would be byte[] wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570.diff, rrefsqlj30118.html The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365102 ] Mamta A. Satoor commented on DERBY-761: --- I looked at sqlgrammar.jj and found following set of keywords that are missing from the docs 1)BINARY 2)CHARACTER_LENGTH 3)COALESCE 4)D 5)_DEFAULT 6)LOWER 7)MODULE 8)T 9)TS 10)VALUE 11)VARBINARY Following should be removed from the reserved keywords list from the doc 1)INOUT 2)NVARCHAR 3)OUT 4)TRAILING The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
I'm not sure I understand this logic. Shouldn't we be providing useful error messages with enough detail as possible? Standard error messages may be reusable, but they may not be helpful. Are there space concerns? David Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12365037 ] Daniel John Debrunner commented on DERBY-856: - Patch looks good, I don't agree the error message has to change, it's the standard Derby error message for the correct situation. We shouls not be adding special error messages for one off situations. modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: javadoc errors
Hi Kathey, Nothing up my sleeve here. I'm just invoking ant derbydocs and hand editting the source code. Would be interested in advice on tools which we could use to fix simple cut-and-paste errors (like leaving @return tags on void methods). Would also be interested in tools we could wire into derbyall to force us to clean up our headers before checkin. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: Thanks, Kathey. I synced and picked up your fixes. There was an outstanding javadoc problem in SystemProcedures.java, which I have just scrubbed and committed. Thanks Rick. What do you run to scrub the javadoc?
[jira] Updated: (DERBY-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Eric Radzinski updated DERBY-761: - Attachment: derby761.diff rrefkeywords29722.html attached patch addresses derby-761. HTML file is included for review. The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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] Updated: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
Thanks, Narayanan, I'll take a look at this. The LobTest failure was a result of my checkin try and fix some jdk13 test regressions. In the process I broke LobTest for jdk14. I just checked in a fix, let me know if that works for you. Rather than spending the time to run a test in your own clean sandbox, you can always check the test results from the regression test run or the tinderbox test runs found at http://www.multinet.no/~solberg/public/Apache/index.html and http://people.apache.org/~fuzzylogic/derby_test_results/ David V.Narayanan (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-856?page=all ] V.Narayanan updated DERBY-856: -- Attachment: setCharacterStreamInternal_3.diff Hi, 1) I have made the changes and am reattaching the patch again. 2) I ran derbyall and noticed failures. I noticed a failure in jdbcapi/LobTest.java. So I ran derbyall on a workspace on which I had'nt applied this patch and I observed the same failure. I then concluded that this failure was not due to me applying my patch. 3) I am attaching the diff file setCharacterStreamInternal_3.diff as the new diff file. thanx Narayanan modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method -- Key: DERBY-856 URL: http://issues.apache.org/jira/browse/DERBY-856 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Environment: All Environments Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat, setCharacterStreamInternal_3.diff A similar change to setBinaryStreamInternal is being handled as part of DERBY-599. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: javadoc errors
Rick Hillegas wrote: Hi Kathey, Nothing up my sleeve here. I'm just invoking ant derbydocs and hand editting the source code. Would be interested in advice on tools which we could use to fix simple cut-and-paste errors (like leaving @return tags on void methods). Would also be interested in tools we could wire into derbyall to force us to clean up our headers before checkin. So you fixed all those javadoc warnings by hand ? I thought you must have had a tool. You are amazing! Thank you so much Rick. Kathey
Re: [jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
David W. Van Couvering wrote: I'm not sure I understand this logic. Shouldn't we be providing useful error messages with enough detail as possible? Standard error messages may be reusable, but they may not be helpful. Are there space concerns? Space concern is one factor. The other is that approaching this on an ad-hoc basis doesn't seem the best approach to me. Will lead to lots of different messages written by different people that really are describing the same situation. For example with your proposed fix would would have had a message just for CLOB that really isn't in line with the style of the other messages. Why not address it for BLOB as well, what about other data types, what about the corresponding client message? I've seen this before, the data type messages used to each print the type in their own way, much as the text of your message proposed. Thus we had no consistency, Clob vs. CLOB, DOUBLE vs. DOUBLE PRECISION vs double, DECIMAL vs NUMERIC vs. DECIMAL/NUMERIC. I'm sure we could write better error messages, but let's make a consistent effort around that, not little fixups in unrelated patches. If the standard message for value out of range is confusing, what could be done to improve it for all cases? Dan.
Re: nightly regression in jdk15 procedure, LOBtest, and parameterMapping
I just submitted a change that should solve this. I have run the tests on jdk14 and jdk13. I'll also run under jdk15 just to make sure, but based on Deepa's comments what I did should have solved the problem. David Mike Matrigali wrote: In last night's run of nightly regression tests I saw the following 3 errors. I haven't had time to track it down, but it seems likely that David's fixes for these tests under jdk131 have not broken them for jdk15: jdk15 derbyall derbyall: 3 failures derbyall/derbynetclientmats/derbynetmats.fail:lang/procedure.java derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/LOBTest.java derbyall/derbynetclientmats/derbynetmats.fail:jdbcapi/parameterMapping.java Let me know if I should open new JIRA's or if just reopening the orignal ones is appropriate. In the following environment: Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.5.0_02 Java Vendor: Sun Microsystems Inc. Java home: E:\jartest\jdk15\jre Java classpath: e:/jartest/classes/derby.jar;e:/jartest/classes/derbyLocale_zh_TW.jar;e:/jartest/classes/derbyLocale_zh_CN.jar;e:/jartest/classes/derbyLocale_pt_BR.jar;e:/jartest/classes/derbyLocale_ko_KR.jar;e:/jartest/classes/derbyLocale_ja_JP.jar;e:/jartest/classes/derbyLocale_it.jar;e:/jartest/classes/derbyLocale_fr.jar;e:/jartest/classes/derbyLocale_es.jar;e:/jartest/classes/derbyLocale_de_DE.jar;e:/jartest/classes/derbytools.jar;e:/jartest/classes/derbynet.jar;e:/jartest/classes/derbyclient.jar;;e:/jartest/classes/derbyTesting.jar;e:/jartest/classes/maps.jar;e:/jartest/classes/functionTests.jar;e:/jartest/tools/java/junit.jar;e:/jartest/tools/java/jndi/fscontext.jar;e:/jartest/tools/java/RmiJdbc.jar;e:/jartest/drda/jcc/2.4/db2jcc.jar;e:/jartest/drda/jcc/2.4/db2jcc_license_c.jar OS name: Windows 2000 OS architecture: x86 OS version: 5.0 Java user name: cloudtst Java user home: C:\WINNT\Profiles\cloudtst Java user dir: E:\jartest\JarResults.2006-02-02\jdk15_derbyall java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [E:\jartest\classes\derby.jar] 10.2.0.0 alpha - (374572) [E:\jartest\classes\derbytools.jar] 10.2.0.0 alpha - (374572) [E:\jartest\classes\derbynet.jar] 10.2.0.0 alpha - (374572) [E:\jartest\classes\derbyclient.jar] 10.2.0.0 alpha - (374572) [E:\jartest\drda\jcc\2.4\db2jcc.jar] 2.4 - (17) [E:\jartest\drda\jcc\2.4\db2jcc_license_c.jar] 2.4 - (17) Here are the diffs: *** Start: procedure jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-02-03 03:21:03 *** 274 del EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of 10243.. See attached Throwable. Caused by exception class org.apache.derby.client.am.ConversionException: [converters] Overflow occurred during numeric data type conversion of 10243. 274a274 EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of 10243.. See attached Throwable. 355 del EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of 102.33.. See attached Throwable. Caused by exception class org.apache.derby.client.am.ConversionException: [converters] Overflow occurred during numeric data type conversion of 102.33. 355a355 EXPECTED SQL Exception: BigDecimal conversion exception [converters] Overflow occurred during numeric data type conversion of 102.33.. See attached Throwable. Test Failed. *** End: procedure jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-02-03 03:22:49 *** *** Start: LOBTest jdk1.5.0_02 DerbyNetClient derbynetmats:jdbcapi 2006-02-03 03:56:45 *** 48 del 1 getDate -EXCEPTION (Invalid data conversion: Parameter instance 101is invalid for requested conversion to java.sql.Date. Caused by exception class java.lang.IllegalArgumentException: null) 48a48 1 getDate -EXCEPTION (Invalid data conversion: Parameter instance 101is invalid for requested conversion to java.sql.Date.) 56 del 1 getTime -EXCEPTION (Invalid data conversion: Parameter instance 101is invalid for requested conversion to java.sql.Time. Caused by exception class java.lang.IllegalArgumentException: null) 57 del 1 getTimeStamp -EXCEPTION (Invalid data conversion: Parameter instance 101is invalid for requested conversion to java.sql.Timestamp. Caused by exception class java.lang.IllegalArgumentException: Timestamp format must be -mm-dd hh:mm:ss.f) 57a56,57 1 getTime -EXCEPTION (Invalid data conversion: Parameter instance 101is invalid for requested conversion to java.sql.Time.)
[jira] Commented: (DERBY-761) The reserved words list in the reference manual doesn't look uptodate
[
http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365110 ]
Mamta A. Satoor commented on DERBY-761:
---
I am glad you are looking at the list too. I was surprised to see D and T in
the TOKEN reserved words list. Here is what I see in sqlgrammar.jj
/*
This list should contain only and all SQL92 keywords that are reserved.
Reserved keywords can be used as identifiers in the language only
as delimited identifiers.
*/
/* NOTE - If you add a keyword, then you must add it to reservedKeyword()
*or nonReservedKeyword() as well!
*/
TOKEN [IGNORE_CASE] :
{ /* SQL92 reserved Keywords */
ADD: add
| ALL: all
| ALLOCATE: allocate
| ALTER: alter
| AND: and
| ANY: any
| ARE: are
| AS: as
| ASC: asc
| ASSERTION: assertion
| AT: at
| AUTHORIZATION: authorization
| AVG: avg
| BEGIN: begin
| BETWEEN: between
| BINARY: binary
| BIT: bit
| BOTH: both
| BY: by
| CASCADE: cascade
| CASCADED: cascaded
| CASE: case
| CAST: cast
| CHAR: char
| CHARACTER: character
| CHARACTER_LENGTH: character_length
| CHECK: check
| CLOSE: close
| COALESCE: coalesce
| COLLATE: collate
| COLLATION: collation
| COLUMN: column
| COMMIT: commit
| CONNECT: connect
| CONNECTION: connection
| CONSTRAINT: constraint
| CONSTRAINTS: constraints
| CONTINUE: continue
| CONVERT: convert
| CORRESPONDING: corresponding
| COUNT: count
| CREATE: create
| CURRENT: current
| CURRENT_DATE: current_date
| CURRENT_TIME: current_time
| CURRENT_TIMESTAMP: current_timestamp
| CURRENT_USER: current_user
| CURSOR: cursor
| D: d
| DEALLOCATE: deallocate
| DEC: dec
| DECIMAL: decimal
| DECLARE: declare
| _DEFAULT: default
| DEFERRABLE: deferrable
| DEFERRED: deferred
| DELETE: delete
| DESC: desc
| DESCRIBE: describe
| DIAGNOSTICS: diagnostics
| DISCONNECT: disconnect
| DISTINCT: distinct
| DOUBLE: double
| DROP: drop
| ELSE: else
| END: end
| ENDEXEC: end-exec
| ESCAPE: escape
| EXCEPT: except
| EXCEPTION: exception
| EXEC: exec
| EXECUTE: execute
| EXISTS: exists
| EXTERNAL: external
| FALSE: false
| FETCH: fetch
| FIRST: first
| FLOAT: float
| FOR: for
| FOREIGN: foreign
| FOUND: found
| FROM: from
| FULL: full
| FUNCTION: function
| GET: get
| GLOBAL: global
| GO: go
| GOTO: goto
| GRANT: grant
| GROUP: group
| HAVING: having
| HOUR: hour
| IDENTITY: identity
| IMMEDIATE: immediate
| IN: in
| INDICATOR: indicator
| INITIALLY: initially
| INNER: inner
| INPUT: input
| INSENSITIVE: insensitive
| INSERT: insert
| INT: int
| INTEGER: integer
| INTERSECT: intersect
| INTO: into
| IS: is
| ISOLATION: isolation
| JOIN: join
| KEY: key
| LAST: last
| LEFT: left
| LIKE: like
| LOWER: lower
| MATCH: match
| MAX: max
| MIN: min
| MINUTE: minute
| MODULE: module
| NATIONAL: national
| NATURAL: natural
| NCHAR: nchar
| NEXT: next
| NO: no
| NOT: not
| NULL: null
| NULLIF: nullif
| NUMERIC: numeric
| OF: of
| ON: on
| ONLY: only
| OPEN: open
| OPTION: option
| OR: or
| ORDER: order
| OUTER: outer
| OUTPUT: output
| OVERLAPS: overlaps
| PAD: pad
| PARTIAL: partial
| PREPARE: prepare
| PRESERVE: preserve
| PRIMARY: primary
| PRIOR: prior
| PRIVILEGES: privileges
| PROCEDURE: procedure
| PUBLIC: public
| READ: read
| REAL: real
| REFERENCES: references
| RELATIVE: relative
| RESTRICT: restrict
| REVOKE: revoke
| RIGHT: right
| ROLLBACK: rollback
| ROWS: rows
| SCHEMA: schema
| SCROLL: scroll
| SECOND: second
| SELECT: select
| SESSION_USER: session_user
| SET: set
| SMALLINT: smallint
| SOME: some
| SPACE: space
| SQL: sql
| SQLCODE: sqlcode
| SQLERROR: sqlerror
| SQLSTATE: sqlstate
| SUBSTRING: substring
| SUM: sum
| SYSTEM_USER: system_user
| T: t
| TABLE: table
| TEMPORARY: temporary
| TIMEZONE_HOUR: timezone_hour
| TIMEZONE_MINUTE: timezone_minute
| TO: to
| TRANSACTION: transaction
| TRANSLATE: translate
| TRANSLATION: translation
| TRUE: true
| TS: ts
| UNION: union
| UNIQUE: unique
|
Re: [jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method
OK, thanks, point taken. I do hope at some point we have a project to improve our error messages; in general they are pretty good, but there are some doozys. David Daniel John Debrunner wrote: David W. Van Couvering wrote: I'm not sure I understand this logic. Shouldn't we be providing useful error messages with enough detail as possible? Standard error messages may be reusable, but they may not be helpful. Are there space concerns? Space concern is one factor. The other is that approaching this on an ad-hoc basis doesn't seem the best approach to me. Will lead to lots of different messages written by different people that really are describing the same situation. For example with your proposed fix would would have had a message just for CLOB that really isn't in line with the style of the other messages. Why not address it for BLOB as well, what about other data types, what about the corresponding client message? I've seen this before, the data type messages used to each print the type in their own way, much as the text of your message proposed. Thus we had no consistency, Clob vs. CLOB, DOUBLE vs. DOUBLE PRECISION vs double, DECIMAL vs NUMERIC vs. DECIMAL/NUMERIC. I'm sure we could write better error messages, but let's make a consistent effort around that, not little fixups in unrelated patches. If the standard message for value out of range is confusing, what could be done to improve it for all cases? Dan. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Updated: (DERBY-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=all ] Eric Radzinski updated DERBY-570: - Attachment: (was: rrefsqlj30118.html) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570.diff The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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: javadoc errors
Thanks for your thanks. Thanks also to David for committing the original patch. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: Hi Kathey, Nothing up my sleeve here. I'm just invoking ant derbydocs and hand editting the source code. Would be interested in advice on tools which we could use to fix simple cut-and-paste errors (like leaving @return tags on void methods). Would also be interested in tools we could wire into derbyall to force us to clean up our headers before checkin. So you fixed all those javadoc warnings by hand ? I thought you must have had a tool. You are amazing! Thank you so much Rick. Kathey
[jira] Updated: (DERBY-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Satheesh Bandaram updated DERBY-761: Comment: was deleted The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365115 ] Satheesh Bandaram commented on DERBY-761: - Here is the correct list... My previous list had GET_CURRENT_CONNECTION, it should have been GETCURRENTCONNECTION. ADD ALL ALLOCATE ALTER AND ANY ARE AS ASC ASSERTION AT AUTHORIZATION AVG BEGIN BETWEEN BIGINT BIT BOTH BY CASCADE CASCADED CASE CAST CHAR CHARACTER CHECK CLOSE COLLATE COLLATION COLUMN COMMIT CONNECT CONNECTION CONSTRAINT CONSTRAINTS CONTINUE CONVERT CORRESPONDING CREATE CURRENT CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER CURSOR DEALLOCATE DEC DECIMAL DECLARE _DEFAULT DEFERRABLE DEFERRED DELETE DESC DESCRIBE DIAGNOSTICS DISCONNECT DISTINCT DOUBLE DROP ELSE END END-EXEC ESCAPE EXCEPT EXCEPTION EXEC EXECUTE EXISTS EXTERNAL FALSE FETCH FIRST FLOAT FOR FOREIGN FOUND FROM FULL FUNCTION GET GETCURRENTCONNECTION GLOBAL GO GOTO GRANT GROUP HAVING HOUR IDENTITY IMMEDIATE IN INDICATOR INITIALLY INNER INOUT INPUT INSENSITIVE INSERT INT INTEGER INTERSECT INTO IS ISOLATION JOIN KEY LAST LEFT LIKE LOWER MATCH MAX MIN MINUTE NATIONAL NATURAL NCHAR NVARCHAR NEXT NO NOT NULL NULLIF NUMERIC OF ON ONLY OPEN OPTION OR ORDER OUT OUTER OUTPUT OVERLAPS PAD PARTIAL PREPARE PRESERVE PRIMARY PRIOR PRIVILEGES PROCEDURE PUBLIC READ REAL REFERENCES RELATIVE RESTRICT REVOKE RIGHT ROLLBACK ROWS SCHEMA SCROLL SECOND SELECT SESSION_USER SET SMALLINT SOME SPACE SQL SQLCODE SQLERROR SQLSTATE SUBSTRING SUM SYSTEM_USER TABLE TEMPORARY TIMEZONE_HOUR TIMEZONE_MINUTE TO TRANSACTION TRANSLATE TRANSLATION TRUE UNION UNIQUE UNKNOWN UPDATE UPPER USER USING VALUES VARCHAR VARYING VIEW WHENEVER WHERE WITH WORK WRITE YEAR BOOLEAN CALL EXPLAIN LTRIM RTRIM SUBSTR XML XMLPARSE XMLSERIALIZE XMLEXISTS The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=all ] Eric Radzinski updated DERBY-570: - Attachment: derby570-2.diff rrefsqlj30118.html The newest patch and HTML file address Dan's suggestion. I've reformatted the topic to match the other data type topics. Also, the suggested compile time to use was byte [ ] All the other data type topics used the fully-qualified name though, so I used java.lang.Byte. Let me know if that's not correct. wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570-2.diff, derby570.diff, rrefsqlj30118.html The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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-761) The reserved words list in the reference manual doesn't look uptodate
Mamta A. Satoor (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365110 ] Mamta A. Satoor commented on DERBY-761: --- I am glad you are looking at the list too. I was surprised to see D and T in the TOKEN reserved words list. Here is what I see in sqlgrammar.jj snip token list But I don't see them in the reservedKeyword() so I guess D and T are not reserved words. Thanks for catching it. Eric, please take those off from your changes. I haven't looked at this closely, but note that TS is in the same category as D and T. They're for timestamp, date, and time, respectively. So whatever happens to D and T should probably (I assume, having not investigated further) also occur for TS. I.e. if you're going to remove D and T, it seems (to me) that you should probably remove TS, as well...? Army
[jira] Commented: (DERBY-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=comments#action_12365118 ] Daniel John Debrunner commented on DERBY-570: - No java.lang.Byte is wrong. I was going to say look at VARCHAR FOR BIT DATA, but it doesn't have a compile type section. I would match VARCHAR FOR BIT DATA and CHAR FOR BIT data by not having a compile time type. I actually think we could remove the compile time java types for all the data types, I have no idea what it is meant to mean. Mappings between SQL types and Java types should be covered elsewhere. That's probably a separate cleanup though. wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570-2.diff, derby570.diff, rrefsqlj30118.html The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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-921) Support 32bit branch offsets for conditional logic in generated code.
Support 32bit branch offsets for conditional logic in generated code. - Key: DERBY-921 URL: http://issues.apache.org/jira/browse/DERBY-921 Project: Derby Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner Assigned to: Daniel John Debrunner Priority: Minor Fix For: 10.2.0.0 Conditionals in generated code (MethodBuilder.conditionalIf and conditionalIfNull) generate code that only supports 16 bit jump offsets for the branch opcode (e.g. IFNONNULL) or the GOTO opcode. Earlier code now detects the offset being larger than 32767. The JVM supports a 32bit jump offset instruction, GOTO_W, this can be used to support jump offsets that are bigger than 16bits (32767) for both the branch opcode and the GOTO instruction. This allow increasing the number of IN list values as seen in the query in the largeCodeGen test. -- 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] Updated: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server
Bryan Pendleton (JIRA) derby-dev@db.apache.org writes: [ http://issues.apache.org/jira/browse/DERBY-821?page=all ] Bryan Pendleton updated DERBY-821: -- Attachment: changes-no-object-tags.html Hi Knut Anders, Your document is excellent. Thank you very much for writing it. The changes make much more sense to me now. My browser (Firefox) was not behaving so well with the object tags in your changes.html file, so I took the liberty of re-posting the file with the object tags removed, in case there are other people having the same problem. Thanks Bryan, I don't know what the purpose of the object tags is, but validator.w3.org insisted on having them. :) If you get time to look at the patch, I would really appreciate hearing your opinions on it. (I apologize if a similar mail appears on the list. I sent an answer yesterday, but it seems to be lost somewhere. It probably took the wrong Trans-Atlantic cable or something.) -- Knut Anders
Re: SQLException and missing stack trace
Hi, Knut, you're right, I didn't see your original email, I do have to
have a pretty tight filter to get anything done besides read email.
The intent was to clone the SqlException into a SQLException, but
you're right, the stack trace and other context of the SqlException
would be lost in the way it's done now. Thanks very much for catching
this!
If the SqlException itself was caused by another exception, I have to
make sure that history gets saved too. I'll log a bug and take a look
at this.
David
Knut Anders Hatlen wrote:
David, I didn't see you responding to this mail. I'm resending it with
a different subject which is hopefully less likely to be regarded as
junk by your mail filter. :)
Thanks,
Knut Anders
Knut Anders Hatlen [EMAIL PROTECTED] writes:
Hi David, I'm sorry that I didn't notice it earlier, but I have found
a problem with the following method:
Modified:
db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java
URL:
http://svn.apache.org/viewcvs/db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java?rev=371561r1=371560r2=371561view=diff
==
---
db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java
(original)
+++
db/derby/code/trunk/java/client/org/apache/derby/client/am/SqlException.java
Mon Jan 23 07:58:34 2006
+
+/**
+ * Convert this SqlException into a java.sql.SQLException
+ */
+public SQLException getSQLException()
+{
+if ( wrappedException_ != null )
+{
+return wrappedException_;
+}
+
+// When we have support for JDBC 4 SQLException subclasses, this is
+// where we decide which exception to create
+SQLException sqle = new SQLException(getMessage(), getSQLState(),
+getErrorCode());
+
+// If we're in a runtime that supports chained exceptions, set the cause
+// of the SQLException.
+ if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
+{
+sqle.initCause(getCause());
+}
+
+// Set up the nextException chain
+if ( nextException_ != null )
+{
+// The exception chain gets constructed automatically through
+// the beautiful power of recursion
+sqle.setNextException(nextException_.getSQLException());
+}
+
+return sqle;
+}
I think
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(getCause());
}
should have been
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(this);
}
It is the SqlException that is the cause of the SQLException. The
cause of an SqlException is often null, and if we pass the null value
to SQLException.initCause(), we lose all of the driver internal stack
trace, and it makes debugging very difficult. All we get in the stack
trace is SqlException.getSQLException(), the top-level JDBC method and
the application stack.
There is a similar problem in SqlWarning.getSQLWarning().
--
Knut Anders
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
[jira] Created: (DERBY-922) getSQLException() method in client.am.SqlException does not correctly chain exceptions
getSQLException() method in client.am.SqlException does not correctly chain
exceptions
--
Key: DERBY-922
URL: http://issues.apache.org/jira/browse/DERBY-922
Project: Derby
Type: Bug
Reporter: David Van Couvering
This was detected by Knut Anders. From his email:
I think
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(getCause());
}
should have been
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(this);
}
It is the SqlException that is the cause of the SQLException. The
cause of an SqlException is often null, and if we pass the null value
to SQLException.initCause(), we lose all of the driver internal stack
trace, and it makes debugging very difficult. All we get in the stack
trace is SqlException.getSQLException(), the top-level JDBC method and
the application stack.
--
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-922) getSQLException() method in client.am.SqlException does not correctly chain exceptions
[ http://issues.apache.org/jira/browse/DERBY-922?page=all ]
David Van Couvering reassigned DERBY-922:
-
Assign To: David Van Couvering
getSQLException() method in client.am.SqlException does not correctly chain
exceptions
--
Key: DERBY-922
URL: http://issues.apache.org/jira/browse/DERBY-922
Project: Derby
Type: Bug
Reporter: David Van Couvering
Assignee: David Van Couvering
This was detected by Knut Anders. From his email:
I think
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(getCause());
}
should have been
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(this);
}
It is the SqlException that is the cause of the SQLException. The
cause of an SqlException is often null, and if we pass the null value
to SQLException.initCause(), we lose all of the driver internal stack
trace, and it makes debugging very difficult. All we get in the stack
trace is SqlException.getSQLException(), the top-level JDBC method and
the application stack.
--
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-921) Support 32bit branch offsets for conditional logic in generated code.
[ http://issues.apache.org/jira/browse/DERBY-921?page=comments#action_12365121 ] Daniel John Debrunner commented on DERBY-921: - Basic solution is to turn if X branch using big offset then code into if NOT X branch to T: (small fixed offset of +8) GOTO_W big offset T: then code and change replace GOTO with GOTO_W when the offset is bigger than 32767. Full details will be in the code comments for the Conditional class in the change Support 32bit branch offsets for conditional logic in generated code. - Key: DERBY-921 URL: http://issues.apache.org/jira/browse/DERBY-921 Project: Derby Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner Priority: Minor Fix For: 10.2.0.0 Conditionals in generated code (MethodBuilder.conditionalIf and conditionalIfNull) generate code that only supports 16 bit jump offsets for the branch opcode (e.g. IFNONNULL) or the GOTO opcode. Earlier code now detects the offset being larger than 32767. The JVM supports a 32bit jump offset instruction, GOTO_W, this can be used to support jump offsets that are bigger than 16bits (32767) for both the branch opcode and the GOTO instruction. This allow increasing the number of IN list values as seen in the query in the largeCodeGen test. -- 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: SQLException and missing stack trace
David W. Van Couvering [EMAIL PROTECTED] writes:
Hi, Knut, you're right, I didn't see your original email, I do have to
have a pretty tight filter to get anything done besides read email.
The intent was to clone the SqlException into a SQLException, but
you're right, the stack trace and other context of the SqlException
would be lost in the way it's done now. Thanks very much for catching
this!
I think thanks for running into this would be more precise. ;)
If the SqlException itself was caused by another exception, I have to
make sure that history gets saved too.
That won't be a problem since that cause would be linked to the
SqlException, so you could do something like this in your application:
try {
...
} catch (SQLException sqle) {
Throwable cause1 = sqle.getCause(); // SqlException
Throwable cause2 = cause1.getCause(); // SqlException's cause
}
I'll log a bug and take a look at this.
Thanks for looking into this. You'll probably need to update a couple
of master files as well. At least, when I had the proposed changes in
my sandbox, some of the tests failed because of extra Caused by:
lines.
--
Knut Anders
[jira] Commented: (DERBY-922) getSQLException() method in client.am.SqlException does not correctly chain exceptions
[
http://issues.apache.org/jira/browse/DERBY-922?page=comments#action_12365124 ]
Knut Anders Hatlen commented on DERBY-922:
--
There is a similar problem in SqlWarning.getSQLWarning().
getSQLException() method in client.am.SqlException does not correctly chain
exceptions
--
Key: DERBY-922
URL: http://issues.apache.org/jira/browse/DERBY-922
Project: Derby
Type: Bug
Reporter: David Van Couvering
Assignee: David Van Couvering
This was detected by Knut Anders. From his email:
I think
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(getCause());
}
should have been
if (JVMInfo.JDK_ID = JVMInfo.J2SE_14 )
{
sqle.initCause(this);
}
It is the SqlException that is the cause of the SQLException. The
cause of an SqlException is often null, and if we pass the null value
to SQLException.initCause(), we lose all of the driver internal stack
trace, and it makes debugging very difficult. All we get in the stack
trace is SqlException.getSQLException(), the top-level JDBC method and
the application stack.
--
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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Eric Radzinski updated DERBY-761: - Attachment: (was: rrefkeywords29722.html) The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761.diff I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-898) setAutoCommit(false) is not working properly for local connection with ClientXADataSource
[
http://issues.apache.org/jira/browse/DERBY-898?page=comments#action_12365127 ]
Kathey Marsden commented on DERBY-898:
--
Checked in fix to 10.1
Date: Fri Feb 3 13:00:35 2006
New Revision: 374742
URL: http://svn.apache.org/viewcvs?rev=374742view=rev
setAutoCommit(false) is not working properly for local connection with
ClientXADataSource
-
Key: DERBY-898
URL: http://issues.apache.org/jira/browse/DERBY-898
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.1.0, 10.1.1.1
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Priority: Critical
Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.3
Attachments: DERBY-898.diff
Network Server is not honoring local
transaction rollback using ClientXADataSource. Run the following standalone
JDBC code.
The output shows that after rolling back the local transaction,
the inserted data is still present.
final org.apache.derby.jdbc.ClientXADataSource ds =
new org.apache.derby.jdbc.ClientXADataSource();
ds.setServerName(localhost);
ds.setPortNumber(1527);
ds.setDatabaseName(WOMBAT);
ds.setTraceLevel(-1);
ds.setSecurityMechanism(ds.CLEAR_TEXT_PASSWORD_SECURITY);
ds.setUser(dbuser1);
ds.setPassword(dbpwd1);
//ds.setLogWriter(new
java.io.PrintWriter(System.out));
XAConnection xaConn = ds.getXAConnection();
Connection conn = xaConn.getConnection();
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_R
EAD);
conn.setAutoCommit(true);
System.out.println(Database product: +
conn.getMetaData().getDatabaseProductName());
System.out.println(Database version: +
conn.getMetaData().getDatabaseProductVersion());
System.out.println(Driver name: +
conn.getMetaData().getDriverName());
System.out.println(Driver version:+
conn.getMetaData().getDriverVersion());
Statement stmt = conn.createStatement();
try { stmt.execute(drop table cmtest); }
catch (SQLException sqlX) {} // ok, didn't exist
stmt.execute(CREATE TABLE cmtest (id integer not null
primary key, name varchar(60)));
stmt.close();
conn.setAutoCommit(false);
PreparedStatement pstmt = conn.prepareStatement(
INSERT INTO cmtest (id, name) VALUES(?,?),
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
pstmt.setInt(1, 13);
pstmt.setString(2, blah1);
pstmt.executeUpdate();
pstmt.setInt(1, 2);
pstmt.setString(2, blah2);
pstmt.executeUpdate();
conn.rollback();
PreparedStatement pstmt2 = conn.prepareStatement(
SELECT * FROM cmtest WHERE id = ?,
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
pstmt2.setInt(1, 13);
ResultSet rset = pstmt2.executeQuery();
if (rset.next())
{
System.out.println(Test fails. First insert was
not rolled back.);
System.out.println(The data is still present. It
is: + rset.getObject(1) +
, + rset.getObject(2));
}
else
System.out.println(Test passes. First insert was
rolled back.);
Here's the output,
Database product: Apache Derby
Database version: 10.1.2.2
Driver name: Apache Derby Network Client JDBC Driver
Driver version: 10.1.2.2
Test fails. First insert was not rolled back.
The data is still present. It is: 13, blah1
On some brief investigation I see that the Network Server embedded connection
is in autocomit mode so is autocommitting the transaction before the
rollback. Network server should always have autocommit false and let the
client drive the commit.
--
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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Eric Radzinski updated DERBY-761: - Attachment: derby761-2.diff rrefkeywords29722.html This patch and HTML file are based on Sateesh's list. Note that several of the keywords that Mamta originally suggested including are not present. These include: BINARY, CHARACTER_LENGTH, D, MODULE, T, TS, VALUE, and VARBINARY. And this list does include INOUT and NVARCHAR, which Mamta suggested deleting. The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761-2.diff, derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=all ] Eric Radzinski updated DERBY-570: - Attachment: (was: rrefsqlj30118.html) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570-2.diff, derby570.diff The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=all ] Eric Radzinski updated DERBY-570: - Attachment: rrefsqlj30118.html derby570-3.diff derby570-3.diff removes the compile time type section from the topic. Latest HTML file is included for review. wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570-2.diff, derby570-3.diff, derby570.diff, rrefsqlj30118.html The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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-570) wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA
[ http://issues.apache.org/jira/browse/DERBY-570?page=comments#action_12365131 ] Daniel John Debrunner commented on DERBY-570: - Looks good. Thanks for working through this one. wrong java.sql.Type id implied for LONG VARCHAR FOR BIT DATA Key: DERBY-570 URL: http://issues.apache.org/jira/browse/DERBY-570 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Rick Hillegas Attachments: derby570-2.diff, derby570-3.diff, derby570.diff, rrefsqlj30118.html The Datatypes section of the Reference Manual says that LONG VARCHAR FOR BIT DATA is identical to VARCHAR FOR BIT DATA but does not give a jdbc type, implying that LONG VARCHAR FOR BIT DATA has the same jdbc type as VARCHAR FOR BIT DATA, i.e., VARBINARY. This section should say that LONG VARCHAR FOR BIT DATA has the following jdbc type: LONGVARBINARY. -- 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
Question about DERBY-44 test case (paging Myrna)
Hi, I have a question about a test case for DERBY-44 (which appears to have been fixed by Myrna). In jdbcapi/parameterMetaDataJdbc30.java, I found this test case: // variation, and also test out empty string in the escape (jira 44). System.out.println(variation 1, testing jira 44); ps = con.prepareStatement(select * from sys.systables where tablename like ? escape ?); ps.setString (1, SYS%); ps.setString (2, ); paramMetaData = ps.getParameterMetaData(); System.out.println(parameters count for prepared statement is + paramMetaData.getParameterCount()); dumpParameterMetaData(paramMetaData); ps.execute(); I wonder what the purpose of this test is. Is it to test that the escape keyword is accepted by the SQL parser/compiler, or is it to test that specifiying an empty escape string shouldn't cause ps.execute() to fail? The reason why I'm asking is that this case failed when I was testing a patch for DERBY-822. In DERBY-822, we want the client driver to prefetch data in the execute call. Since having an empty string as escape character is not allowed by the SQL spec, this test will fail if we do prefetching in execute(). However, the test code does not attempt to fetch the results from the query, so it doesn't fail if we don't prefetch data. To me, this test case looks a bit odd (testing that executing invalid SQL doesn't fail), but I thought I'd ask before changing it, in case there's a reason for doing it like this. Thanks. -- Knut Anders
Re: [jira] Updated: (DERBY-898) setAutoCommit(false) is not working properly for local connection with ClientXADataSource
Bryan Pendleton wrote: Is this something specific to XA distributed transactions, or is it just a fundamental aspect of how the Network Server behaves that all transaction control should be performed by the client? It is the same for all connections. The transactional control is performed by the client. The server side connection is always autocommit false, but in XADatabase.java it was not being set properly as it is in Database.java. I think that we could probably see a significant performance improvement if autocommit is true if we switched to a different model and sent an EXCSQLSET command of some sort with setAutoCommit(), This would be similar to Oyvind's implemetnation for setQueryTimeout. Right now, with autocommit true there is an extra round trip to the server with each statement, because the client has to send the statement followed by the commit. Of course we would need to take care to do the right thing for older clients. Kathey
[jira] Created: (DERBY-923) Remove stale reserved words from Derby. I found many reserved words not really used in Derby.
Remove stale reserved words from Derby. I found many reserved words not really used in Derby. - Key: DERBY-923 URL: http://issues.apache.org/jira/browse/DERBY-923 Project: Derby Type: Sub-task Components: SQL Environment: Generic Reporter: Satheesh Bandaram Priority: Minor There may be use for some of these in the future, but from first look all these don't seem to be used. Any ideas on what should be done? Removing these from Derby parser would also speed up query parsing time. ALLOCATE ARE ASSERTION CASCADED COLLATE COLLATION CONNECT CORRESPONDING DISCONNECT DEALLOCATE DEFERRABLE DEFERRED DESCRIBE DIAGNOSTICS END-EXEC EXCEPTION FIRST FOUND FULL GO GOTO IMMEDIATE INDICATOR INITIALLY INSENSITIVE MATCH NATURAL OPTION OVERLAPS PAD PARTIAL PREPARE PRIOR RELATIVE SCROLL SPACE SQLCODE SQLERROR SQLSTATE SYSTEM_USER TIMEZONE_HOUR TIMEZONE_MINUTE TRANSLATE TRANSLATION WHENEVER WRITE -- 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-916) documentation to address Derby-239: online backup
[ http://issues.apache.org/jira/browse/DERBY-916?page=comments#action_12365136 ] Suresh Thalamati commented on DERBY-916: Hi Eric, Thanks for volunteering to document the online backup feature. You are right, Server Admin Guide and Reference Guide has to be updated with the above information. In addition to what you already mentioned, I think following information also should be added: Server Guide : 1) in Section : Using the backup procedure to perform an online backup (SYSCS_UTIL.SYSCS_BACKUP_DATABASE ..topic) SYSCS_UTIL.SYSCS_BACKUP_DATABASE procedures will throw error, if there are any unlogged operations already executed in the same transaction as backup procedure. If there are any unlogged operations in progress in other transactions in the system when backup starts, this procedures will block until those transactions are completed before performing the backup. Derby automatically converts unlogged operations to logged mode if they are started when the backup is in progress except operations that are used to maintain application jar files in the database. Procedures to install, replace, and remove jar files in a database are blocked when the backup is in progress. If you don't want backup to block for unlogged operation in other transactions to complete, use SYSCS_UTIL.SYSCS_BACKUP_DATABASE_NOWAIT procedure. This procedure will return error immediately if there are any transactions in progress with unlogged operations at the start of the backup instead of waiting for those transactions to complete. 2) Same information as above should be added to Rollforward Recovery Section also. (SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE topic). Info is same as above(1) , except procedure names will be SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE and SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT 3) Any mention of update operations not possible should be removed except when it is mentioned in the context of using SYSCS_UTIL.SYSCS_FREEZE_DATABASE procedure. 4) In the freeze procedure section following sentence should be changed. Current sentence: For example, because the UNIX tar command uses operating system file-copying routines, and Derby uses the IBM Application Developer Kit file-copying routines, the tar command might provide faster backups than the SYSCS_UTIL.SYSCS_BACKUP_DATABASE procedure. replace it with something like: For example, because the UNIX tar command uses operating system file-copying routines, and SYSCS_UTIL.SYSCS_BACKUP_DATABASE procedure uses java I/O calls with additional internal synchronization to allow updates during the backup, the tar command might provide faster backups than the SYSCS_UTIL.SYSCS_BACKUP_DATABASE procedure. Reference Guide: 1) Following two new procedures needs to be added to the Reference Guide: --SYSC_UTIL.SYSCS_ONLINE_BACKUP_DATABASE_NOWAIT and --SYSC_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT 2) While scanning throws the docs, I also noticed Following two procedures are missing in 10.0 and 10.1 docs in the reference manual , I think they need to be added too. SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE (IN BACKUPDIR VARCHAR(32672), IN SMALLINT DELETE_ARCHIVED_LOG_FILES) SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(IN SMALLINT DELETE_ARCHIVED_LOG_FILES) Thanks -suresht documentation to address Derby-239: online backup - Key: DERBY-916 URL: http://issues.apache.org/jira/browse/DERBY-916 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Assignee: Eric Radzinski -- 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-880) jdbcapi/connectionJdbc20.java fails for server (10.1.2.2) and client (10.2.0.0) compatibility testing with SQLSTATE(null): java.sql.SQLException: Stream of column value
[ http://issues.apache.org/jira/browse/DERBY-880?page=all ] Rajesh Kartha updated DERBY-880: type: Test (was: Bug) Fix Version: 10.1.2.3 (was: 10.2.0.0) Priority: Major (was: Critical) - Changing the priority from 'Critical' to 'Medium'. - Since the tests in 10.1 branch needs to be updated, the fix verison should also reflect that - 10.1.2.3 jdbcapi/connectionJdbc20.java fails for server (10.1.2.2) and client (10.2.0.0) compatibility testing with SQLSTATE(null): java.sql.SQLException: Stream of column value in result cannot be retrieved twice --- Key: DERBY-880 URL: http://issues.apache.org/jira/browse/DERBY-880 Project: Derby Type: Test Components: Regression Test Failure, Network Client Versions: 10.2.0.0 Environment: OS: Windows 2000, Server: 10.1.2.2 (372412), Client: 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 Reporter: Ramandeep Kaur Fix For: 10.1.2.3 Attachments: connectionJdbc20.diff, connectionJdbc20.tmp, connectionJdbc20.tmpmstr Ran derby suite derbynetclientmats with Server: 10.1.2.2 (372412), Client: 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 as following: 1. Create directories for 10.1.2.2 jar files (all jar files except derbyclient.jar) and 10.2.0.0 jars files (only derbyClient.jar). 2. Set CLASSPATh to the jars in the above directories. 3. Run suite derbynetclientmats by giving the following command:- java org.apache.derbyTesting.functionTests.harness.RunSuite derbynetclientmats Test case jdbcapi/connectionJdbc20.java failed with following exception:- FAIL -- unexpected exception SQLSTATE(null): java.sql.SQLException: Stream of column value in result cannot be retrieved twice java.sql.SQLException: Stream of column value in result cannot be retrieved twice Test Failed. Attaching diff, tmp, and tmpstr. -- 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-881) jdbcapi/LOBTest.java fails for server (10.1.2.2) and client (10.2.0.0) compatibility testing
[ http://issues.apache.org/jira/browse/DERBY-881?page=all ] Rajesh Kartha updated DERBY-881: type: Test (was: Bug) Fix Version: 10.1.2.3 Priority: Major (was: Critical) - Changing the priority from 'Critical' to 'Medium'. - Since the tests in 10.1 branch needs to be updated, the fix verison should also reflect that - 10.1.2.3 jdbcapi/LOBTest.java fails for server (10.1.2.2) and client (10.2.0.0) compatibility testing Key: DERBY-881 URL: http://issues.apache.org/jira/browse/DERBY-881 Project: Derby Type: Test Components: Network Client, Regression Test Failure Versions: 10.1.2.2, 10.2.0.0 Environment: OS: Windows 2000, Server: 10.1.2.2 (372412), Client: 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 Reporter: Ramandeep Kaur Fix For: 10.1.2.3 Attachments: LOBTest.diff, LOBTest.tmp, LOBTest.tmpmstr Ran derby suite derbynetclientmats with Server: 10.1.2.2 (372412), Client: 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 as following: 1. Create directories for 10.1.2.2 jar files (all jar files except derbyclient.jar) and 10.2.0.0 jars files (only derbyClient.jar). 2. Set CLASSPATh to the jars in the above directories. 3. Run suite derbynetclientmats by giving the following command:- java org.apache.derbyTesting.functionTests.harness.RunSuite derbynetclientmats Test case jdbcapi/LOBTest.java failed with following diff (pasting part of diff) *** Start: LOBTest jdk1.5.0_02 DerbyNetClient derbynetmats:jdbcapi 2006-01-26 00:11:56 *** 18 del 0 getBinaryStream - EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 18a18 0 getBinaryStream - EXCEPTION (Stream of column value in result cannot be retrieved twice) 23 del 0 getCharacterStream - EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 23a23 0 getCharacterStream - EXCEPTION (Stream of column value in result cannot be retrieved twice) 41 del 1 getBinaryStream - EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 41a41 1 getBinaryStream - EXCEPTION (Stream of column value in result cannot be retrieved twice) 46 del 1 getCharacterStream -Object': java.io.Reader -- 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-583) networkserver does not return error message strings in native encoding to ij on zseries
[ http://issues.apache.org/jira/browse/DERBY-583?page=all ] Kathey Marsden reassigned DERBY-583: Assign To: Kathey Marsden networkserver does not return error message strings in native encoding to ij on zseries --- Key: DERBY-583 URL: http://issues.apache.org/jira/browse/DERBY-583 Project: Derby Type: Bug Components: Network Server Versions: 10.1.1.0 Environment: OS/390 (zseries) 1.06, ibm 1.4.2 jre Reporter: Myrna van Lunteren Assignee: Kathey Marsden Fix For: 10.2.0.0 Attachments: ijzrepro.jar When running ij on an OS/390 without specifying any encoding or locale properties, and starting network server without any locale properties, various error messages do not get converted into the native encoding. Thus the messages are unreadable and not helpful. The problem is not limited to ij, just easy to reproduce with ij. Some errors return readable message strings are returned with jcc, but not with derbyclient, for instance the test lang/forupdate.sql has this line in it: select i from t1, t2 for update; which on linux windows results in an error message 42Y90, FOR UPDATE is not permitted in this type of statement. On OS/390 this error message is readable with jcc, but with derbyclient, only the string 'ERROR' is readable. Other messages - especially those with indirection in it like error 42X04 are equally unreadable with both clients. To reproduce 1 situation: - start networkserver - in another shell window, use the following string to run the in.sql file save the output for jcc-client and derbyclient respectively: -- java -Dij.database='jdbc:derby:net://localhost:1527/wombat3;create=true' -Dij.retrieveMessagesFromServerOnGetMessage=true -Dij.protocol=jdbc:derby:net://localhost:1527/ -Dij.driver=com.ibm.db2.jcc.DB2Driver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql jcc.out 21 -- java -Dij.database='jdbc:derby://localhost:1527/wombat2;create=true' -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.driver=org.apache.derby.jdbc.ClientDriver -Dij.user=APP -Dij.password=APP org.apache.derby.tools.ij in.sql client.out 21 -- in.sql contains: -- drop table a; create table a (a int); insert into a values (2342323423); disconnect; exit; -- I'll attach a jar with the .out files and in.sql. This means that the out files are in EBCDIC, to read them, one needs to run them through native2ascii -encoding Cp1047. -- 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] Updated: (DERBY-898) setAutoCommit(false) is not working properly for local connection with ClientXADataSource
Kathey Marsden [EMAIL PROTECTED] writes: Bryan Pendleton wrote: Is this something specific to XA distributed transactions, or is it just a fundamental aspect of how the Network Server behaves that all transaction control should be performed by the client? It is the same for all connections. The transactional control is performed by the client. The server side connection is always autocommit false, but in XADatabase.java it was not being set properly as it is in Database.java. I think that we could probably see a significant performance improvement if autocommit is true if we switched to a different model and sent an EXCSQLSET command of some sort with setAutoCommit(), This would be similar to Oyvind's implemetnation for setQueryTimeout. Right now, with autocommit true there is an extra round trip to the server with each statement, because the client has to send the statement followed by the commit. Of course we would need to take care to do the right thing for older clients. Hi Kathey and Bryan, I doubt that such a modification would improve the performance. The client driver is already piggybacking the commit messages so the number of round trips is not affected. This might change a bit if my patch for DERBY-821 is accepted. Right now, we have this situation: - ps.executeUpdate() needs one round trip (execute with commit piggybacked) - ps.executeQuery() needs one round trip, but you get an extra round trip to close the result set (commit is piggybacked on close) With my patch for DERBY-821, nothing changes for executeUpdate(). However, when using executeQuery(), you don't need a round trip to close the result set. Instead, you need a round trip for commit, since you don't have a message to piggyback it on. So in this case autocommit on the server would be advantageous. -- Knut Anders
Paging Lance: format of empty result set
If I want to send an empty result set, do the result columns still have to match the expected set of result columns? I can't see why this would matter. Anybody else want to weigh in on this? It would be a lot simpler for me if I could have a single fake query that generates a generic empty result set with, say, a single integer column, rather than compose one with the right columns for each unsupported metadata call. Thanks, David begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: Paging Lance: format of empty result set
David W. Van Couvering wrote: If I want to send an empty result set, do the result columns still have to match the expected set of result columns? I can't see why this would matter. Anybody else want to weigh in on this? It would be a lot simpler for me if I could have a single fake query that generates a generic empty result set with, say, a single integer column, rather than compose one with the right columns for each unsupported metadata call. You have to provide a result set of the shape defined by the call. It will be just to confusing to do anything else. With your approach the ResultSetMetaData would not match the defined columns of the DMD method. Dan.
[jira] Commented: (DERBY-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365145 ] Mamta A. Satoor commented on DERBY-761: --- Satheesh, your list looks correct except for _DEFAULT. It should really be DEFAULT which is the reserved keyword. The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761-2.diff, derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-745) DRDA Protocol Exception using DB2JCC driver and CLOBs from IJ
[ http://issues.apache.org/jira/browse/DERBY-745?page=comments#action_12365147 ] Kathey Marsden commented on DERBY-745: -- Thanks Bryan for looking at this issue. If I try to create the table with DB2, I get an error SQLSTATE 54010 Table record length is too long. So, there is definitely more investigation needed from the jcc side if this is to work with Derby. The SYSSTAT package that refers to the static functions that are supposed to be built in but I think does not correspond to the schema. The metadata calls for instance would be sent with package SYSSTAT but the procedure name would be SYSIBM.GETTABLES() for instance. If there is no procedure name in the EXCSQLSTT call, I am not sure what JCC is trying to call in this case, but will pass on to those who might be able to find out. A little background on some of the package names is available at: http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/ad/r0007866.htm?resultof=%22%53%59%53%53%54%41%54%22%20%22%73%79%73%73%74%61%74%22%20%22%70%61%63%6b%61%67%65%22%20%22%70%61%63%6b%61%67%22%20%22%69%73%6f%6c%61%74%69%6f%6e%22%20%22%69%73%6f%6c%22%20%22%6c%65%76%65%6c%22%20 DRDA Protocol Exception using DB2JCC driver and CLOBs from IJ - Key: DERBY-745 URL: http://issues.apache.org/jira/browse/DERBY-745 Project: Derby Type: Bug Components: Network Server Versions: 10.1.1.0 Reporter: Bryan Pendleton Assignee: Bryan Pendleton Priority: Minor Trying to manipulate a cursor via IJ using the DB2JCC driver talking to the Network Server encounters a DRDA Protocol Exception: ERROR 58009: Execution failed due to a distribution protocol error that caused deallocation of the conversation. A DRDA Data Stream Syntax Error was detected. Reason: 0x2113 Here is how to reproduce the problem: 1) Start the Network Server, including derbyTesting.jar in your classpath 2) Create a database. In my script below I called the database 'testBig', but you can use any name, just tweak the connect statement below 3) Start IJ, being sure that a) db2jcc.jar and db2jcc_license_c.jar are in your path b) you are authenticated (-Dij.user=APP -Dij.password=APP in the simple case) 4) Run the following small script. The error occurs on the 'first c1' line. driver 'com.ibm.db2.jcc.DB2Driver'; connect 'jdbc:derby:net://localhost:1527/testBig'; create procedure INSERTDATA1(IN a int) language java parameter style java external name 'org.apache.derbyTesting.functionTests.util.ProcedureTest.bigTestData'; prepare p1 as 'call INSERTDATA1(?)'; drop table big; create table big(c1 clob(4), c2 clob(4), c3 clob(4)); execute p1 using 'values 8'; get scroll insensitive cursor c1 as 'select * from big'; first c1; quit; -- 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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Eric Radzinski updated DERBY-761: - Attachment: derby761-3.diff rrefkeywords29722.html latest patch changes _DEFAULT to DEFAULT. The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761-2.diff, derby761-3.diff, derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Eric Radzinski updated DERBY-761: - Attachment: (was: rrefkeywords29722.html) The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761-2.diff, derby761-3.diff, derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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: Paging Lance: format of empty result set
OK, thanks. I hadn't considered the RS metadata. David Daniel John Debrunner wrote: David W. Van Couvering wrote: If I want to send an empty result set, do the result columns still have to match the expected set of result columns? I can't see why this would matter. Anybody else want to weigh in on this? It would be a lot simpler for me if I could have a single fake query that generates a generic empty result set with, say, a single integer column, rather than compose one with the right columns for each unsupported metadata call. You have to provide a result set of the shape defined by the call. It will be just to confusing to do anything else. With your approach the ResultSetMetaData would not match the defined columns of the DMD method. Dan. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Commented: (DERBY-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
[ http://issues.apache.org/jira/browse/DERBY-51?page=comments#action_12365150 ] Kathey Marsden commented on DERBY-51: - Well I guess I didn't notice David's comment on this issue when he made it (in May). David said code that shuts down embedded seems to be commented out -- see the commented out code at the end of NetworkServerControlImpl.blockingStart(), starting with // Shutdown Cloudscape. I am a little surprised and wonder. Has it always been this way since 10.0? Are we shutting down cleanly when we start from the command line? Is it that we need an API that makes this an optional behavior? Or are things OK as they stand? I tend to think we need an api to shutdown embedded with network server. Othewise it seems likely that folks will assume it gets shutdown. Need NetworkServerControl shutdown API method that does not shutdown derby embedded --- Key: DERBY-51 URL: http://issues.apache.org/jira/browse/DERBY-51 Project: Derby Type: Improvement Components: Network Server Versions: 10.0.2.0 Reporter: Kathey Marsden Attachments: NSinSameJVM.java In an applcation server environment where both Network Server and Embedded connections are being used it is a problem when Network server is shutdown and deregisters the embedded driver and shutsdown the databases. this would be the signature /** * Shutdown a Network Server. * Shuts down the Network Server listening on the port and InetAddress * specified in the constructor for this NetworkServerControl object. * * @param derbyShutdown if true, shutsdown the derby embedded system . if false do not shutdown derby embeddded system * @exception Exceptionthrows an exception if an error occurs */ public void shutdown(boolean derbyShutdown) throws Exception -- 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
Auto-close of result sets on failure?
There is a new metadata call, autoCommitFailureClosesAllResultSets, which returns true if a SQLException while autoCommit is true indicates that all open ResultSets are closed, even ones that are holdable. In my naive scan of the code on the embedded side, it appears as though we do *not* close result sets upon exception. There is a method clearResultSets() on EmbedStatement that is only called when the statement itself is closed or when executing a new statement (we close the old result sets from the previous invocation of the statement). Because of the asynchronous nature of the network client protocol, it's a little harder to decode, but it appears that we do not close result sets upon exception there either. Does anyone care to differ? Otherwise I'll return false for this new JDBC4 metadata call. Thanks, David begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Updated: (DERBY-921) Support 32bit branch offsets for conditional logic in generated code.
[ http://issues.apache.org/jira/browse/DERBY-921?page=all ] Daniel John Debrunner updated DERBY-921: Description: Conditionals in generated code (MethodBuilder.conditionalIf and conditionalIfNull) generate code that only supports 16 bit jump offsets for the branch opcode (e.g. IFNONNULL) or the GOTO opcode. Earlier code now detects the offset being larger than 32767. The JVM supports a 32bit jump offset instruction, GOTO_W, this can be used to support jump offsets that are bigger than 16bits (32767) for both the branch opcode and the GOTO instruction. This allow increasing the number of logical operators as seen in the query in the largeCodeGen test. was: Conditionals in generated code (MethodBuilder.conditionalIf and conditionalIfNull) generate code that only supports 16 bit jump offsets for the branch opcode (e.g. IFNONNULL) or the GOTO opcode. Earlier code now detects the offset being larger than 32767. The JVM supports a 32bit jump offset instruction, GOTO_W, this can be used to support jump offsets that are bigger than 16bits (32767) for both the branch opcode and the GOTO instruction. This allow increasing the number of IN list values as seen in the query in the largeCodeGen test. Spaced out on which query this was helping in large code gen. Support 32bit branch offsets for conditional logic in generated code. - Key: DERBY-921 URL: http://issues.apache.org/jira/browse/DERBY-921 Project: Derby Type: Sub-task Components: Services, SQL Reporter: Daniel John Debrunner Assignee: Daniel John Debrunner Priority: Minor Fix For: 10.2.0.0 Conditionals in generated code (MethodBuilder.conditionalIf and conditionalIfNull) generate code that only supports 16 bit jump offsets for the branch opcode (e.g. IFNONNULL) or the GOTO opcode. Earlier code now detects the offset being larger than 32767. The JVM supports a 32bit jump offset instruction, GOTO_W, this can be used to support jump offsets that are bigger than 16bits (32767) for both the branch opcode and the GOTO instruction. This allow increasing the number of logical operators as seen in the query in the largeCodeGen test. -- 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: Paging Lance: format of empty result set
David W. Van Couvering wrote: OK, thanks. I hadn't considered the RS metadata. Just a note that the result set metadata should match the defined results _exactly_. Returning an int where a short is expected, or a char where a varchar is expected, or a nullable column where a not null column is expected, etc. etc. can cause existing applications a lot of problems--see DERBY-107. Our JDBC tests might not catch it, but my past experience is that ODBC applications (esp. Microsoft ones like Access) will throw a fit if something is even slightly off... Army
[jira] Assigned: (DERBY-900) Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour
[ http://issues.apache.org/jira/browse/DERBY-900?page=all ] Kathey Marsden reassigned DERBY-900: Assign To: Kathey Marsden Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour -- Key: DERBY-900 URL: http://issues.apache.org/jira/browse/DERBY-900 Project: Derby Type: Bug Reporter: Daniel John Debrunner Assignee: Kathey Marsden Fix For: 10.2.0.0 These constructors use the Java default platform encoding to convert the bytes to a String, this typically leads to bugs on platforms with different encodings. Replace with code using fixed conversion, or alternative mechanisms. If the call is required its use should be commented as to why it is required. org.apache.derby.client.am.ClobOutputStream - some existing bug? org.apache.derby.client.am.DateTime - see DERBY-877 org.apache.derby.client.am.sqlca I generated this list using the Java search in eclipse for references to the constructors String(byte[]) String(byte[],int,int) -- 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: Paging Lance: format of empty result set
OK, I will do my best to match *exactly* what is expected. I will look at some of the existing stuff to use as a pattern. However, I will have to leave it to you or whomever does the ODBC tests to make sure it works for ODBC. David Army wrote: David W. Van Couvering wrote: OK, thanks. I hadn't considered the RS metadata. Just a note that the result set metadata should match the defined results _exactly_. Returning an int where a short is expected, or a char where a varchar is expected, or a nullable column where a not null column is expected, etc. etc. can cause existing applications a lot of problems--see DERBY-107. Our JDBC tests might not catch it, but my past experience is that ODBC applications (esp. Microsoft ones like Access) will throw a fit if something is even slightly off... Army begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: Question about DERBY-44 test case (paging Myrna)
On 03 Feb 2006 22:30:46 +0100, Knut Anders Hatlen [EMAIL PROTECTED] wrote: Hi,I have a question about a test case for DERBY-44 (which appears tohave been fixed by Myrna). In jdbcapi/parameterMetaDataJdbc30.java, I found this test case:// variation, and also test out empty string in the escape (jira 44).System.out.println(variation 1, testing jira 44);ps = con.prepareStatement(select * from sys.systables where tablename like ? escape ?);ps.setString (1, SYS%);ps.setString (2, );paramMetaData = ps.getParameterMetaData();System.out.println (parameters count for prepared statement is + paramMetaData.getParameterCount());dumpParameterMetaData(paramMetaData);ps.execute();I wonder what the purpose of this test is. Is it to test that the escape keyword is accepted by the SQL parser/compiler, or is it totest that specifiying an empty escape string shouldn't causeps.execute() to fail? It was not at all clear, but after much digging through old tests and repros ;-) it appears this test is trying to make sure ERROR 22019 is returned. At one point, passing onthe empty string in a piece of code like thiswould generate an StringIndexOutOfBoundsException instead of ERROR 22019 on the ps.execute(). The reason why I'm asking is that this case failed when I was testinga patch for DERBY-822. In DERBY-822, we want the client driver to prefetch data in the execute call. Since having an empty string asescape character is not allowed by the SQL spec, this test will failif we do prefetching in execute(). However, the test code does notattempt to fetch the results from the query, so it doesn't fail if we don't prefetch data.To me, this test case looks a bit odd (testing that executing invalidSQL doesn't fail), but I thought I'd ask before changing it, in casethere's a reason for doing it like this. Thx for checking, I hope my reply makes sense. It was attempting to check it didn't fail in an uglyway. I'm wondering how it's failing for you, you didn't say. Myrna
Re: svn commit: r374778 - in /db/derby/code/trunk/java: engine/org/apache/derby/iapi/services/classfile/ engine/org/apache/derby/impl/services/bytecode/ testing/org/apache/derbyTesting/functionTests/m
[EMAIL PROTECTED] wrote: Thanks Dan for the continued progress on my favorite issue. I am looking forward to studying the patch sometime to actually understand it, but in the meanwhile I just looked at the little stuff. 1) On the javadoc I found that eclipse generates javadoc like this, but Rick reported that it actually causes a warning because there is nothing after the @return * @param pc +* @param additionalBytes +* @return +*/ 2) Would it make sense to bump up the starting value of the loop in the test, now that you have made so much progress? +PASS: PREPARE: Logical operators with 200 parameters PASS: Logical operators with 200 parameters +PASS: PREPARE: Logical operators with 300 parameters PASS: Logical operators with 300 parameters +PASS: PREPARE: Logical operators with 400 parameters PASS: Logical operators with 400 parameters -FAILED QUERY: Logical operators with 500 parameters. +PASS: PREPARE: Logical operators with 500 parameters +PASS: Logical operators with 500 parameters +PASS: PREPARE: Logical operators with 600 parameters +PASS: Logical operators with 600 parameters +PASS: PREPARE: Logical operators with 700 parameters +PASS: Logical operators with 700 parameters +PASS: PREPARE: Logical operators with 800 parameters +PASS: Logical operators with 800 parameters +FAILED QUERY: Logical operators with 900 parameters.
[jira] Updated: (DERBY-907) regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me)
[ http://issues.apache.org/jira/browse/DERBY-907?page=all ] Deepa Remesh updated DERBY-907: --- Attachment: derby-907.diff derby-907.status Attaching a patch 'derby-907.diff' which modifies the test store/RecoveryAfterBackup.java to run with j9 and j9_foundation vm. * Modifies app_properties files to add ij.dataSource properties. Also changed 'database' to 'ij.database' property. Removed usedefaults to avoid conflict with default property. * Modified the test to get connection using DriverManager/DataSource. With the patch, I ran the RecoveryAfterBackup tests with Sun JDK1.4.2, j9 and j9 foundation vm. Please review/commit this patch. Thanks regression test failure in RecoveryAfterBackup on wssd5.6 ibm jvm (j2me) Key: DERBY-907 URL: http://issues.apache.org/jira/browse/DERBY-907 Project: Derby Type: Bug Components: Regression Test Failure Versions: 10.2.0.0 Reporter: Mike Matrigali Assignee: Deepa Remesh Priority: Critical Attachments: derby-907.diff, derby-907.status It looks like this test may be using a class that does not exist in j2me, can someone with j2me knowledge take a look? If so test either should not run there, or test may need to change. This failed from 1/27 codeline, last passed 1/13 that I know of. *** Start: RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 2006-01-29 20:40:13 *** 1 del Count: 2 Sum: 1 2 del Inserting records ... 3 del Shutting down database ... 4 del Database shutdown completed 5 del Starting restore with roll-forward recovery.. 6 del Verifying database ... 7 del Count: 256 Sum: 32640 7 add Exception in thread main java.lang.NoClassDefFoundError: javax.sql.DataSource Test Failed. *** End: RecoveryAfterBackup jdk1.3.1 subset - 2.1 storeall:storerecovery 2006-01-29 20:40:14 *** -- 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-885) Test harness aborts with exception when running nist test suite in J2ME
[ http://issues.apache.org/jira/browse/DERBY-885?page=all ] Deepa Remesh updated DERBY-885: --- Attachment: derby-885.diff derby-885.status Ataching a patch 'derby-885.diff' which adds new j9 masters for nist/dml160.sql test. With this patch, I ran nist suite with j9 vms and Sun JDK 1.4.2. Please review/commit this patch. Thanks Test harness aborts with exception when running nist test suite in J2ME --- Key: DERBY-885 URL: http://issues.apache.org/jira/browse/DERBY-885 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: IBM WCTME 5.7 j9 foundation VM Reporter: Deepa Remesh Assignee: Deepa Remesh Attachments: derby-885.diff, derby-885.status The first test in nist suite (schema1.sql) fails with following exception: RunIJ -- java.security.AccessControlException: Access denied (java.io.FilePermission C:\deepa\Derby\derby_testing\j9foun_nist\nist\schema1_app.properties read) java.security.AccessControlException: Access denied (java.io.FilePermission C:\deepa\Derby\derby_testing\j9foun_nist\nist\schema1_app.properties read) at java.security.AccessController.checkPermission(AccessController.java:74) at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) at java.lang.SecurityManager.checkRead(SecurityManager.java:395) at java.io.FileInputStream.init(FileInputStream.java:90) at org.apache.derby.impl.tools.ij.util.getPropertyArg(util.java:120) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:91) at org.apache.derby.impl.tools.ij.Main.main(Main.java:75) at org.apache.derby.tools.ij.main(ij.java:56) at org.apache.derbyTesting.functionTests.harness.RunIJ.run(RunIJ.java:44) at java.lang.Thread.run(Thread.java:795) java.security.AccessControlException: Access denied (java.util.PropertyPermission * read,write) at java.security.AccessController.checkPermission(AccessController.java:74) at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) at java.lang.SecurityManager.checkPropertiesAccess(SecurityManager.java:353) at java.lang.System.getProperties(System.java:252) at org.apache.derbyTesting.functionTests.harness.RunTest.execTestNoProcess(RunTest.java:2324) at org.apache.derbyTesting.functionTests.harness.RunTest.testRun(RunTest.java:442) at org.apache.derbyTesting.functionTests.harness.RunTest.main(RunTest.java:301) at org.apache.derbyTesting.functionTests.harness.RunList.runTests(RunList.java:550) at org.apache.derbyTesting.functionTests.harness.RunList.runSuites(RunList.java:306) at org.apache.derbyTesting.functionTests.harness.RunList.init(RunList.java:160) at org.apache.derbyTesting.functionTests.harness.RunSuite.getSuitesList(RunSuite.java:186) at org.apache.derbyTesting.functionTests.harness.RunSuite.main(RunSuite.java:146) I think this is happening after the change to install a SecurityManager when useprocess=false is specified. This property is specified in the properties file for nist suite. Before this change, security manager was not used when running tests in J2ME. Since this exception causes the test harness to exit, derbyall cannot be completed in this environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-701) Java 2 security policy file examples don't work -- are missing a needed line
[ http://issues.apache.org/jira/browse/DERBY-701?page=all ]
Jean T. Anderson resolved DERBY-701:
Fix Version: 10.2.0.0
Resolution: Fixed
Patch derby701-2.diff looks good -- and I actually ran the network server
example to make sure it works. Committed to the trunk, revision 374798.
Modified files:
$ svn status
M src/adminguide/tadminnetservrun.dita
M src/devguide/rdevcsecure871406.dita
M src/devguide/rdevcsecure871439.dita
M src/devguide/rdevcsecure871422.dita
Java 2 security policy file examples don't work -- are missing a needed line
Key: DERBY-701
URL: http://issues.apache.org/jira/browse/DERBY-701
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.1.1
Reporter: Jean T. Anderson
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby701-2.diff, derby701.diff, derby701_html_files-2.zip,
derby701_html_files.zip
These security policy file examples don't work as is:
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure871406.html
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure871422.html
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure871439.html
Each example needs this additional line:
permission java.io.FilePermission ${derby.system.home},read;
The email thread is here:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200511.mbox/[EMAIL
PROTECTED]
To show one of the examples, here is the current text for Example 1:
grant codeBase file://f:/derby/lib/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home}${/}-,
read,write,delete;
};
It needs to be this instead:
grant codeBase file://f:/derby/lib/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home},read;
permission java.io.FilePermission
${derby.system.home}${/}-,read,write,delete;
};
--
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-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=comments#action_12365160 ] Satheesh Bandaram commented on DERBY-761: - I have reviewed the changes... I think this patch is ready to be committed. The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Attachments: derby761-2.diff, derby761-3.diff, derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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-924) new JDBC4 metadata API getFunctions() needs to be implemented
new JDBC4 metadata API getFunctions() needs to be implemented - Key: DERBY-924 URL: http://issues.apache.org/jira/browse/DERBY-924 Project: Derby Type: New Feature Environment: JDK 1.6 Reporter: David Van Couvering For now I am implementing this to return empty result set so at least we're compliant, but we should be able to implement this one -- 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-701) Java 2 security policy file examples don't work -- are missing a needed line
[ http://issues.apache.org/jira/browse/DERBY-701?page=all ]
Jean T. Anderson closed DERBY-701:
--
Java 2 security policy file examples don't work -- are missing a needed line
Key: DERBY-701
URL: http://issues.apache.org/jira/browse/DERBY-701
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.1.1
Reporter: Jean T. Anderson
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby701-2.diff, derby701.diff, derby701_html_files-2.zip,
derby701_html_files.zip
These security policy file examples don't work as is:
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure871406.html
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure871422.html
http://db.apache.org/derby/docs/dev/devguide/rdevcsecure871439.html
Each example needs this additional line:
permission java.io.FilePermission ${derby.system.home},read;
The email thread is here:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200511.mbox/[EMAIL
PROTECTED]
To show one of the examples, here is the current text for Example 1:
grant codeBase file://f:/derby/lib/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home}${/}-,
read,write,delete;
};
It needs to be this instead:
grant codeBase file://f:/derby/lib/derby.jar {
permission java.lang.RuntimePermission createClassLoader;
permission java.util.PropertyPermission derby.*, read;
permission java.io.FilePermission ${derby.system.home},read;
permission java.io.FilePermission
${derby.system.home}${/}-,read,write,delete;
};
--
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-925) Implement new JDBC 4 metadata API getFunctionParameters()
Implement new JDBC 4 metadata API getFunctionParameters() - Key: DERBY-925 URL: http://issues.apache.org/jira/browse/DERBY-925 Project: Derby Type: New Feature Components: JDBC Environment: JDK 1.6 Reporter: David Van Couvering I am currently implementing this to return an empty result set so at least we're compliant, but we should be able to provide real metadata here. -- 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-925) Implement new JDBC 4 metadata API getFunctionParameters()
[ http://issues.apache.org/jira/browse/DERBY-925?page=all ] David Van Couvering updated DERBY-925: -- Component: JDBC Implement new JDBC 4 metadata API getFunctionParameters() - Key: DERBY-925 URL: http://issues.apache.org/jira/browse/DERBY-925 Project: Derby Type: New Feature Components: JDBC Environment: JDK 1.6 Reporter: David Van Couvering I am currently implementing this to return an empty result set so at least we're compliant, but we should be able to provide real metadata here. -- 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-924) new JDBC4 metadata API getFunctions() needs to be implemented
[ http://issues.apache.org/jira/browse/DERBY-924?page=all ] David Van Couvering updated DERBY-924: -- Component: JDBC Version: 10.2.0.0 new JDBC4 metadata API getFunctions() needs to be implemented - Key: DERBY-924 URL: http://issues.apache.org/jira/browse/DERBY-924 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Environment: JDK 1.6 Reporter: David Van Couvering For now I am implementing this to return empty result set so at least we're compliant, but we should be able to implement this one -- 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-925) Implement new JDBC 4 metadata API getFunctionParameters()
[ http://issues.apache.org/jira/browse/DERBY-925?page=all ] David Van Couvering updated DERBY-925: -- Version: 10.2.0.0 Implement new JDBC 4 metadata API getFunctionParameters() - Key: DERBY-925 URL: http://issues.apache.org/jira/browse/DERBY-925 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Environment: JDK 1.6 Reporter: David Van Couvering I am currently implementing this to return an empty result set so at least we're compliant, but we should be able to provide real metadata here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-761) The reserved words list in the reference manual doesn't look uptodate
[ http://issues.apache.org/jira/browse/DERBY-761?page=all ] Jean T. Anderson resolved DERBY-761: Fix Version: 10.2.0.0 Resolution: Fixed Committed derby761-3.diff to the trunk, revision 374803. Modified files: $ svn status M src/ref/rrefkeywords29722.dita The reserved words list in the reference manual doesn't look uptodate - Key: DERBY-761 URL: http://issues.apache.org/jira/browse/DERBY-761 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Fix For: 10.2.0.0 Attachments: derby761-2.diff, derby761-3.diff, derby761.diff, rrefkeywords29722.html I looked at the 10.1 reference manual's reserved word list and noticed keywords like BINARY, COALESCE missing from the list. Haven't checked the list thoroughly to see what else might be missing but it would be good to fix this for 10.2 -- 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
testing against jar files
I'm working on a feature which only surfaces if you are running against jar files. Is there a template for writing a test which only executes when derbyall runs against jar files? Thanks, -Rick
