Re: catch-22: Derby, Mustang, and JCP issue
On 6/22/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Isn't an implementation of JSR221 writing (clean room) classes in the java.sql and javax.sql name spaces. (e.g. java.sql.Driver & javax.sql.DataSource). Derby is not doing that, Derby is providing an implementation of a JDBC driver, not an implementation of JSR221 itself. Implementing JSR221 is something that Harmony would (might) do. My point is that the JCP rules for implementation of the spec itself do not apply here. +1 I agree, on rereading the JSPA agreement, the text I quoted in my previous email refers to independent implementations of the core classes covered by JSR-221. i.e. the java.sql.* classes, etc. Applications which happen to implement interfaces in those packages in their own namespace don't seem to be covered by anything in the JSPA. But, looking at the evaluation license you need to agree to download the spec, it contains this: Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification only for the purposes of evaluation. This license includes the right to discuss the Specification (including the right to provide limited excerpts of text to the extent relevant to the point[s] under discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. *Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property*, and the Specification may only be used in accordance with the license terms set forth herein. This license will expire on the earlier of: ... (ii) the date on which the final version of the Specification is publicly released; Presumably this is where the idea that you can't ship something that implements an interface in a JSR comes from, because you would have needed to copy material which is copyrighted by Sun, and to which you've agreed to this license to have knowledge of. Let's assume that the people who implemented the Derby implementations of the JDBC 4 interfaces are subject to this agreement. And, that this means that the method signatures described in the spec and any javadoc comments in the JDBC 4.0 spec are the IP in question here that we have 'acquired no right' to use. The method signatures in the Derby classes were clearly copied from the spec, and I believe perhaps some javadoc comments as well, although I would need to check that. Now, there are two things involved in our catch-22: * Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. Sun wants to release a version of Derby with the JDK that (I would assume) includes javadoc for Derby that includes material copied from the JDBC 4 spec. But if Sun shipping the JDK is the event which satisifes ' (ii) the date on which the final version of the Specification is publicly released' then the license above expires and the people who were reading the spec and copied parts of it into Derby are no longer bound by this agreement either. It's not clear what license is then in effect, but I would like to think that by virtue of the contributors in question, the ASL is the license in effect on that code, since it was contributed to Derby by employees of Sun under its CCLA and the various ICLAS in effect for the individual contributors. But then, IANAL. As far as the Derby bits that Sun ships in the JDK, well, it's not really Derby they've committed to shipping but JavaDB. So they can twiddle the bits as they see fit I suppose, as long as they don't call it an official Derby release anywhere in the JDK. I could imagine a situation where they simply flip the beta flag and update the version so that Derby reports itself as a 10.2.0.0 database at whatever revision it happens to be the day the JDK ships, along with the modified 'M' flag in the version string. If Sun says that all that did was ship the Derby code at that revision level with the necessary version bits modified, then anyone using the Derby bundled with the JDK will just have to believe them. If, say, that version happens to not upgrade to official Derby releases for some bizarre reason, then suddenly there are lots of new, irate users complaining that Derby is broken. This would make the Derby community look bad through no fault of its own (and Sun has a sticky problem to boot). Hopefully this won't be an issue, though. * Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. One modification here: Derby could ship a GA 10.2 any time it likes. Just not with the JDBC 4 bits. Nor would it want to, anyway, since besides the evaluation license probably covering material that Derby would be releaseing, Derby could possibly ship incorrect implementations of interfaces defined in the spec, and nobody in the community is interested in that. :-) But, once the spec i
Re: MySQL to Derby Migration Tool
Thanks for your comments, Jean. I would like to add that using DatabaseMetaData, I am able to find primary keys and foreign keys using the methods getPrimaryKeys and getImportedKeys, but have not been able to find a way to find out other details of a table specified in the original create statement such as CHECK constraint. Comments are appreciated... Thanks much, Ramin Moazeni On 6/22/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote: Ramin Moazeni wrote: > Hello, > > I am a Google Summer of code participant working on the Derby > Migration tool project. The High level design document is posted at > http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument It's great to see you doing this! > There are 2 approaches described in the document -- one based on the use > DatabaseMetaData class and the other is based on the use ddlUtils tool > (http://db.apache.org/ddlutils) which is also an apache project. In the "Approach 2: Using DdlUtils" section of http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument , there is this description: In order to use DdlUtils component to migrate the source database to the target database, following steps are suggested: * Capture DDL file from DdlUtils. * Modify the source DDL to the target DDL using Serialization and Deserialization of XML. * Fed in the new DDL file to the DdlUtils. If the intent is to use the XML DDL file generated by DdlUtils, technically there should be no need to modify it for the target database -- except that there are a few issues that would need to be watched for, such as Derby doesn't support a boolean type. At any rate, the Java app can read the database model from the XML file, or even from the "live database" (see http://db.apache.org/ddlutils/api-usage.html#Reading+the+model+from+a+live+database ), then write that database model to the target. The DdlUtils code takes care of producing the SQL required to create the tables in the new database. > Please note that the DdlUtils doesn't support non-table entities, constraints, triggers, stored procedures, etc. DdlUtils supports primary and foreign key constraints, but not check constraints. Given its limitations, your DatabaseMetaData approach might be more complete. But if you can use any pieces from DdlUtils, you should feel free to do so (with all the correct attributions, of course) since it is under the ASL 2.0. -jean
Re: catch-22: Derby, Mustang, and JCP issue
Brian McCallister wrote: > > On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote: > >> "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes >> final." >> >> Where does this restriction come from? > > > Until a spec is final I don't see how you can have a certified compliant > implementation of that spec. Agreed, and I'm not sure that there is any requirement for Derby to have a certified compliant JDBC driver. Sure it would be great to have a certified driver, but it's not a requirement for a Derby release. > It might be as easy as not claiming JDBC 4.0 > compliance until *after* JSR-221 is final, than saying, "huh, gee whiz, > we pass the TCK!" Except there is no TCK for compliance of a JDBC 4.0 driver. I believe the compliance for a driver is only described by text in the JDBC 4.0 spec. The JSR221 TCK is for compliance of the JDBC 4.0 apis. > If the interfaces happen to exist in a release before the spec is final, > well, cool. Folks using them are at risk of the spec changing at the last > minute, so I would put bright red warnings around them if they are event > documented before the official release of the spec (not of Derby). +1 Dan.
Re: catch-22: Derby, Mustang, and JCP issue
Geir Magnusson Jr wrote: > Daniel John Debrunner wrote: > >>Jean T. Anderson wrote: >> >> >>>David posted a good summary of the legal catch-22 at [1]. But the >>>shortest story is: >>> >>> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. >>> + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. >>> >>>Let's keep this thread confined to the JCP issue Andrew raised that to >>>roll a release candidate qualifies as "creation".[2] And those release >>>candidates will be generally available. >> >>I don't think the JCP rules apply since we are not creating an >>implementation of JSR221. > > > How could that be? Where did the information for the APIs come from? Isn't an implementation of JSR221 writing (clean room) classes in the java.sql and javax.sql name spaces. (e.g. java.sql.Driver & javax.sql.DataSource). Derby is not doing that, Derby is providing an implementation of a JDBC driver, not an implementation of JSR221 itself. Implementing JSR221 is something that Harmony would (might) do. My point is that the JCP rules for implementation of the spec itself do not apply here. >>I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver >>until Mustang goes GA, but that's not the JCP rules that Andrew provided >>references to. It would be good to get Lance to expand on what he meant >>when he said: >> >>"You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final." >> >>Where does this restriction come from? > > > I'm not sure. The license on the public review draft gives no rights to > distribute an implementation under *any* label (more recent public > review draft licenses do now after the whole EJB3 brouhaha) My point is "implementation" of what exactly. I think Lance (JSR221 spec lead) has already said that the TCK for JSR221 just checks the the classes (java.sql etc.) exist and have the correct methods & signatures, that implies to me that implementing JSR221 means providing those classes. Dan.
Re: catch-22: Derby, Mustang, and JCP issue
Kathey Marsden wrote: > Brian McCallister wrote: > >> If the interfaces happen to exist in a release before the spec is final, >> well, cool. Folks using them are at risk of the spec changing at the >> last >> minute, so I would put bright red warnings around them if they are event >> documented before the official release of the spec (not of Derby). >> > +1 > - We have a Derby 10.2 GA release with any JDBC 4.0 functionality marked > as USE AT YOUR OWN RISK, just part of incremental devlopment and totally > subject to change if the spec does. > - Mustang takes that and runs with it. > - Then we have a follow up release, yes even two months later where we > are certified compliant. > > A nice clean 2 phase commit. I haven't read the legal stuff, but does > this not work? It works, but if you want to be technical about it, not really. Because of the license Sun chose for the public draft for JDBC4, you can't actually implement and distribute it. Of course, as the licensor, Sun could offer a 'clarification' of that license and allow implementations of the public draft, and that would at least let us legally ship it. The cleanest way seem to just remove the JDBC4 stuff from the upcoming GA release, and then release a JDBC4 driver as fast as you can once you have the final spec and a TCK. geir
Re: catch-22: Derby, Mustang, and JCP issue
Brian McCallister wrote: If the interfaces happen to exist in a release before the spec is final, well, cool. Folks using them are at risk of the spec changing at the last minute, so I would put bright red warnings around them if they are event documented before the official release of the spec (not of Derby). +1 - We have a Derby 10.2 GA release with any JDBC 4.0 functionality marked as USE AT YOUR OWN RISK, just part of incremental devlopment and totally subject to change if the spec does. - Mustang takes that and runs with it. - Then we have a follow up release, yes even two months later where we are certified compliant. A nice clean 2 phase commit. I haven't read the legal stuff, but does this not work? Kathey
Re: catch-22: Derby, Mustang, and JCP issue
Brian McCallister wrote: > > On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote: > >> "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes >> final." >> >> Where does this restriction come from? > > Until a spec is final I don't see how you can have a certified compliant > implementation of that spec. It might be as easy as not claiming JDBC 4.0 > compliance until *after* JSR-221 is final, than saying, "huh, gee whiz, > we pass the TCK!" The only problem I see is that by the letter of the law, there is no right to implement and distribute JDBC4's public draft. I guess the first thing to figure out is what from the JDBC4 expert group has actually been implemented. > > If the interfaces happen to exist in a release before the spec is final, > well, cool. Sun used to have some strange arguments about spec API copyrights which made that uncool unless you passed the TCK (which implied completion of the JSR) > Folks using them are at risk of the spec changing at the last > minute, so I would put bright red warnings around them if they are event > documented before the official release of the spec (not of Derby). Or just leave JDBC4 out of the GA release, and given it's only a database driver, just offer it as a second jar when it's possible to do so. Why tie the DB release cycle to an updated driver? Won't a JDBC3 driver work well too? geir
Re: catch-22: Derby, Mustang, and JCP issue
Daniel John Debrunner wrote: > Jean T. Anderson wrote: > >> David posted a good summary of the legal catch-22 at [1]. But the >> shortest story is: >> >> + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. >> + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. >> >> Let's keep this thread confined to the JCP issue Andrew raised that to >> roll a release candidate qualifies as "creation".[2] And those release >> candidates will be generally available. > > I don't think the JCP rules apply since we are not creating an > implementation of JSR221. How could that be? Where did the information for the APIs come from? > > I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver > until Mustang goes GA, but that's not the JCP rules that Andrew provided > references to. It would be good to get Lance to expand on what he meant > when he said: > > "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final." > > Where does this restriction come from? I'm not sure. The license on the public review draft gives no rights to distribute an implementation under *any* label (more recent public review draft licenses do now after the whole EJB3 brouhaha) > > Dan. > >> How do we handle this cleanly? I would assume that you just don't ship a JDBC 4 driver with the release of Derby, and do a release when the spec is final and a TCK can be obtained from the spec lead to ensure that the implementation is compatible with the spec. It's just a driver. The database is fully functional w/o it, right? Seems to be fairly simple. geir >> >> -jean >> >> >> [1] >> http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html >> [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html >> > > > >
Re: catch-22: Derby, Mustang, and JCP issue
Jean T. Anderson wrote: > David posted a good summary of the legal catch-22 at [1]. But the > shortest story is: > > + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. > + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. > > Let's keep this thread confined to the JCP issue Andrew raised that to > roll a release candidate qualifies as "creation".[2] And those release > candidates will be generally available. > > How do we handle this cleanly? > > -jean > > > [1] > http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html > [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html I goofed up these URLs and both point to the start of the thread. I meant to point to these: [1] http://www.nabble.com/Re%3A-Proposal-for-10.2-release-schedule-p5003242.html [2] http://www.nabble.com/Re%3A-Proposal-for-10.2-release-schedule-p5003602.html
Re: catch-22: Derby, Mustang, and JCP issue
On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote: "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final." Where does this restriction come from? Until a spec is final I don't see how you can have a certified compliant implementation of that spec. It might be as easy as not claiming JDBC 4.0 compliance until *after* JSR-221 is final, than saying, "huh, gee whiz, we pass the TCK!" If the interfaces happen to exist in a release before the spec is final, well, cool. Folks using them are at risk of the spec changing at the last minute, so I would put bright red warnings around them if they are event documented before the official release of the spec (not of Derby). -Brian
Re: catch-22: Derby, Mustang, and JCP issue
Jean T. Anderson wrote: > David posted a good summary of the legal catch-22 at [1]. But the > shortest story is: > > + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. > + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. > > Let's keep this thread confined to the JCP issue Andrew raised that to > roll a release candidate qualifies as "creation".[2] And those release > candidates will be generally available. I don't think the JCP rules apply since we are not creating an implementation of JSR221. I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver until Mustang goes GA, but that's not the JCP rules that Andrew provided references to. It would be good to get Lance to expand on what he meant when he said: "You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final." Where does this restriction come from? Dan. > > How do we handle this cleanly? > > -jean > > > [1] > http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html > [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html >
catch-22: Derby, Mustang, and JCP issue
David posted a good summary of the legal catch-22 at [1]. But the shortest story is: + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0. + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang. Let's keep this thread confined to the JCP issue Andrew raised that to roll a release candidate qualifies as "creation".[2] And those release candidates will be generally available. How do we handle this cleanly? -jean [1] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html
Re: Proposal for 10.2 release schedule
Hi,Jean commented on David's post:... In order for this to work, we need Java DB to be based on an official,"GA-ready" release of Derby to be what Sun redistributes in Mustang.Otherwise databases created in Mustang will be "locked in" to Java DB.The problem is that it can't *actually* be GA until after JCP approvesJSR 221, JDBC 4.0, which will happen in tandem with the GA release ofthe JDK, around 5 weeks after the JDK team needs their final integrationbits from all the pieces going into it. in other words, we have a classic catch-22. :-)No, not at all. What happens right now is that we publish a release candidate that is available for the Derby community to test and vote on. Once the vote is complete, the release manager ties up some of the loose ends (records the vote results, pushes the bits around) and publishes the release on the Apache mirrors. Subsequently, other loose ends are tied (official announcement on Apache general email alias).What Rick is proposing to happen is for the community to vote and subsequently tie up some loose ends (record the vote results, send the bits to the Mustang folks instead of to the Apache mirrors). Once the Mustang release is official, continue tying up loose ends (publish the release on the Apache mirrors). And more loose ends (official announcement on Apache general email alias). So the only thing that changes compared to today is the delay that Rick mentioned between community approval of the bits and posting the bits to the Apache mirrors. I think what Rick is asking for is a release that is voted as"GA-ready", has the GA-bit turned on, but because of JCP rules is notactually *made* generally available until JSR 220 becomes final. Sincewe all need to vet this release and approve it, it would be available tothe Derby community, but not *generally* available by distributing it onall the Apache mirrors. It would still be easily available. And once downloaded, and probablyredistributed further, downstream users would have no idea that theyaren't working with an official Apache release.As I understand it, this is what happens today. Once the release candidate is announced, anyone can theoretically grab the bits and distribute them before the release is voted on and available from the mirrors. Is this considered a problem today?What is the specific legal verbiage we're working with here?IANAL, but the only license available right now (the license under which the community is using the bits) is an evaluation license for JSR 221, which reads, in part:Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification only for the purposes of evaluation.Until Mustang goes GA, there is no redistribution license available.Craig -jean I know this seems like a fine hair to split, but it's the only way wecan be successful without Sun having to do a non-upgradable fork ofDerby, which I don't think any of us want.I hope this helps to clear things up, even if it doesn't make thingssimpler :)David Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Proposal for 10.2 release schedule
David Van Couvering wrote: Lance J. Andersen wrote: You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. Are you *sure* you can't *have* a GA version, e.g the bits can't exist somewhere, as long as they're not officially declared generally available? If we can't even create the bits, then it is physically and logically impossible for us to give anything to the JDK team for integration. I think we are talking different things here as you are talking about getting your final version of your product ready to be released based on a JSR which is getting ready to go final , which is fine, which is different from what i was trying to say. http://jcp.org/en/resources/guide#fab gives you an overview of how a JSR goes final. Personally, I think we need to get clarification from the JCP folks on this before we make any final conclusions about this. Thanks, David
Re: Proposal for 10.2 release schedule
That said, it's probably also good to hear from the JCP as well. It would probably help the ASF gauge what their exposure is and what approaches they feel comfortable with. David David Van Couvering wrote: OK, good point, thanks. David Daniel John Debrunner wrote: David Van Couvering wrote: Andrew McIntyre wrote: Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. From the ASF point of view, which is what we are discussing here, I rather think Geir is the "horse's mouth". It's the ASF's interpretation of the licence the ASF signed and the risks the ASF is willing to take that matter with a Apache Derby release. Dan.
Re: Proposal for 10.2 release schedule
Hi, Lance. Sorry I had to challenge you publicly on the list, but I'm really worried that if we're not very careful we are going to paint ourselves into a corner and we are going to have to fork Derby in order to do a Java DB release. I think we need the JCP lawyers (and it sounds like the ASF lawyers) to weigh in on this question before we make any conclusions that could cause us real trouble. Thanks, David David Van Couvering wrote: Lance J. Andersen wrote: You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. Are you *sure* you can't *have* a GA version, e.g the bits can't exist somewhere, as long as they're not officially declared generally available? If we can't even create the bits, then it is physically and logically impossible for us to give anything to the JDK team for integration. Personally, I think we need to get clarification from the JCP folks on this before we make any final conclusions about this. Thanks, David
Re: Proposal for 10.2 release schedule
OK, good point, thanks. David Daniel John Debrunner wrote: David Van Couvering wrote: Andrew McIntyre wrote: Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. From the ASF point of view, which is what we are discussing here, I rather think Geir is the "horse's mouth". It's the ASF's interpretation of the licence the ASF signed and the risks the ASF is willing to take that matter with a Apache Derby release. Dan.
Re: Proposal for 10.2 release schedule
Lance J. Andersen wrote: You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. Are you *sure* you can't *have* a GA version, e.g the bits can't exist somewhere, as long as they're not officially declared generally available? If we can't even create the bits, then it is physically and logically impossible for us to give anything to the JDK team for integration. Personally, I think we need to get clarification from the JCP folks on this before we make any final conclusions about this. Thanks, David
Re: Proposal for 10.2 release schedule
David Van Couvering wrote: > Andrew McIntyre wrote: >> Or maybe ask Geir, since he's VP of Java Community Process for the >> Apache Software Foundation, since similar instances may have come up >> fairly recently. [3] >> > > Even if we did ask Geir, he's not the last word on it. I'd rather hear > it from the horse's mouth. I or someone else will get back to you. >From the ASF point of view, which is what we are discussing here, I rather think Geir is the "horse's mouth". It's the ASF's interpretation of the licence the ASF signed and the risks the ASF is willing to take that matter with a Apache Derby release. Dan.
Re: Proposal for 10.2 release schedule
that was MUCH clearer than what rick wrote.. thanks David Van Couvering wrote: Ok, this is very tricky. First, I'd like to make sure we're on the same page here about Java DB going into the JDK. I think in general the community thinks it's a good thing for Derby for Java DB to be in the JDK. It gives us great exposure and distribution. I also think the community would probably like it if databases created by the version of Java DB to be upgradable to a subsequent release of Derby, so that users can get the latest and greatest functionality of Derby directly from the Apache web site, or even upgrade to a future release of Cloudscape if they decide to get support from IBM. In order for this to work, we need Java DB to be based on an official, "GA-ready" release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be "locked in" to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. I think what Rick is asking for is a release that is voted as "GA-ready", has the GA-bit turned on, but because of JCP rules is not actually *made* generally available until JSR 220 becomes final. Since we all need to vet this release and approve it, it would be available to the Derby community, but not *generally* available by distributing it on all the Apache mirrors. I know this seems like a fine hair to split, but it's the only way we can be successful without Sun having to do a non-upgradable fork of Derby, which I don't think any of us want. I hope this helps to clear things up, even if it doesn't make things simpler :) David Daniel John Debrunner wrote: Rick Hillegas wrote: Daniel John Debrunner wrote: The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements. Sorry if I'm being dense. Dan. -- Rob Stephens Chief of Staff, Database Technology Group OPG Sun Microsystems, Inc. Bay Area, California US Phone 1-877-244-4740 or x51734 Mobile 1-510-928-2996 Fax 1-877-244-4740 Email [EMAIL PROTECTED]
Re: Proposal for 10.2 release schedule
Daniel John Debrunner wrote: Andrew McIntyre wrote: Call in the lawyers: From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board has executed, being a JCP Member (they've even got quotes from Geir prominently featured on their "about JCP 2.6 page" [2]): 5.B. License to Create Independent Implementations. Dumb question, is Derby: - creating an independent implementation of JSR221 - or is it implementing a driver that adheres to JSR221? I would say Apache Harmony (when/if they tackle Jave SE 6) would be creating an independent implementation of JSR221 and that Derby is not. You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final. The Derby Embedded and Network Client drivers provide implementations of the JDBC drivers based on JSR 221. A Java SE implementation provides the interfaces and concrete classes that are used by a JDBC driver for the given Java SE implementation. JSR 221 falls under the umbrella spec for Java SE 6. They all go final together. Dan.
Re: Proposal for 10.2 release schedule
Andrew McIntyre wrote: Anyway, what's the trigger for breaching the contract here? If it's 'creation' alone, then rolling that release candidate surely qualifies as as creation. If it's 'creation and distribution,' well, is posting the release candidate in a public forum and on a public website (like one would have to do to vote on it) considered distribution in this case? I have no idea, because i'm not a lawyer. I don't either. I will try and get someone here to discuss this with the JCP lawyers and try and get some clarification about 'creation' vs. 'creation and distribution'. I can't see how you can be in trouble for creating a set of bits that nobody has access to, but IANAL. I guess you have somewhat answered my question from my other email: you must, even temporarily, make the official GA bits available for download, just so we can vote on the release. Could we remove the download once it's voted on, at least to keep the window of vulnerability to a minimum? I'm not saying that would satisfy the lawyers, but I'd like to know what is possible before we talk to them. How do we handle this normally, if you create a release candidate with the GA bit set, and then we reject the release. Don't we have the same problem already, with people getting access to a release that looks and smells like an official Apache release but actually isn't? Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] Even if we did ask Geir, he's not the last word on it. I'd rather hear it from the horse's mouth. I or someone else will get back to you. Thanks for all your input, and your research! andrew p.s. I'm assuming there's no TCK for JSR-221. P.S. I am pretty sure there is, but as I understand it, it just validates the interfaces are there. It's part of the overall TCK for Java SE 6, is my understanding. I am sure Lance will be happy to clarify. [1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf [2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html [3] http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt (search for "SUN ISSUES")
[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.
[ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417392 ] Kathey Marsden commented on DERBY-1434: --- Wish I could delete the comment but the early closed result set with is issue is not a valid symptom. This wrong line caused the test to fail. Should have been ps2. ResultSet rs2 = ps.executeQuery(); > Client can send incorrect database name to server after having made multiple > connections to different databases. > > > Key: DERBY-1434 > URL: http://issues.apache.org/jira/browse/DERBY-1434 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.2.0.0, 10.1.3.0, 10.1.2.5 > Reporter: A B > Fix For: 10.2.0.0 > Attachments: Server2.trace, _driver_1, d1434.java > > I have a simple program that connects to a database using the Derby Client, > executes a simple query, then connects to a different database using a > different Connection object and executes another simple query on that second > connection. The queries both execute without error, so it appears that the > connections are correct--i.e. each query will only work on one of the > databases, and both queries work, therefore each must be getting executed > against the correct database. > But in looking at the client and server traces, I noticed that for the query > on the second database, the client is actually sending the name of the > *first* database as RDBNAM, which (I think?) is wrong--it should be sending > the name of the second database, since the query is being executed on the > second Connection object. > This behavior does not appear to occur for JCC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposal for 10.2 release schedule
Jean and Dan, you raise good points (a) what happens if someone downloads this "GA-ready but not GA" release of Derby. If for some reason we have to do a respin of the release (see (b)), how will they later know that it's not actually an official release of Apache? (b) is there a possibility, however, slight, that the JDBC spec could change after we have marked a release "GA-ready" I think these are great points for discussion. I get the sense that we all want to make this work, but are not sure how just yet. I have a suggestion, and I'm sure I'm missing something, but here goes. Is there a way we can vote on the release, and if it passes, Rick can flip the GA bit, sign it and put it on the shelf, but not make it available for download, even from the Derby site? This would allow us to re-spin if necessary (although I don't think it's likely) due to a last-minute change to JDBC, and would prevent a user from ending up with a release that looks and smells like it's an official Apache release but actually isn't. David Daniel John Debrunner wrote: Jean T. Anderson wrote: David Van Couvering wrote: ... In order for this to work, we need Java DB to be based on an official, "GA-ready" release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be "locked in" to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. in other words, we have a classic catch-22. :-) Are there any dates around JDBC 4.0/JSR221 that need to be factored in? I'm curious as to how we can vote on the release that's supporting JDBC 4.0 if the spec isn't final and/or generally available for people to read. Maybe we would be just voting on the current functionality of *Derby* and if it happens to match JDBC 4.0 that's a bonus. Dan.
Re: Proposal for 10.2 release schedule
Andrew McIntyre wrote: > Call in the lawyers: > >> From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board > > has executed, being a JCP Member (they've even got quotes from Geir > prominently featured on their "about JCP 2.6 page" [2]): > > 5.B. License to Create Independent Implementations. Dumb question, is Derby: - creating an independent implementation of JSR221 - or is it implementing a driver that adheres to JSR221? I would say Apache Harmony (when/if they tackle Jave SE 6) would be creating an independent implementation of JSR221 and that Derby is not. Dan.
Re: Proposal for 10.2 release schedule
On 6/22/06, Rick Hillegas <[EMAIL PROTECTED]> wrote: >> I think we want that database to play well with the approved >> release candidate which goes GA. >> >> > >The mid-Sep Derby release candidate will be marked alpha or beta (JCP >rules) so the databases won't upgrade anyway. > > I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. A release candidate that the Derby community votes on would not be marked alpha/beta by necessity. A vote on a release candidate is for that set of bits to become the release. If the release candidate is marked alpha/beta, and that's what people had voted on, and then the RM rebuilds the distributions to change the version string and publishes that, then the RM would be publishing something that the community had not vetted. Not a good idea. Elsewhere, Daniel John Debrunner wrote: Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements Call in the lawyers: From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board has executed, being a JCP Member (they've even got quotes from Geir prominently featured on their "about JCP 2.6 page" [2]): 5.B. License to Create Independent Implementations. For any Specification produced under a new JSR, the Spec Lead for such JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights in and patent claims covering the Specification (including rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to anyone who wishes to create and/or distribute an Independent Implementation of the Spec. Such license will authorize the creation and distribution of Independent Implementations provided such Independent Implementations: (a) fully implement the Spec(s) including all its required interfaces and functionality; (b) do not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Spec or Specs being implemented; and (c) pass the TCK for such Spec. So, all we really need is for Lance, as Spec Lead, to indemnify the ASF from any legal action regarding Derby's implementation of the JDBC 4 spec. Hey Lance, just send a note to the ASF Board that Sun's not going to sue the ASF. Thanks! ;o) Anyway, what's the trigger for breaching the contract here? If it's 'creation' alone, then rolling that release candidate surely qualifies as as creation. If it's 'creation and distribution,' well, is posting the release candidate in a public forum and on a public website (like one would have to do to vote on it) considered distribution in this case? I have no idea, because i'm not a lawyer. Or maybe ask Geir, since he's VP of Java Community Process for the Apache Software Foundation, since similar instances may have come up fairly recently. [3] andrew p.s. I'm assuming there's no TCK for JSR-221. [1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf [2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html [3] http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt (search for "SUN ISSUES")
Re: Proposal for 10.2 release schedule
Jean T. Anderson wrote: > David Van Couvering wrote: > ... > >>In order for this to work, we need Java DB to be based on an official, >>"GA-ready" release of Derby to be what Sun redistributes in Mustang. >>Otherwise databases created in Mustang will be "locked in" to Java DB. >> >>The problem is that it can't *actually* be GA until after JCP approves >>JSR 221, JDBC 4.0, which will happen in tandem with the GA release of >>the JDK, around 5 weeks after the JDK team needs their final integration >>bits from all the pieces going into it. > > > in other words, we have a classic catch-22. :-) Are there any dates around JDBC 4.0/JSR221 that need to be factored in? I'm curious as to how we can vote on the release that's supporting JDBC 4.0 if the spec isn't final and/or generally available for people to read. Maybe we would be just voting on the current functionality of *Derby* and if it happens to match JDBC 4.0 that's a bonus. Dan.
Re: Proposal for 10.2 release schedule
David Van Couvering wrote: ... > In order for this to work, we need Java DB to be based on an official, > "GA-ready" release of Derby to be what Sun redistributes in Mustang. > Otherwise databases created in Mustang will be "locked in" to Java DB. > > The problem is that it can't *actually* be GA until after JCP approves > JSR 221, JDBC 4.0, which will happen in tandem with the GA release of > the JDK, around 5 weeks after the JDK team needs their final integration > bits from all the pieces going into it. in other words, we have a classic catch-22. :-) > I think what Rick is asking for is a release that is voted as > "GA-ready", has the GA-bit turned on, but because of JCP rules is not > actually *made* generally available until JSR 220 becomes final. Since > we all need to vet this release and approve it, it would be available to > the Derby community, but not *generally* available by distributing it on > all the Apache mirrors. It would still be easily available. And once downloaded, and probably redistributed further, downstream users would have no idea that they aren't working with an official Apache release. What is the specific legal verbiage we're working with here? -jean > I know this seems like a fine hair to split, but it's the only way we > can be successful without Sun having to do a non-upgradable fork of > Derby, which I don't think any of us want. > > I hope this helps to clear things up, even if it doesn't make things > simpler :) > > David
[jira] Created: (DERBY-1443) DataTypeDescriptor.isBinaryType() return false for Types.BLOB
DataTypeDescriptor.isBinaryType() return false for Types.BLOB - Key: DERBY-1443 URL: http://issues.apache.org/jira/browse/DERBY-1443 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.1.2.4, 10.1.2.5 Reporter: Steve Taylor DataTypeDescriptor.isBinaryType() return false for Types.BLOB. Surely BLOB is a binary type and so method should return true? -- 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: Proposal for 10.2 release schedule
Ok, this is very tricky. First, I'd like to make sure we're on the same page here about Java DB going into the JDK. I think in general the community thinks it's a good thing for Derby for Java DB to be in the JDK. It gives us great exposure and distribution. I also think the community would probably like it if databases created by the version of Java DB to be upgradable to a subsequent release of Derby, so that users can get the latest and greatest functionality of Derby directly from the Apache web site, or even upgrade to a future release of Cloudscape if they decide to get support from IBM. In order for this to work, we need Java DB to be based on an official, "GA-ready" release of Derby to be what Sun redistributes in Mustang. Otherwise databases created in Mustang will be "locked in" to Java DB. The problem is that it can't *actually* be GA until after JCP approves JSR 221, JDBC 4.0, which will happen in tandem with the GA release of the JDK, around 5 weeks after the JDK team needs their final integration bits from all the pieces going into it. I think what Rick is asking for is a release that is voted as "GA-ready", has the GA-bit turned on, but because of JCP rules is not actually *made* generally available until JSR 220 becomes final. Since we all need to vet this release and approve it, it would be available to the Derby community, but not *generally* available by distributing it on all the Apache mirrors. I know this seems like a fine hair to split, but it's the only way we can be successful without Sun having to do a non-upgradable fork of Derby, which I don't think any of us want. I hope this helps to clear things up, even if it doesn't make things simpler :) David Daniel John Debrunner wrote: Rick Hillegas wrote: Daniel John Debrunner wrote: The mid-Sep Derby release candidate will be marked alpha or beta (JCP rules) so the databases won't upgrade anyway. I apologize for creating confusion here. We'd like Mustang to ship with a fully functional Derby, which creates upgradeable databases. So I'm assuming that we turn off the beta marker on the vetted candidate before handing the candidate to Mustang for QA bake-in. Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements. Sorry if I'm being dense. Dan.
[jira] Updated: (DERBY-1320) Test lang/procedure.java fails with ibm1.5 jvm
[ http://issues.apache.org/jira/browse/DERBY-1320?page=all ] Manjula Kutty updated DERBY-1320: - Attachment: procedure.java > Test lang/procedure.java fails with ibm1.5 jvm > -- > > Key: DERBY-1320 > URL: http://issues.apache.org/jira/browse/DERBY-1320 > Project: Derby > Type: Bug > Components: Unknown, Regression Test Failure > Versions: 10.2.0.0 > Environment: IBM 1.5 JVM /linux > Reporter: Sunitha Kambhampati > Priority: Minor > Fix For: 10.2.0.0 > Attachments: procedure.diff, procedure.java > > lang/procedure.java fails on IBM1.5 jvm on linux machine.I spoke to > Manjula who filed DERBY-1108 that this is related to that issue and is a JVM > bug. The JVM team has been notified.Please note: I have marked this as a > Regression Test Failure although this test has not passed with IBM 1.5 JVM > atleast in our nightly regression test runs, so it is not a regression of > the product. > diff: > * Diff file derbyall/derbylang/procedure.diff > *** Start: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:16 *** > 1018 del > < testImplicitClose(): PASSED > 1018 add > > testImplicitClose(): FAILED (no exception thrown) > Test Failed. > *** End: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:31 *** > here is machine info. > -- Java Information -- > Java Version:1.5.0 > Java Vendor: IBM Corporation > Java home: /local1/cloudtst/dev/src/ibm15/jre > Java classpath: > /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst/dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbynet.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/local1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.jar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar: > OS name: Linux > OS architecture: x86 > OS version: 2.6.5-7.252-bigsmp > Java user name: cloudtst > Java user home: /u/cloudtst > Java user dir: > /local1/cloudtst/dev/src/NightlyBuildResults.2006-05-10/ibm15_derbyall > java.specification.name: Java Platform API Specification > java.specification.version: 1.5 > - Derby Information > JRE - JDBC: J2SE 5.0 - JDBC 3.0 > [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.0 alpha - (405653) > [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.0 alpha - > (405653) > [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.0 alpha - (405653) > [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.0 alpha - > (405653) > [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90) > [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90) > -- -- 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-1320) Test lang/procedure.java fails with ibm1.5 jvm
[ http://issues.apache.org/jira/browse/DERBY-1320?page=all ] Manjula Kutty updated DERBY-1320: - Attachment: procedure.diff I thought the same fix for setTransactionIsolation will work for this test too. But no..When I apply the same change here I'm getting a different diff. I'm attaching the diff and also the test code > Test lang/procedure.java fails with ibm1.5 jvm > -- > > Key: DERBY-1320 > URL: http://issues.apache.org/jira/browse/DERBY-1320 > Project: Derby > Type: Bug > Components: Unknown, Regression Test Failure > Versions: 10.2.0.0 > Environment: IBM 1.5 JVM /linux > Reporter: Sunitha Kambhampati > Priority: Minor > Fix For: 10.2.0.0 > Attachments: procedure.diff, procedure.java > > lang/procedure.java fails on IBM1.5 jvm on linux machine.I spoke to > Manjula who filed DERBY-1108 that this is related to that issue and is a JVM > bug. The JVM team has been notified.Please note: I have marked this as a > Regression Test Failure although this test has not passed with IBM 1.5 JVM > atleast in our nightly regression test runs, so it is not a regression of > the product. > diff: > * Diff file derbyall/derbylang/procedure.diff > *** Start: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:16 *** > 1018 del > < testImplicitClose(): PASSED > 1018 add > > testImplicitClose(): FAILED (no exception thrown) > Test Failed. > *** End: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:31 *** > here is machine info. > -- Java Information -- > Java Version:1.5.0 > Java Vendor: IBM Corporation > Java home: /local1/cloudtst/dev/src/ibm15/jre > Java classpath: > /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst/dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbynet.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/local1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.jar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar: > OS name: Linux > OS architecture: x86 > OS version: 2.6.5-7.252-bigsmp > Java user name: cloudtst > Java user home: /u/cloudtst > Java user dir: > /local1/cloudtst/dev/src/NightlyBuildResults.2006-05-10/ibm15_derbyall > java.specification.name: Java Platform API Specification > java.specification.version: 1.5 > - Derby Information > JRE - JDBC: J2SE 5.0 - JDBC 3.0 > [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.0 alpha - (405653) > [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.0 alpha - > (405653) > [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.0 alpha - (405653) > [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.0 alpha - > (405653) > [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90) > [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90) > -- -- 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-959) Allow use of DRDA QRYDTA block sizes greater than 32K
[ http://issues.apache.org/jira/browse/DERBY-959?page=all ] Mike Matrigali updated DERBY-959: - I missed one file new file in previous commit, here is the svn commit for it: m1_142:155>svn commit Adding java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\values64kblksz.inc Transmitting file data . Committed revision 416486. > Allow use of DRDA QRYDTA block sizes greater than 32K > - > > Key: DERBY-959 > URL: http://issues.apache.org/jira/browse/DERBY-959 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Versions: 10.1.1.0, 10.2.0.0, 10.1.1.1, 10.1.1.2 > Reporter: Bryan Pendleton > Priority: Minor > Fix For: 10.2.0.0 > Attachments: 959Notes_v1.html, SmallRows_32kBlkSz.trace, > SmallRows_64kBlkSz.trace, derby959.review.diff.txt, derby959.review.stat.txt, > odbc_rowgreaterthan64k.trace > > Currently, the Network Server and Network Client use a 32K blocksize when > returning database data in QRYDTA blocks. > I came across the following statement in the DRDA spec (Volume 1, page 12): > Blocking applies only to the QRYDTA reply objects. Each > query block is a QRYDTA DSS. The maximum query block size > value allowed in the qryblksz parameter is increased from > 32K to 10M, thus accomodating the larger data volumes > required by modern, more data-intensive applications. > The importance of larger block sizes depends strong on the application > profile.. For example, many applications perform single-record selects, > and they are not influenced by the block size. > But for some applications, it seems like the ability to use a larger block > size could be quite valuable. -- 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-959) Allow use of DRDA QRYDTA block sizes greater than 32K
[ http://issues.apache.org/jira/browse/DERBY-959?page=all ] Mike Matrigali updated DERBY-959: - Fix Version: 10.2.0.0 I committed the xxx patch to the trunk: m1_142:151>svn commit Sendingjava\drda\org\apache\derby\impl\drda\CodePoint.java Sending java\testing\org\apache\derbyTesting\functionTests\master\testProtocol.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\protocol.tests Sending java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testProtocol_app.properties Transmitting file data Committed revision 416485. > Allow use of DRDA QRYDTA block sizes greater than 32K > - > > Key: DERBY-959 > URL: http://issues.apache.org/jira/browse/DERBY-959 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Versions: 10.1.1.0, 10.2.0.0, 10.1.1.1, 10.1.1.2 > Reporter: Bryan Pendleton > Priority: Minor > Fix For: 10.2.0.0 > Attachments: 959Notes_v1.html, SmallRows_32kBlkSz.trace, > SmallRows_64kBlkSz.trace, derby959.review.diff.txt, derby959.review.stat.txt, > odbc_rowgreaterthan64k.trace > > Currently, the Network Server and Network Client use a 32K blocksize when > returning database data in QRYDTA blocks. > I came across the following statement in the DRDA spec (Volume 1, page 12): > Blocking applies only to the QRYDTA reply objects. Each > query block is a QRYDTA DSS. The maximum query block size > value allowed in the qryblksz parameter is increased from > 32K to 10M, thus accomodating the larger data volumes > required by modern, more data-intensive applications. > The importance of larger block sizes depends strong on the application > profile.. For example, many applications perform single-record selects, > and they are not influenced by the block size. > But for some applications, it seems like the ability to use a larger block > size could be quite valuable. -- 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: Proposal for 10.2 release schedule
Rick Hillegas wrote: > Daniel John Debrunner wrote: >> The mid-Sep Derby release candidate will be marked alpha or beta (JCP >> rules) so the databases won't upgrade anyway. >> >> > I apologize for creating confusion here. We'd like Mustang to ship with > a fully functional Derby, which creates upgradeable databases. So I'm > assuming that we turn off the beta marker on the vetted candidate before > handing the candidate to Mustang for QA bake-in. Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA until Mustang ships. How can it be marked GA without violating the JCP requirements. Sorry if I'm being dense. Dan.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the 10.2
branch?
If we fix critical bugs during that time in the 10.2 branch can't
they
go into the release end of October?
They should be able to. Since we won't have had a GA release (JCP
rules)
until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require
a new
release candidate and new vote. Could even be a database format
change.
Let me work out the implications of this.
o Mustang would ship with a release candidate which the community
rejected.
o The community would approve a later release candidate and promote it
to GA status.
o Bug reports would come in against both the rejected candidate bundled
into Mustang and the approved candidate which was promoted to GA
status.
A couple issues come to mind:
o In those bug reports, how would we disambiguate the release
candidates? We could bump the last digit of the release identifier
after
producing the first candidate. Or we could rely on the full version id
produced by sysinfo, which contains the subversion revision number.
I think we have bumped the fourth version ("point") digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.
o The database format change troubles me. What happens if someone
creates a database with the rejected release candidate bundled with
Mustang? I think we want that database to play well with the approved
release candidate which goes GA.
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
I apologize for creating confusion here. We'd like Mustang to ship
with a fully functional Derby, which creates upgradeable databases. So
I'm assuming that we turn off the beta marker on the vetted candidate
before handing the candidate to Mustang for QA bake-in.
Re-reading your comment, I see another issue which I need to clarify.
The release candidate is not a GA implementation under the JCP as I
understand this process. The candidate does not become GA until we post
it on the Apache mirrors and announce, via the Derby website, that it is
the latest Derby release.
Re: [VOTE] 10.1.3.0 release
On 6/22/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > Andrew McIntyre wrote: >> Is this a serious enough issue to warrant another release candidate? >> Tests that exercise the issue were not contributed along with the fix, >> and it would be nice to know that this is an issue that is likely to >> be hit in known circumstances. If so, a release note is probably in >> order since it supposedly can cause corruption to a database. H, what would the release note say? "In some situations you can end up with a corrupted database and there's nothing you can do about it. However the problem is fixed and it's in the 10.1 branch, so best you ignore this release and build your own version." Well, if no one really knows how to exercise it, but it is in fact suspected to cause problems then, sure, I'll roll another release candidate with the fix. It would be nice if we knew what circumstances would hit that code path, so we could warn users of previous versions what to do to prevent corrupting their databases. I'll have a new release candidate posted by tomorrow. andrew
Re: Proposal for 10.2 release schedule
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
Thanks for your comments. Some further remarks follow.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
What happens between September 15 and End of October on the 10.2
branch?
If we fix critical bugs during that time in the 10.2 branch can't they
go into the release end of October?
They should be able to. Since we won't have had a GA release (JCP rules)
until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require a new
release candidate and new vote. Could even be a database format change.
Let me work out the implications of this.
o Mustang would ship with a release candidate which the community rejected.
o The community would approve a later release candidate and promote it
to GA status.
o Bug reports would come in against both the rejected candidate bundled
into Mustang and the approved candidate which was promoted to GA status.
A couple issues come to mind:
o In those bug reports, how would we disambiguate the release
candidates? We could bump the last digit of the release identifier after
producing the first candidate. Or we could rely on the full version id
produced by sysinfo, which contains the subversion revision number.
I think we have bumped the fourth version ("point") digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.
o The database format change troubles me. What happens if someone
creates a database with the rejected release candidate bundled with
Mustang? I think we want that database to play well with the approved
release candidate which goes GA.
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
I apologize for creating confusion here. We'd like Mustang to ship with
a fully functional Derby, which creates upgradeable databases. So I'm
assuming that we turn off the beta marker on the vetted candidate before
handing the candidate to Mustang for QA bake-in.
Dan.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote:
> Hi Dan,
>
> Thanks for your comments. Some further remarks follow.
>
> Regards,
> -Rick
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>
>>
>>> Kathey Marsden wrote:
>>>
>>>
>>>
Rick Hillegas wrote:
>>
>>
>>
>>
What happens between September 15 and End of October on the 10.2
branch?
>>
>>
>>
>>
If we fix critical bugs during that time in the 10.2 branch can't they
go into the release end of October?
>>
>>
>> They should be able to. Since we won't have had a GA release (JCP rules)
>> until Mustang ships, it seems any critical bug that we find and fix
>> between Sep 15th and Mustang shipping has the potential to require a new
>> release candidate and new vote. Could even be a database format change.
>>
>>
> Let me work out the implications of this.
>
> o Mustang would ship with a release candidate which the community rejected.
> o The community would approve a later release candidate and promote it
> to GA status.
> o Bug reports would come in against both the rejected candidate bundled
> into Mustang and the approved candidate which was promoted to GA status.
>
> A couple issues come to mind:
>
> o In those bug reports, how would we disambiguate the release
> candidates? We could bump the last digit of the release identifier after
> producing the first candidate. Or we could rely on the full version id
> produced by sysinfo, which contains the subversion revision number.
I think we have bumped the fourth version ("point") digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.
> o The database format change troubles me. What happens if someone
> creates a database with the rejected release candidate bundled with
> Mustang? I think we want that database to play well with the approved
> release candidate which goes GA.
The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
Dan.
Re: MySQL to Derby Migration Tool
Ramin Moazeni wrote: > Hello, > > I am a Google Summer of code participant working on the Derby > Migration tool project. The High level design document is posted at > http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument It's great to see you doing this! > There are 2 approaches described in the document -- one based on the use > DatabaseMetaData class and the other is based on the use ddlUtils tool > (http://db.apache.org/ddlutils) which is also an apache project. In the "Approach 2: Using DdlUtils" section of http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument , there is this description: In order to use DdlUtils component to migrate the source database to the target database, following steps are suggested: * Capture DDL file from DdlUtils. * Modify the source DDL to the target DDL using Serialization and Deserialization of XML. * Fed in the new DDL file to the DdlUtils. If the intent is to use the XML DDL file generated by DdlUtils, technically there should be no need to modify it for the target database -- except that there are a few issues that would need to be watched for, such as Derby doesn't support a boolean type. At any rate, the Java app can read the database model from the XML file, or even from the "live database" (see http://db.apache.org/ddlutils/api-usage.html#Reading+the+model+from+a+live+database ), then write that database model to the target. The DdlUtils code takes care of producing the SQL required to create the tables in the new database. > Please note that the DdlUtils doesn’t support non-table entities, > constraints, triggers, stored procedures, etc. DdlUtils supports primary and foreign key constraints, but not check constraints. Given its limitations, your DatabaseMetaData approach might be more complete. But if you can use any pieces from DdlUtils, you should feel free to do so (with all the correct attributions, of course) since it is under the ASL 2.0. -jean
Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
Under Deprecated there is: "A deprecated interface may be removed from the project after four minor and/or major releases." http://wiki.apache.org/db-derby/ForwardCompatibility#head-b94fc1d3af5d38a917e2b6c754a8c4213e28f06e Not sure that really works. With an open source project there could be four releases in a couple of months, would allow features to be deprecated very quickly. Not sure of any better wording. Dan.
[jira] Commented: (DERBY-959) Allow use of DRDA QRYDTA block sizes greater than 32K
[ http://issues.apache.org/jira/browse/DERBY-959?page=comments#action_12417367 ] Sunitha Kambhampati commented on DERBY-959: --- Discussion happened on this issue on derby-dev. Here is the link to the discussion that happened on derby-dev http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273 I have opened two other jira issues for the tasks related to this issue. . DERBY-1441 - client side changes to support query block size greater than 32k DERBY-1442- to do performance analysis and come up with a 'good' query block size value for the client to send to the server. > Allow use of DRDA QRYDTA block sizes greater than 32K > - > > Key: DERBY-959 > URL: http://issues.apache.org/jira/browse/DERBY-959 > Project: Derby > Type: Improvement > Components: Network Client, Performance, Network Server > Versions: 10.1.1.0, 10.2.0.0, 10.1.1.1, 10.1.1.2 > Reporter: Bryan Pendleton > Priority: Minor > Attachments: 959Notes_v1.html, SmallRows_32kBlkSz.trace, > SmallRows_64kBlkSz.trace, derby959.review.diff.txt, derby959.review.stat.txt, > odbc_rowgreaterthan64k.trace > > Currently, the Network Server and Network Client use a 32K blocksize when > returning database data in QRYDTA blocks. > I came across the following statement in the DRDA spec (Volume 1, page 12): > Blocking applies only to the QRYDTA reply objects. Each > query block is a QRYDTA DSS. The maximum query block size > value allowed in the qryblksz parameter is increased from > 32K to 10M, thus accomodating the larger data volumes > required by modern, more data-intensive applications. > The importance of larger block sizes depends strong on the application > profile.. For example, many applications perform single-record selects, > and they are not influenced by the block size. > But for some applications, it seems like the ability to use a larger block > size could be quite valuable. -- 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: Proposal for 10.2 release schedule
Hi Dan, Thanks for your comments. Some further remarks follow. Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: Kathey Marsden wrote: Rick Hillegas wrote: What happens between September 15 and End of October on the 10.2 branch? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? They should be able to. Since we won't have had a GA release (JCP rules) until Mustang ships, it seems any critical bug that we find and fix between Sep 15th and Mustang shipping has the potential to require a new release candidate and new vote. Could even be a database format change. Let me work out the implications of this. o Mustang would ship with a release candidate which the community rejected. o The community would approve a later release candidate and promote it to GA status. o Bug reports would come in against both the rejected candidate bundled into Mustang and the approved candidate which was promoted to GA status. A couple issues come to mind: o In those bug reports, how would we disambiguate the release candidates? We could bump the last digit of the release identifier after producing the first candidate. Or we could rely on the full version id produced by sysinfo, which contains the subversion revision number. o The database format change troubles me. What happens if someone creates a database with the rejected release candidate bundled with Mustang? I think we want that database to play well with the approved release candidate which goes GA. Suppose we were able to publish the 10.2 release candidate (make it GA) right after we vetted it in mid-September. When would you want to produce the follow-on bug fix release? At the end of October? A couple months later? We could do either. The community may want to defer the follow-on bug fix release for a couple months. That would give us time to collect more feedback from users of the published, GA release. However, we could "release early, release often" and produce another release from the 10.2 branch at the end of October. Not sure I understand the point of this paragraph. I thought the JCP rules mean we can't make 10.2 GA in mid-Sep, thus it seems to be a hypothetical impossible situation. Dan. That's right. This is an impossible, hypothetical situation. I was trying to compare Kathey's scenario to a scenario which could arise if we didn't have the JCP restrictions: Suppose we produce a GA feature release and a week later we discover that the release has a horrendous, data-corrupting bug. We might produce a bug fix release a couple weeks after the bad release.
[jira] Created: (DERBY-1442) Do performance analysis and come up with a good query block size value for the client to send to the server
Do performance analysis and come up with a good query block size value for the client to send to the server --- Key: DERBY-1442 URL: http://issues.apache.org/jira/browse/DERBY-1442 Project: Derby Type: Improvement Components: Network Server, Test, Network Client, Performance Reporter: Sunitha Kambhampati Priority: Minor Fix For: 10.2.0.0 Do performance analysis, and find a good query block size value for the client to send to the server . Need to understand the memory usage also for greater query block size values. This issue is related to DERBY-959 and DERBY-1441. DERBY-959 has server side changes DERBY-1441 issue talks about client side changes DERBY-959 talks about 'Allowing use of QRYDTA block sizes greater than 32k'. As part of discussion on that jira, it was suggested that the performance analysis to decide a good query block size value for the client to send to the server be a separate task. Here is the link to the discussion that happened for DERBY-959. http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273 -- 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-1441) Allow client to be able to send greater than 32k query block size.
Allow client to be able to send greater than 32k query block size. --- Key: DERBY-1441 URL: http://issues.apache.org/jira/browse/DERBY-1441 Project: Derby Type: Improvement Components: Network Client Versions: 10.2.0.0 Reporter: Sunitha Kambhampati Priority: Minor DERBY-959 talks about 'Allowing use of QRYDTA block sizes greater than 32k'. I am opening two tasks after the discussion on DERBY-959. As part of this issue: - add support in client to be able to send query block size of greater than 32k. After that, some benchmarking needs to be done to choose a good query block size for the client to send to the server. I'll open another jira for the performance analysis task. Here is the link to the discussion that happened for DERBY-959. http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273 -- 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: Proposal for 10.2 release schedule
Rick Hillegas wrote: > Kathey Marsden wrote: > >> Rick Hillegas wrote: >> >> What happens between September 15 and End of October on the 10.2 branch? > >> If we fix critical bugs during that time in the 10.2 branch can't they >> go into the release end of October? They should be able to. Since we won't have had a GA release (JCP rules) until Mustang ships, it seems any critical bug that we find and fix between Sep 15th and Mustang shipping has the potential to require a new release candidate and new vote. Could even be a database format change. > Suppose we were able to publish the 10.2 release candidate (make it GA) > right after we vetted it in mid-September. When would you want to > produce the follow-on bug fix release? At the end of October? A couple > months later? We could do either. The community may want to defer the > follow-on bug fix release for a couple months. That would give us time > to collect more feedback from users of the published, GA release. > However, we could "release early, release often" and produce another > release from the 10.2 branch at the end of October. Not sure I understand the point of this paragraph. I thought the JCP rules mean we can't make 10.2 GA in mid-Sep, thus it seems to be a hypothetical impossible situation. Dan.
[jira] Updated: (DERBY-1271) Release documentation for JDBC4 release
[ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick Hillegas updated DERBY-1271: - Attachment: derby-1271_copyrights_v02.diff Attaching derby-1271_copyrights_v02.diff. Same files as previous patch. This patch removes the "Edition" lines, which no-one understands. This patch also corrects the copyright notices as Jean recommended today. > Release documentation for JDBC4 release > --- > > Key: DERBY-1271 > URL: http://issues.apache.org/jira/browse/DERBY-1271 > Project: Derby > Type: Improvement > Components: Documentation, JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Rick Hillegas > Fix For: 10.2.0.0 > Attachments: derby-1271_copyrights.diff, derby-1271_copyrights_v02.diff > > We can't check in any of this work until we understand how our release trains > line up. However, the JDBC4-bearing release will need the following > documentation: > 1) Changes to the user guides. These need to be understood. We can analyze > the scope of these changes without checking anything in yet. > 2) Summary page which explains what pieces of JDBC4 we tackled and what we > passed over. > 3) Verbiage for the Release Notes. > USER GUIDES > Admin Guide > Part One...How to start an embedded server from an application > For JDBC4, we can omit the Class.forName() line because > of Driver autoloading. > Part One...Embedded server example > For JDBC4, we can omit the Class.forName() line because > of Driver autoloading. > Part One...Network client driver examples > For JDBC4, we can omit the Class.forName() line because > of Driver autoloading. > Part One...Accessing the Network Server by using a DataSource > For JDBC4, we have different DataSources: ClientDateSource40 > and ClientConnectionPoolDataSource40. > Part One...Using the Derby ij tool with the Network Server > In case the DRIVER command ends up being needed pre-JDBC4, > we should note that you don't need it under JDBC4 because > of Driver autoloading. > Part One...The NsSample sample program > Change NsSample to demonstrate driver autoloading under JDBC4. > Part One...Overview of the SimpleNetworkServerSample program > Change SimpleNetworkServerSample to demonstrate driver autoloading under > JDBC4. > Part One...Connecting a client to the Network Server with the > SimpleNetworkClientSample program > Change SimpleNetworkClientSample to demonstrate driver autoloading under > JDBC4. > Developer's Guide > JDBC applications and Derby basics > Derby embedded basics > Derby JDBC driver > Note that you don't need Class.forName() in JDBC4. > Derby embedded basics > Embedded Derby JDBC driver > Note that you don't need Class.forName() in JDBC4. > Starting Derby as an embedded database > Note that you don't need Class.forName() or the jdbc.drivers property > in JDBC4. > Controlling Derby application behavior > Working with Derby SQLExceptions in an application > Note that with JDBC4, these are refined subclasses > Example of processing SQLExceptions > Say something about SQLException.getCause() > Using Derby as a J2EE resource manager > Classes that pertain to resource managers > Mention the JDBC4 variants of these classes. > Getting a DataSource > Include example using JDBC4 variants of these classes. > Shutting down or creating a database > Include example using JDBC4 variants of these classes. > Getting Started Guide > No changes necessary. > Reference Guide > Derby exception messages and SQL states > Describe SQLFeatureNotSupportedException and its SQLStates. > SQLState and error message reference > Mention new unimplementedFeature exceptions. > What to do about new SQLStates. > JDBC Reference > "conforms to the JDBC 2.0 and 3.0 APIs" > -> > "conforms to the JDBC 2.0, 3.0, and 4.0 APIs" > java.sql.Driver > Amend this to note driver autoloading for JDBC4. > java.sql.Connection > Connection functionality not supported > List unsupported Connection methods. > java.sql.DatabaseMetaData > Columns in the ResultSet returned by getProcedureColumns > Add new columns added by JDBC4 > java.sql.Statement > Note that Derby does not support the execute() and > executeQuery() overloads which return autogenerated keys. > Prepared statements and streaming columns > Note that with JDBC4, you can specify length as a long > or even omit the length when setting LOB streams. > java.sql.ResultSetMetaData > Waiting for feedback from Dag on whether we still don't > support isDefinitelyWritable(), isReadOnly(), and > isWritable(). > java.sql.Blob and java.sql.Clob > Right now this section says that
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: > Last week, Sun Microsystems announced that it will bundle Derby with the > next major release of the reference jdk, Java SE 6, also known as > Mustang or jdk1.6. To be precise, Sun Microsystems announced that it will bundle "Java DB" with Mustang. http://biz.yahoo.com/prnews/060621/sfw063.html?.v=66 Dan.
Re: Proposal for 10.2 release schedule
Hi Kathey, Thanks for raising these issues. Here are some clarifications. Regards, -Rick Kathey Marsden wrote: Rick Hillegas wrote: The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized. Is this something that the Derby community is bound to? The JCP rules are the license you accept when you publish a GA implementation of a JSR. In our case this is JSR 221, which governs JDBC4. The Derby community accepts this license by exposing a GA implementation of JDBC4 in release 10.2. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 What happens between September 15 and End of October on the 10.2 branch? Between September 15 and the end of October, the vetted 10.2 release candidate is still available to anyone who needs it, just as the 10.1.3 release candidate is available right now. Does bug fixing and work on 10.2.1 begin? Forgive me for being pedantic about release numbers. I think that the first release cut off the 10.2 branch will be called 10.2.1.0. I think that you are asking about bug fixing for the second release cut off the 10.2 branch, which would be 10.2.2.0. I think that we can begin putting more bug fixes into the 10.2 branch as soon as we produce the first 10.2 release candidate. So that would be mid-September. If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? Suppose we were able to publish the 10.2 release candidate (make it GA) right after we vetted it in mid-September. When would you want to produce the follow-on bug fix release? At the end of October? A couple months later? We could do either. The community may want to defer the follow-on bug fix release for a couple months. That would give us time to collect more feedback from users of the published, GA release. However, we could "release early, release often" and produce another release from the 10.2 branch at the end of October. End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
David Van Couvering wrote: Hi, Kathey, my silence (and I'm guessing the silence of others) was general approval of your comments. Did you update the page? I didn't see any change notifications fly by. Finally did it. What kind of clarification are you looking for? I'm afraid I'm missing your point :( nevermind. Probably not important. No time to pursue now.
Re: Tuncation of trailing blanks and lengthless streaming overloads
Daniel John Debrunner wrote: Kristian Waagan wrote: Hello, I'm working on DERBY-1417; adding new lengthless overloads to the streaming API. So far, I have only been looking at implementing this in the embedded driver. Based on some comments in the code, I have a few questions and observations regarding truncation of trailing blanks in the various character data types. TypeTrail. blank trunc. Where CHARallowed SQLChar.normalize VARCHAR allowed SQLVarchar.normalize LONG VARCHAR disallowed SQLLongVarchar.normalize CLOBallowed streaming or SQLVarchar.normalize, depending on source. As can be seen, only data for CLOB is truncated for trailing blanks in the streaming class. We must still read all the data, or so much as we need to know the insertion will fail, but we don't have to store it all in memory. Truncation of trailing blanks is not allowed at all for LONG VARCHAR (according to code comments and bug 5592 - haven't found the place this is stated in the specs). My question is, should we do the truncate check for CHAR and VARCHAR on the streaming level as well? If we don't add this feature, inserting a 10GB file into a VARCHAR field by mistake will cause 10GB to be loaded into memory even though the max size allowed is ~32K, possibly causing out-of-memory errors. The error could be generated at an earlier stage (possibly after reading ~32K +1 bytes). I would say its a separate issue to the one you are addressing. Applications most likely won't be inserting 10Gb values into CHAR/VARCHAR columns using streams as it's not going to work. Maybe enter a bug, but doesn't seem it has to be fixed as part of this issue. Handling this as a separate issue is better. The code changes would most likely go into the same class as my changes for DERBY-1417. It seems like a simple enough change, so I will enter a Jira improvement issue. I don't like getting an out-of-memory exception (heap). As far as I can tell, adding this feature is a matter of modifying the 'ReaderToUTF8' class and the 'EmbedPrearedStatement.setCharacterStreamInternal' method. One could also optimize the reading of data into LONG VARCHAR, where one would abort the reading as soon as you can instead of taking it all into memory first. This would require some special case handling in the mentioned locations. Another matter is that streams will not be checked for exact length match when using the lengthless overloads, as we don't have a specified length to compare against. I have a preliminary implementation for setAsciiStream, setCharacterStream and setClob (all without length specifications) in EmbedPreparedStatement. What's the issue with setClob()? The current method doesn't take a length. Has java.sql.Clob been changed to not always have a length? There are/will be 3 setClob methods in PreparedStatement: 1) setClob(int,Clob) 2) setClob(int,Reader,long) 3) setClob(int,Reader) 1) and 2) are already implemented, 3) is a new method added to JDBC. The same story goes for the other setXXXStream methods and updateXXXStream methods. These are located in PreparedStatement, CallableStatement and ResultSet. -- Kristian Dan.
Re: Proposal for 10.2 release schedule
Rick Hillegas wrote: The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized. Is this something that the Derby community is bound to? Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 What happens between September 15 and End of October on the 10.2 branch? Does bug fixing and work on 10.2.1 begin? If we fix critical bugs during that time in the 10.2 branch can't they go into the release end of October? End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors.
[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.
[ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417352 ] Kathey Marsden commented on DERBY-1434: --- Well, I guess I have a little to say about the client code. It looks like our client SectionManager logic is fatally flawed when it comes to two databases. It has these two static variables for hold and non-hold package names and consistency tokens. // noHoldPKGNAMCBytes stores PKGNAMCBytes when holdability is no hold public static byte[] holdPKGNAMCBytes = null; public static byte[] noHoldPKGNAMCBytes = null; There seems to be a databaseName parameter for each SectionManager, so I don't understand why these are static. > Client can send incorrect database name to server after having made multiple > connections to different databases. > > > Key: DERBY-1434 > URL: http://issues.apache.org/jira/browse/DERBY-1434 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.2.0.0, 10.1.3.0, 10.1.2.5 > Reporter: A B > Fix For: 10.2.0.0 > Attachments: Server2.trace, _driver_1, d1434.java > > I have a simple program that connects to a database using the Derby Client, > executes a simple query, then connects to a different database using a > different Connection object and executes another simple query on that second > connection. The queries both execute without error, so it appears that the > connections are correct--i.e. each query will only work on one of the > databases, and both queries work, therefore each must be getting executed > against the correct database. > But in looking at the client and server traces, I noticed that for the query > on the second database, the client is actually sending the name of the > *first* database as RDBNAM, which (I think?) is wrong--it should be sending > the name of the second database, since the query is being executed on the > second Connection object. > This behavior does not appear to occur for JCC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Copyright format (was Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release)
Rick Hillegas (JIRA) wrote: > [ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] > > Rick Hillegas updated DERBY-1271: > - > > Attachment: derby-1271_copyrights.diff > > Attaching derby-1271_copyrights.diff. This adjusts dates in the visible > copyright notices in the user guides. Touches the following files: regarding the format of the copyright, Rick did what I originally suggested: > Copyright 1997, 2005-2006 The Apache Software Foundation or its licensors, as > applicable. Looking at this more closely, all that is needed is the origin year and the year of the most recent update: Copyright 1997, 2006 The Apache Software Foundation or its licensors, as applicable. -jean
Proposal for 10.2 release schedule
Last week, Sun Microsystems announced that it will bundle Derby with the next major release of the reference jdk, Java SE 6, also known as Mustang or jdk1.6. If you download the latest Mustang build, you will see that it contains our Derby 10.2.0.3 snapshot in the "db" directory parallel to "lib" and "bin". This is big news. It means that over the course of the next year, Derby will turn up on the desktops of millions of developers. Hopefully, Derby's user and developer communities will both grow dramatically. I would like to support this bundling. Note that Mustang will need our vetted 10.2 release candidate by September 15 so that they can QA it. This is expected to take about 5 weeks, after which Mustang should go GA in late October. The JCP requires that our JDBC4-exposing release can not be generally available until the JDBC4 specification is finalized, which happens when Mustang is generally available. Until that date, this means that our final, vetted release candidate can not be officially stamped as "GA" and we can not promote it to the various Apache mirrors. Here are proposed dates for 10.2 milestones: August 10 - Feature work committed. 10.2 branch created. August 24 - Last day to commit changes for 10.2 August 25 - Begin vetting 10.2 release candidate September 15 - Target date for finishing the voting on Derby 10.2 End of October - Expected GA of JDBC4 with Mustang End of October - GA of Derby 10.2. Release promoted to Apache mirrors. Are this proposal and its dates reasonable?
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ] Kathey Marsden commented on DERBY-1275: --- I was wondering if anyone had any thoughts on how to implement this improvement to provide a way to enable client tracing without changing the application Not being able to turn on tracing in a deployed application without application code changes is a serious supportability issue because unless the application has a mechanism to configure settings like traceDirectory and traceLevel, the application itself my have to be rebuilt to enable client tracing. Even when such a mechanism is provided it takes someone with knowledge of the application to turn it on, again a supportability issue. All I can think of is supporting System properties like derby.client.traceLevel. We also could mimic our server side mechanism and have a System property derby.client.home that points to a directory where a file derby.client.properties can live and the trace files can go by default. The System property mechanism raises a red flag for me because of class loader issues like we have for derby.system.home. But maybe it is ok because of the diagnostic nature. I ask this question because I find myself in need to put this into a debug build to send to a user and figure I might as well head down the correct path toward an ultimate solution. Thoughts? > Provide a way to enable client tracing without changing the application > --- > > Key: DERBY-1275 > URL: http://issues.apache.org/jira/browse/DERBY-1275 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.2.3 > Reporter: Kathey Marsden > Priority: Minor > > Currently the client tracing can be enabled by setting attributes on the > client url, setXXX methods on the DataSource or calling > DriverManager.setLogWriter(), but it often cannot be enabled in a deployed > client application because all of these API's require modification of the > application or its configuration files. > It would be good to have a global way to turn on client tracing. A system > property pointing to a property file is one possibility but probably not > ideal because of the impact in class loader contexts.I am not sure what > the other possiblities are, -- 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-1271) Release documentation for JDBC4 release
+1 Regards, -Rick Jean T. Anderson wrote: Jeff Levitt wrote: As the person who contributed the DITA-converted documentation, I can tell you I didn't bump the edition up based on that. I believe the pre-DITA documentation already said Second Edition. The pre-DITA (10.0) doc source says First Edition: https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/getstart/gspr.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/reference/sqlj.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/develop/develop.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tools/tools.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/admin/hubprnt.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tuning/perf.ihtml The thought is that major releases (10.0, 10.1, 10.2) are First Editions, and subsequent fixpaks are Second, Third, Fourth editions etc., like 10.1.3 would be. In any case, we haven't adhered to any kind of consistency on this with the guides, so I agree that we need to define what we feel is an "edition" and stick with it or remove it alltogether (although perhaps there's a legal reason to keep it?) If we don't have a specific use for it, I recommend removing it. I don't know of any legal reason to have it. -jean
Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release
Jeff Levitt wrote: > As the person who contributed the DITA-converted > documentation, I can tell you I didn't bump the > edition up based on that. I believe the pre-DITA > documentation already said Second Edition. The pre-DITA (10.0) doc source says First Edition: https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/getstart/gspr.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/reference/sqlj.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/develop/develop.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tools/tools.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/admin/hubprnt.ihtml https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tuning/perf.ihtml > The thought is that major releases (10.0, 10.1, 10.2) > are First Editions, and subsequent fixpaks are Second, > Third, Fourth editions etc., like 10.1.3 would be. In > any case, we haven't adhered to any kind of > consistency on this with the guides, so I agree that > we need to define what we feel is an "edition" and > stick with it or remove it alltogether (although > perhaps there's a legal reason to keep it?) If we don't have a specific use for it, I recommend removing it. I don't know of any legal reason to have it. -jean
Re: [VOTE] 10.1.3.0 release
> Andrew McIntyre wrote: >> Is this a serious enough issue to warrant another release candidate? >> Tests that exercise the issue were not contributed along with the fix, >> and it would be nice to know that this is an issue that is likely to >> be hit in known circumstances. If so, a release note is probably in >> order since it supposedly can cause corruption to a database. H, what would the release note say? "In some situations you can end up with a corrupted database and there's nothing you can do about it. However the problem is fixed and it's in the 10.1 branch, so best you ignore this release and build your own version." :-) Seems like a new release candidate is in order. Dan.
Re: [VOTE] 10.1.3.0 release
+1 Based on test results: http://www.multinet.no/~solberg/public/Apache/index.html Andreas
Re: [VOTE] 10.1.3.0 release
Andrew McIntyre wrote: If we have another release candidate, and assuming that the relevant fixes for it can be committed by Friday, are those testing the release candidate comfortable with a 72-hour turnaround on the vote for the new release candidate or will we need another two weeks? I think for DERBY-1392 72 hours is just fine because. 1) Nobody has a test that goes through that code path anyway. 2) If anybody does go through that code path as it stands they get a corrupt db. So it sounds like whatever the fix for DERBY-1392 holds it is only going to be better for users. What else has gone into 10.1.3 since the release candidate? I think it would be the other fixes that would dictate how much additional testing is required. Kathey
Re: [jira] Updated: (DERBY-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db
Mike Matrigali (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1156?page=all ] Mike Matrigali updated DERBY-1156: -- i reviewed and tested reencrypt_3.diff patch. it looks fine, i will let you commit. Still would like to see more testing, especially exercising the abort paths when failure happens while reencrypting. Thanks Mike. I will add the tests for abort paths. -suresh
[jira] Updated: (DERBY-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db
[ http://issues.apache.org/jira/browse/DERBY-1156?page=all ] Mike Matrigali updated DERBY-1156: -- i reviewed and tested reencrypt_3.diff patch. it looks fine, i will let you commit. Still would like to see more testing, especially exercising the abort paths when failure happens while reencrypting. > allow the encrypting of an existing unencrypted db and allow the > re-encrypting of an existing encrypted db > -- > > Key: DERBY-1156 > URL: http://issues.apache.org/jira/browse/DERBY-1156 > Project: Derby > Type: Improvement > Components: Store > Versions: 10.1.2.3 > Reporter: Mike Matrigali > Assignee: Suresh Thalamati > Priority: Minor > Fix For: 10.2.0.0 > Attachments: encryptspec.html, reencrypt_1.diff, reencrypt_2.diff, > reencrypt_3.diff > > encrypted database to be re-encrypted with a new password. > Here are some ideas for an initial implementation. > The easiest way to do this is to make sure we have exclusive access to the > data and that no log is required in the new copy of the db. I want to avoid > the log as it also is encrypted. Here is my VERY high level plan: > 1) Force exclusive access by putting all the work in the low level store, >offline boot method. We will do redo recovery as usual, but at the end >there will be an entry point to do the copy/encrypt operation. > copy/encrypt process: > 0) The request to encrypt/re-encrypt the db will be handled with a new set >of url flags passed into store at boot time. The new flags will provide >the same inputs as the current encrypt flags. So at high level the >request will be "connect db old_encrypt_url_flags; new_encrypt_url_flags". >TODO - provide exact new flag syntax. > 1) Open a transaction do all logged work to do the encryption. All logging >will be done with existing encryption. > 2) Copy and encrypt every db file in the database. The target files will >be in the data directory. There will be a new suffix to track the new >files, similar to the current process used for handling drop table in >a transaction consistent manner without logging the entire table to the > log. >Entire encrypted destination file is guaranteed synced to disk before >transaction commits. I don't think this part needs to be logged. >Files will be read from the cache using existing mechanism and written >directly into new encrypted files (new encrypted data does not end up in >the cache). > 3) Switch encrypted files for old files. Do this under a new log operation >so the process can be correctly rolled back if the encrypt db operation >transaction fails. Rollback will do file at a time switches, no reading >of encrypted data is necessary. > 4) log a "change encryption of db" log record, but do not update >system.properties with the change. > 5) commit transaction. > 6) update system.properties and sync changes. > 7) TODO - need someway to handle crash between steps 5 and 6. > 6) checkpoint all data, at this point guaranteed that there is no outstanding >transaction, so after checkpoint is done there is no need for the log. > ISSUES: > o there probably should be something that catches a request to encrypt to > whatever db was already encrypted with. -- 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-1343) It is possible to have duplicate entries in conglomerateId of sysconglomerates before DERBY-655 was fixed in 10.0 or 10.1 databases. It is desirable to patch these databas
[ http://issues.apache.org/jira/browse/DERBY-1343?page=all ] Mike Matrigali updated DERBY-1343: -- Component: (was: Store) this is an issue with the system catalogs, from discussions on list it looks like not a store issue. > It is possible to have duplicate entries in conglomerateId of > sysconglomerates before DERBY-655 was fixed in 10.0 or 10.1 databases. It is > desirable to patch these databases on upgrade to 10.2 so conglomerateId > becomes unique again. > > > Key: DERBY-1343 > URL: http://issues.apache.org/jira/browse/DERBY-1343 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.0.2.0 > Reporter: Mamta A. Satoor > > Because of an optimization implemented in before Derby 10.0 release, it is > possible to have duplicate entries in conglomerateId column. It would be good > to patch these entries during upgrade to 10.2 or later so that > conglomerateIds become unique again. See the discussion and proposed > solutions at: > http://www.nabble.com/-Derby-655-+%3A+getImportedKeys+returns+duplicate+rows+in+some+cases-t1673189.html#a4535887 > When a user defines a constraint, Derby checks to see if it's backing index > is a duplicate of an existing index and if yes, then it shares the same > conglomerates for both such indexes. Code for this is in > org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction. > This causes Derby to have duplicate rows in sysconglomerates with same > conglomerateid. (More information on this can be found in thread > http://www.nabble.com/-Derby-655-+%3A+getImportedKeys+returns+duplicate+rows+in+some+cases-t1673189.html#a4535887 > titled "[DERBY-655] : getImportedKeys returns duplicate rows in some cases". > During drop constraint, it looks like Derby is not able to identify the > correct row in SYSCONGLOMERATES, if there are duplicate rows with same > conglomerateid and as a consequence, wrong row gets dropped in > SYSCONGLOMERATES. More information with an example on this can be found in > thread > http://www.nabble.com/When+foreign+key+is+dropped%2C+is+Derby+dropping+the+wrong+row+from+SYS.SYSCONGLOMERATES--t1654121.html#a4481463 > titled "When foreign key is dropped, is Derby dropping the wrong row from > SYS.SYSCONGLOMERATES?" -- 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-1271) Release documentation for JDBC4 release
--- Rick Hillegas <[EMAIL PROTECTED]> wrote: > Daniel John Debrunner wrote: > > >Rick Hillegas wrote: > > > > > > > >>Jean T. Anderson wrote: > >> > >> > >> > >>>Rick Hillegas wrote: > >>> > >>> > >>> > >>> > Thanks, Jean. The Edition line turns up in the > visible text which > appears in the printed document. That makes me > think that it applies to > something that the customer, the reader, cares > about. I don't think the > reader is particularly concerned about our > transition to dita. If that > is what Edition is supposed to capture, perhaps > the Edition lines should > be moved to a comments section so that they will > not be > visible/confusing to customers. > > > > >>>The Developers Guide has a "first edition" for > both 10.0 and 10.1: > >>> > http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html > >>> > http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html > >>> > >>>I don't know why the Edition was bumped for the > others. :-) > >>> > >>>If there isn't a major change to the content of > the book, I don't think > >>>the edition should be bumped. > >>> > >>>"Working With Derby" should definitely not be > bumped from First to > >>>Second edition since 10.2 will be its first > release. > >>> > >>> > >>> > >>> > >>I could just bump the edition for the Reference > Guide, which will carry > >>a lot of edits to reflect JDBC4. Would that be > acceptable? > >> > >> > > > >What does the "edition" represent? Would this mean > the first release of > >the 10.2 documentation set would be partially at > the "second edition", > >doesn't seem to make sense to me. > > > >Dan. > > > > > This is what's troubling me too. From Jean's > investigations it seems > that "edition" doesn't have a consistent meaning > across our user guides > and releases. We could just remove the "edition" > lines. If we leave them > in, then it would be good to agree on their meaning. > Maybe one of the > following: > > 1) The Edition number is bumped whenever we create a > release branch. We > don't bump Edition for point or patch releases. > > 2) The Edition number is bumped whenever reviewers > agree that a user > guide has changed significantly. > > 3) The Edition number is the same as the release > number. All user guides > in a given release have identical Edition numbers. > > > As the person who contributed the DITA-converted documentation, I can tell you I didn't bump the edition up based on that. I believe the pre-DITA documentation already said Second Edition. The thought is that major releases (10.0, 10.1, 10.2) are First Editions, and subsequent fixpaks are Second, Third, Fourth editions etc., like 10.1.3 would be. In any case, we haven't adhered to any kind of consistency on this with the guides, so I agree that we need to define what we feel is an "edition" and stick with it or remove it alltogether (although perhaps there's a legal reason to keep it?) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (DERBY-1429) Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly
[ http://issues.apache.org/jira/browse/DERBY-1429?page=all ] Mike Matrigali updated DERBY-1429: -- Component: Services (was: Store) This issue should be handled by the monitor, not the store. > Additional vulnerability to non-deterministic startup behavior when > applications generate derby properties on the fly > - > > Key: DERBY-1429 > URL: http://issues.apache.org/jira/browse/DERBY-1429 > Project: Derby > Type: Bug > Components: Services > Versions: 10.2.0.0 > Reporter: Rick Hillegas > > JDBC4 driver-autoloading, introduced by DERBY-930, increases the exposure to > non-deterministic startup behavior described in DERBY-1428. With the > introduction of driver-autloading, DERBY-1428 can be triggered if OtherApp is > any application which uses a JDBC driver. That is, OtherApp could use a Derby > client driver, the DB2JCC driver, the Oracle client driver, etc.. The extra > exposure arises because, with driver auto-loading, all JDBC drivers are > registered and the Derby engine boots the first time some application asks > for a Connection. > The issues are summarized in an email thread > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200606.mbox/browser and > bug report DERBY-1399. > Workarounds are similar to those for DERBY-1428: > 1) Determine the derby properties BEFORE the VM starts. > 2) If that is not possible, then force the self-configuring embedded > application to run first. -- 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] 10.1.3.0 release
Andrew McIntyre wrote: On 6/20/06, Kathey Marsden <[EMAIL PROTECTED]> wrote: Mike Matrigali wrote: > I would like to see the fix for DERBY-1392 included in the 10.1.3 > release if there is a second release candidate. While the bug > is an edge error case, the result is a corrupt db. I believe > there is little risk as again the path is not one usually taken. > The change has already been fixed in the trunk and the 10.1 branch. +1 to including DERBY-1392 and thanks so much to Anders for finding and fixing this issue! Is this a serious enough issue to warrant another release candidate? Tests that exercise the issue were not contributed along with the fix, and it would be nice to know that this is an issue that is likely to be hit in known circumstances. If so, a release note is probably in order since it supposedly can cause corruption to a database. I believe this is serious enough to warrent another RC. By code inspection as Anders points out it is clear there is a path that could corrupt the db. Another reason I would like to get this in is that in the past there has been a non reproducible case of an unencrypted string getting into a page of an encrypted db with one of our customers on the original cloudscape pre-derby product. We have never been able to reproduce this, but the code for this path is has the same problem in the pre-derby code as the code Anders fixed. Since we never had a reproducible case I can't say this is the fix, but it seems likely. Because the code path depends on a timing I/O exception it is a particularly hard test to write. For this reason I spent extra time reviewing the code and why I felt it was ok to go in without a test. Since 10.2 is around the corner, I am worried that this might be the last official 10.1 release for a long time so would like to see this fix make it.
Re: [VOTE] 10.1.3.0 release
Mike Matrigali wrote: I would like to see the fix for DERBY-1392 included in the 10.1.3 release if there is a second release candidate. While the bug is an edge error case, the result is a corrupt db. I believe there is little risk as again the path is not one usually taken. The change has already been fixed in the trunk and the 10.1 branch. /mikem I agree with Mike, DERBY-1392 fix should be included in the second release candidate. Although it happens only on error case; it is good to fix this issue; I think error path mentioned also can be hit when users interrupt thread when derby is writing pages with an InterrupedIOException. Fix is simple, it should not cause any regressions. Thanks -suresht
Re: [VOTE] 10.1.3.0 release
Kathey Marsden wrote: Mike Matrigali wrote: I would like to see the fix for DERBY-1392 included in the 10.1.3 release if there is a second release candidate. While the bug is an edge error case, the result is a corrupt db. I believe there is little risk as again the path is not one usually taken. The change has already been fixed in the trunk and the 10.1 branch. +1 to including DERBY-1392 and thanks so much to Anders for finding and fixing this issue! Kathey On the similar lines I would also wish to see DERBY-959 available in 10.1.3, if there is an RC2. The fix looks straight forward and at the same time will allow the Network server to match the newer DRDA spec and work with newer C clients. Regards, -Rajesh
[jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
[
http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417334 ]
Olav Sandstaa commented on DERBY-1438:
--
Personally, I prefer the text written by the embedded driver ("SQL Exception:")
over the text written by the client driver ("java.sql.Exception:"), but with
the introduction of the SQL exception hierarchy in Java SE 6 it might be better
to use the exact exception name (e.g.
"java.sql.IamSorryThisShouldNotHappenTodayException") which is what I think you
get if you call SQLException.toString() and running with jdk 1.6.
> Text written by SQLException.toString differs between client and embedded
> driver
>
>
> Key: DERBY-1438
> URL: http://issues.apache.org/jira/browse/DERBY-1438
> Project: Derby
> Type: Improvement
> Components: JDBC, Newcomer
> Versions: 10.2.0.0
> Environment: Sun JDK 1.5
> Reporter: Olav Sandstaa
> Assignee: David Van Couvering
> Priority: Trivial
>
> The first part of the string written by SQLExeption.toString() differs
> between the Derby client driver and the embedded driver. The embedded
> driver writes:
>SQL Exception: Table/View 'DERBYDB' does not exist.
> while the client driver writes:
>java.sql.SQLException: Table/View 'DERBYDB' does not exist.
> It would be good if we changed this so the same text is written by
> both drivers. This reduces the difference seen when changing between
> client and embedded Derby and it make it possible to reduce the amount
> of sed-ing or the number of master file variants for some tests.
--
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: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
David Van Couvering wrote: > > > Rick Hillegas wrote: >> >> I can see that Private Stable applies to the client/server api. These >> apis should remain forward/backward compatible within a release >> family. Do Private Stable interfaces turn up in other situations? > > > Yes, that's right. I wonder if the database file format is also Private > Stable. I am still looking for some guidance in that area in terms of > what are incompatible changes... What guidance do you need above: http://db.apache.org/derby/papers/versionupgrade.html ? (note there is a type in that document, at one point it has 'EM <= 10', I think that should be 'EM >= 10'.) I think that's the policy for on-disk format and did undergo a vote (I believe). Dan.
Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release
Daniel John Debrunner wrote: Rick Hillegas wrote: Jean T. Anderson wrote: Rick Hillegas wrote: Thanks, Jean. The Edition line turns up in the visible text which appears in the printed document. That makes me think that it applies to something that the customer, the reader, cares about. I don't think the reader is particularly concerned about our transition to dita. If that is what Edition is supposed to capture, perhaps the Edition lines should be moved to a comments section so that they will not be visible/confusing to customers. The Developers Guide has a "first edition" for both 10.0 and 10.1: http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html I don't know why the Edition was bumped for the others. :-) If there isn't a major change to the content of the book, I don't think the edition should be bumped. "Working With Derby" should definitely not be bumped from First to Second edition since 10.2 will be its first release. I could just bump the edition for the Reference Guide, which will carry a lot of edits to reflect JDBC4. Would that be acceptable? What does the "edition" represent? Would this mean the first release of the 10.2 documentation set would be partially at the "second edition", doesn't seem to make sense to me. Dan. This is what's troubling me too. From Jean's investigations it seems that "edition" doesn't have a consistent meaning across our user guides and releases. We could just remove the "edition" lines. If we leave them in, then it would be good to agree on their meaning. Maybe one of the following: 1) The Edition number is bumped whenever we create a release branch. We don't bump Edition for point or patch releases. 2) The Edition number is bumped whenever reviewers agree that a user guide has changed significantly. 3) The Edition number is the same as the release number. All user guides in a given release have identical Edition numbers.
[jira] Created: (DERBY-1440) ij running with client driver and jdk 1.6 omits chained exceptions in error messages
ij running with client driver and jdk 1.6 omits chained exceptions in error
messages
Key: DERBY-1440
URL: http://issues.apache.org/jira/browse/DERBY-1440
Project: Derby
Type: Bug
Components: Tools, JDBC, Network Client
Versions: 10.2.0.0
Environment: Sun JDK 1.6
Reporter: Olav Sandstaa
Priority: Minor
When running some SQL queries through ij that fails it seems like some
information about chained exceptions is not presented to the user when
running with the client driver and jdk 1.6.
One example SQL that fails (taken from the ieptests.sql):
=
ij> call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('inventory', 'ORDERTABLE' ,
'extinout/order.dat', null, null, null) ;
When running this in ij the following error message is produced:
Java 1.6 Embedded driver:
=
ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Schema
'inventory' does not exist' was thrown while evaluating an expression.
ERROR 42Y07: Schema 'inventory' does not exist
Java 1.5 Client driver:
===
ERROR 38000: The exception 'SQL Exception: Schema 'inventory' does not
exist' was thrown while evaluating an expression. SQLSTATE: 42Y07:
Schema 'inventory' does not exist
Java 1.6 Client driver:
===
ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Schema
'inventory' does not exist' was thrown while evaluating an expression.
The bug (or difference) here is that the client driver when running
with jdk 1.6 does not print the chained exception and SQL state.
It would be nice to have the same information in the output as what is
written by the embedded driver (or client driver running with jdk
1.5).
--
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-1438) Text written by SQLException.toString differs between client and embedded driver
[ http://issues.apache.org/jira/browse/DERBY-1438?page=comments#action_12417330 ] David Van Couvering commented on DERBY-1438: I'll take a look at this and see what I can do. Thanks, Olav. > Text written by SQLException.toString differs between client and embedded > driver > > > Key: DERBY-1438 > URL: http://issues.apache.org/jira/browse/DERBY-1438 > Project: Derby > Type: Improvement > Components: JDBC, Newcomer > Versions: 10.2.0.0 > Environment: Sun JDK 1.5 > Reporter: Olav Sandstaa > Assignee: David Van Couvering > Priority: Trivial > > The first part of the string written by SQLExeption.toString() differs > between the Derby client driver and the embedded driver. The embedded > driver writes: >SQL Exception: Table/View 'DERBYDB' does not exist. > while the client driver writes: >java.sql.SQLException: Table/View 'DERBYDB' does not exist. > It would be good if we changed this so the same text is written by > both drivers. This reduces the difference seen when changing between > client and embedded Derby and it make it possible to reduce the amount > of sed-ing or the number of master file variants for some tests. -- 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-1438) Text written by SQLException.toString differs between client and embedded driver
[ http://issues.apache.org/jira/browse/DERBY-1438?page=all ] David Van Couvering reassigned DERBY-1438: -- Assign To: David Van Couvering > Text written by SQLException.toString differs between client and embedded > driver > > > Key: DERBY-1438 > URL: http://issues.apache.org/jira/browse/DERBY-1438 > Project: Derby > Type: Improvement > Components: JDBC, Newcomer > Versions: 10.2.0.0 > Environment: Sun JDK 1.5 > Reporter: Olav Sandstaa > Assignee: David Van Couvering > Priority: Trivial > > The first part of the string written by SQLExeption.toString() differs > between the Derby client driver and the embedded driver. The embedded > driver writes: >SQL Exception: Table/View 'DERBYDB' does not exist. > while the client driver writes: >java.sql.SQLException: Table/View 'DERBYDB' does not exist. > It would be good if we changed this so the same text is written by > both drivers. This reduces the difference seen when changing between > client and embedded Derby and it make it possible to reduce the amount > of sed-ing or the number of master file variants for some tests. -- 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-1271) Release documentation for JDBC4 release
Rick Hillegas wrote: > Jean T. Anderson wrote: > >> Rick Hillegas wrote: >> >> >>> Thanks, Jean. The Edition line turns up in the visible text which >>> appears in the printed document. That makes me think that it applies to >>> something that the customer, the reader, cares about. I don't think the >>> reader is particularly concerned about our transition to dita. If that >>> is what Edition is supposed to capture, perhaps the Edition lines should >>> be moved to a comments section so that they will not be >>> visible/confusing to customers. >>> >> >> >> The Developers Guide has a "first edition" for both 10.0 and 10.1: >> http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html >> http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html >> >> I don't know why the Edition was bumped for the others. :-) >> >> If there isn't a major change to the content of the book, I don't think >> the edition should be bumped. >> >> "Working With Derby" should definitely not be bumped from First to >> Second edition since 10.2 will be its first release. >> >> > I could just bump the edition for the Reference Guide, which will carry > a lot of edits to reflect JDBC4. Would that be acceptable? What does the "edition" represent? Would this mean the first release of the 10.2 documentation set would be partially at the "second edition", doesn't seem to make sense to me. Dan.
[jira] Created: (DERBY-1439) Investigate removing the antiGC thread in embedded Derby
Investigate removing the antiGC thread in embedded Derby Key: DERBY-1439 URL: http://issues.apache.org/jira/browse/DERBY-1439 Project: Derby Type: Improvement Components: Services Reporter: Daniel John Debrunner Priority: Minor The antiGC thread was originally created to avoid the DriverManager class being garbage collected when no refrences existed to it and it had loaded the embedded JDBC driver (and hence shutting down the engine). This was an issue with JDK 1.1. Since Derby does not support jdk1.1 and garbage collection of classes is clearly defined, it is possible the thread serves no useful purpose. -- 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: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
Knut Anders Hatlen wrote: > Daniel John Debrunner <[EMAIL PROTECTED]> writes: > > >>David Van Couvering wrote: >> >>>Good news Lance, thanks, I was getting worried if we were going to have >>>to regularly change column order and break existing applications/IDEs/etc. >> >>Hopefully we don't have any documented Derby specific additional columns >>in the metadata, that would be non-standard. > > > The only non-standard columns we have are METHOD_ID and PARAMETER_ID > in getProcedureColumns and getFunctionParameters. For > getProcedureColumns, they are documented in the reference manual. Yes they are documented, but not in any useful way. There is no description of what they represent, only the text: "a Derby-specific column". I think METHOD_ID could be removed, it's an artifact of the old way Cloudscape used to support non-standard method aliases. Dan.
Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
Rick Hillegas wrote: David Van Couvering wrote: Rick Hillegas wrote: Hi David, I had a couple more comments on the compatibility commitments. Cheers-Rick - Changes to stored procedures: We will have to change column order if we add Derby-specific columns to a metadata ResultSet and then a later JDBC also adds more columns. See Lance's email; OK to leave as is? I thought the gist of Lance's response was this: It's ok to add vendor-specific columns to metadata ResultSets. However, the leading columns of the ResultSet must be the columns described in the JDBC spec and those columns must appear in the specified order. After that the order of vendor-specific columns doesn't matter. However, the names of those vendor-specific columns do matter; those names are the stable interface. I don't think the existing text on the compatibility webpage captures this. OK, I'll work on that - Changes to Database Tables: We should be allowed to drop indexes on System tables. OK - Changes to Command Line Interfaces. I don't understand why error message text can't be changed. This contradicts what is said in the Interface Table below. Hm, good point. I suppose changing the error message text *is* an incompatible change, but given that the interface is private, it's OK to do it. But it is a confusing message. Any suggestions? I can (a) remove error message text from the list of incompatible changes (b) keep it, but clarify that this is a private interface (c) make error message text a public interface My vote is for (a). Anyone disagree? That's my vote too, thanks. OK - Other miscellaneous formats. I'm not clear on what these miscellaneou files and strings are. For example, I'd like to make sure that we're not enshrining the current RUNTIMESTATISTICS output. Again, I think this goes back to the same point. It's not clear what the relationship is to the classification of an interface in the interfaces table and what it means to make an incompatible change. I think you're assuming incompatible changes can only apply to public interfaces, because it's really kind of moot/inapplicable for private interfaces. I think there's value in describing what it means to make an incompatible interface change, but I think the ultimate "truth" in terms of what we actually support in terms of interface stability across releases is described in the interfaces table. I think some text in the "incompatible changes" section clarifying this would be helpful. Any thoughts? I can see that Private Stable applies to the client/server api. These apis should remain forward/backward compatible within a release family. Do Private Stable interfaces turn up in other situations? Yes, that's right. I wonder if the database file format is also Private Stable. I am still looking for some guidance in that area in terms of what are incompatible changes... David - Interface table: o Shouldn't the public client api be stable like the embedded api? Yes o What is meant by "Defaults returned by DatabaseMetadata methods"? I don't know, I think I put this in as feedback from someone else. Can anyone clarify? o I think that the format of RUNTIMESTATISTICS output is unstable. OK, anyone disagree? Thanks for your review, Rick! David David Van Couvering wrote: Hi, all. I am thinking of setting up two separate votes based on the Wiki page at http://wiki.apache.org/db-derby/ForwardCompatibility The first one would be on our overall model/approach to making compatibility commitments, as described in the Wiki page. The second would be specifically for the interface table, targetted at the 10.2 release. The reason for separating these out is because, for each release, we should update the interface table and have a new vote; the overall model/approach does not need to be updated or voted on for each release. I would copy the appropriate text directly into the email for the vote, so that the thing we're voting on is a frozen snapshot, not a live document like the Wiki page. I'd like your feedback on this approach. I'd also like to make sure there aren't any lingering issues with the Wiki page as it stands, before I go through the process of running a vote. Thanks, David
[jira] Created: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver
Text written by SQLException.toString differs between client and embedded driver Key: DERBY-1438 URL: http://issues.apache.org/jira/browse/DERBY-1438 Project: Derby Type: Improvement Components: JDBC, Newcomer Versions: 10.2.0.0 Environment: Sun JDK 1.5 Reporter: Olav Sandstaa Priority: Trivial The first part of the string written by SQLExeption.toString() differs between the Derby client driver and the embedded driver. The embedded driver writes: SQL Exception: Table/View 'DERBYDB' does not exist. while the client driver writes: java.sql.SQLException: Table/View 'DERBYDB' does not exist. It would be good if we changed this so the same text is written by both drivers. This reduces the difference seen when changing between client and embedded Derby and it make it possible to reduce the amount of sed-ing or the number of master file variants for some tests. -- 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-1271) Release documentation for JDBC4 release
Jean T. Anderson wrote: Rick Hillegas wrote: Thanks, Jean. The Edition line turns up in the visible text which appears in the printed document. That makes me think that it applies to something that the customer, the reader, cares about. I don't think the reader is particularly concerned about our transition to dita. If that is what Edition is supposed to capture, perhaps the Edition lines should be moved to a comments section so that they will not be visible/confusing to customers. The Developers Guide has a "first edition" for both 10.0 and 10.1: http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html I don't know why the Edition was bumped for the others. :-) If there isn't a major change to the content of the book, I don't think the edition should be bumped. "Working With Derby" should definitely not be bumped from First to Second edition since 10.2 will be its first release. I could just bump the edition for the Reference Guide, which will carry a lot of edits to reflect JDBC4. Would that be acceptable? -jean
Re: [jira] Commented: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger
On 6/22/06, Øystein Grøvlen (JIRA) wrote: I have sometimes seen the same error message in another context. See DERBY-637. No triggers involved in my case and not easily reproduced (but I have seen it several times). I had to shutdown and restart the database to make the error disappers. I took a quick look at DERBY-637 to see if there is anything similar to the scenario in DERBY-1435. I am new to these areas but I think it will be good if we have a repro. Someone more familiar may be able to deduct something. If you still have the repro, it would be helpful if you can post it. Thanks, Deepa
[jira] Commented: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger
[ http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12417323 ] Deepa Remesh commented on DERBY-1435: - Thanks for looking into this Suresh. Now, I can see this from the traces too. We are re-using the prepared statement after table t1 is dropped. Here are the stack traces from ij for execution of a new statement (insert into t2 values(2)) and a previously executed statement (insert into t2 values(1)) after table t1 is dropped: ij> --- these inserts should not work, but the second insert gives XSAI2 insert into t2 values(2); ERROR 42X05: Table/View 'T1' does not exist. ERROR 42X05: Table/View 'T1' does not exist. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304) at org.apache.derby.impl.sql.compile.DMLModStatementNode.verifyTargetTable(DMLModStatementNo de.java:230) at org.apache.derby.impl.sql.compile.InsertNode.bind(InsertNode.java:248) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344) at org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:35 3) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:2 83) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:3 03) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.jav a:690) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.jav a:651) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecuto r.java:138) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java: 110) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator .java:277) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1 134) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:522) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java: 361) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:207) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) ij> insert into t2 values(1); ERROR XSAI2: The conglomerate (896) requested does not exist. ERROR XSAI2: The conglomerate (896) requested does not exist. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304) at org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(HeapCong lomerateFactory.java:224) at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.jav a:484) at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction .java:389) at org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(RAMTransa ction.java:701) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.(DMLWriteResultSet.java:82) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.(DMLWriteResultSet.java:66) at org.apache.derby.impl.sql.execute.InsertResultSet.(InsertResultSet.java:343) at org.apache.derby.impl.sql.execute.GenericResultSetFactory.getInsertResultSet(GenericResul tSetFactory.java:95) at org.apache.derby.exe.ac46a08075x010bxfc52x1188x001171d80.fillResultSet(Unknown Source ) at org.apache.derby.exe.ac46a08075x010bxfc52x1188x001171d80.execute(Unknown Source) at org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:32 6) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java: 359) at org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecuto r.java:169) at org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java: 110) at org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator .java:277) at org.apache.d
Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release
Rick Hillegas wrote: > Thanks, Jean. The Edition line turns up in the visible text which > appears in the printed document. That makes me think that it applies to > something that the customer, the reader, cares about. I don't think the > reader is particularly concerned about our transition to dita. If that > is what Edition is supposed to capture, perhaps the Edition lines should > be moved to a comments section so that they will not be > visible/confusing to customers. The Developers Guide has a "first edition" for both 10.0 and 10.1: http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html I don't know why the Edition was bumped for the others. :-) If there isn't a major change to the content of the book, I don't think the edition should be bumped. "Working With Derby" should definitely not be bumped from First to Second edition since 10.2 will be its first release. -jean
[jira] Updated: (DERBY-955) Get derbyall on jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ] Olav Sandstaa updated DERBY-955: Derby Info: [Patch Available] > Get derbyall on jdk1.6 > -- > > Key: DERBY-955 > URL: http://issues.apache.org/jira/browse/DERBY-955 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Anurag Shekhar > Fix For: 10.2.0.0 > Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, > bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, > bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff > > This bug is a placeholder for patches which enable derbyall to run on jdk1.6. -- 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-955) Get derbyall on jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-955?page=all ] Olav Sandstaa updated DERBY-955: Attachment: bug955_derbyall.diff This patch contains fixes to the following tests that are failing when running derbyall with jdk 1.6: * derbynetclientmats: tools/ieptests.sql -updated master file for jdk16 * derbynetclientmats: jdbcapi/parameterMappint.java -REMOVED jdk16 specific master file * derbynetclientmats: jdbcapi/checkDataSource30.java -updated checkDataSource30.java and checkDataSource.java to produce output that is the same when running with jdk15 and jdk16 -updated master files to reflect changes in output * derbynetmats: tools/ieptests.sql -updated master file for jdk16 svn status reports: M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/checkDataSource30.java M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/checkDataSource.java M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk16/ieptests.out M java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource30.out D java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/parameterMapping.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/ieptests.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/checkDataSource.out M java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/checkDataSource30.out M java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource.out Note: one master file has been removed. I have run derbyall with jdk 1.5 and 1.6. The patch is ready for review and commit. > Get derbyall on jdk1.6 > -- > > Key: DERBY-955 > URL: http://issues.apache.org/jira/browse/DERBY-955 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Anurag Shekhar > Fix For: 10.2.0.0 > Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, > bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, > bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff > > This bug is a placeholder for patches which enable derbyall to run on jdk1.6. -- 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-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed
[ http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12417318 ] Deepa Remesh commented on DERBY-1395: - I had seen the first scenario (both connection and statement closed) in jdbcapi/checkDataSource.java.This is in the checkConnection method. The scenario Knut mentions is covered in ClosedObjectTest.java. > Change the client SQLState to match that of embedded for the exception thrown > on a closed statement whose connection is also closed > --- > > Key: DERBY-1395 > URL: http://issues.apache.org/jira/browse/DERBY-1395 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.3.0 > Reporter: Deepa Remesh > Assignee: David Van Couvering > Priority: Trivial > > Scenario: Both connection and statement are closed and an operation is > performed on a closed statement. SQLStates are as follows: > Embedded: SQLSTATE: XJ012, Message: Statement Closed > Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed > Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed > This issue is related to the effort started in DERBY-254. -- 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-1313) SUR: Use DRDA's extended diagnostic to send ROW_UPDATED and ROW_DELETED warnings.
[ http://issues.apache.org/jira/browse/DERBY-1313?page=all ] Fernanda Pizzorno updated DERBY-1313: - Attachment: derby-1313v1.pdf The attached document (derby-1313v1.pdf) contains a short description of the work done in DERBY-1313 and DERBY-1374, and some thoughts of what is needed in order to extend this work to cover other warnings and exception. > SUR: Use DRDA's extended diagnostic to send ROW_UPDATED and ROW_DELETED > warnings. > - > > Key: DERBY-1313 > URL: http://issues.apache.org/jira/browse/DERBY-1313 > Project: Derby > Type: Bug > Components: JDBC > Reporter: Fernanda Pizzorno > Assignee: Fernanda Pizzorno > Attachments: derby-1313.diff, derby-1313.stat, derby-1313v1.pdf, > derby-1313v2.diff, derby-1313v2.stat, derby-1313v3.diff, derby-1313v3.stat > > Detectability of own changes is implemented in the client using warnings cf > the write-up for DERBY-775. When a row has been deleted and/or updated, a > warning will be sent to the client to indicate that fact. Presently, only one > warning can be sent each time a data row is sent from to the client, that > means that some warnings may be lost. Using extended diagnostic allows us to > send several warnings for each data row. > I propose to use extended diagnostics to send ROW_UPDATED and ROW_DELETED > warnings when necessary. This may later be extended for other warnings, but I > do not plan to do it as a part of the work in this issue. -- 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: ADVICE REQUESTED: Fixing MessageBundleTest
Hi David, You might want to wrap the test in a custom Ant Task. These are described in the Ant manual: "Developing with Ant"->"Writing Your Own Task". You can then check the return status of the task and fail the build if appropriate. Regards, -Rick David Van Couvering wrote: Hm, a build-time check. I guess in a way it is a build-time issue. Let me think about how I might do that, thanks for the idea. David Daniel John Debrunner wrote: David Van Couvering wrote: So, as Andrew very astutely pointed out, i18n/MessageBundleTest.java will not succeed when running against the jar files because it tries to load shared/common/reference/SQLState, which is not included in the jar files. This problem also exists for MessageId.java, which this test also refers to and which also is not included in the jar files. Does this need to be a test, could it be converted into a build time check? Then there are no requirements for these classes to be in derbytesting.jar. Also there is probably no requirement to run this test on different platforms. I used to have something similar (pre-open source), that found messages that existed but were never used. Dan.
Re: Tuncation of trailing blanks and lengthless streaming overloads
Kristian Waagan wrote: > Hello, > > I'm working on DERBY-1417; adding new lengthless overloads to the > streaming API. So far, I have only been looking at implementing this in > the embedded driver. Based on some comments in the code, I have a few > questions and observations regarding truncation of trailing blanks in > the various character data types. > > TypeTrail. blank trunc. Where > > CHARallowed SQLChar.normalize > VARCHAR allowed SQLVarchar.normalize > LONG VARCHAR disallowed SQLLongVarchar.normalize > CLOBallowed streaming or > SQLVarchar.normalize, depending > on source. > > As can be seen, only data for CLOB is truncated for trailing blanks in > the streaming class. We must still read all the data, or so much as we > need to know the insertion will fail, but we don't have to store it all > in memory. > > Truncation of trailing blanks is not allowed at all for LONG VARCHAR > (according to code comments and bug 5592 - haven't found the place this > is stated in the specs). > > My question is, should we do the truncate check for CHAR and VARCHAR on > the streaming level as well? > If we don't add this feature, inserting a > 10GB file into a VARCHAR field by mistake will cause 10GB to be loaded > into memory even though the max size allowed is ~32K, possibly causing > out-of-memory errors. The error could be generated at an earlier stage > (possibly after reading ~32K +1 bytes). I would say its a separate issue to the one you are addressing. Applications most likely won't be inserting 10Gb values into CHAR/VARCHAR columns using streams as it's not going to work. Maybe enter a bug, but doesn't seem it has to be fixed as part of this issue. > As far as I can tell, adding this feature is a matter of modifying the > 'ReaderToUTF8' class and the > 'EmbedPrearedStatement.setCharacterStreamInternal' method. > One could also optimize the reading of data into LONG VARCHAR, where one > would abort the reading as soon as you can instead of taking it all into > memory first. This would require some special case handling in the > mentioned locations. > > > Another matter is that streams will not be checked for exact length > match when using the lengthless overloads, as we don't have a specified > length to compare against. > I have a preliminary implementation for setAsciiStream, > setCharacterStream and setClob (all without length specifications) in > EmbedPreparedStatement. What's the issue with setClob()? The current method doesn't take a length. Has java.sql.Clob been changed to not always have a length? Dan.
[jira] Updated: (DERBY-1361) positioned updates and deletes allowed after a commit without repositioning the cursor - if the table is indexed on the columns selected
[ http://issues.apache.org/jira/browse/DERBY-1361?page=all ] Andreas Korneliussen updated DERBY-1361: Attachment: DERBY-1361v2.diff DERBY-1361v2.stat Attaching an updated patch. Two more master files had to be updated because of the error code change. With this latest patch, I have run derbyall with no failures. I will until next week days before I commit this patch, in case anyone would like to give some review comments. > positioned updates and deletes allowed after a commit without repositioning > the cursor - if the table is indexed on the columns selected > > > Key: DERBY-1361 > URL: http://issues.apache.org/jira/browse/DERBY-1361 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Environment: Java 1.4 > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > Attachments: DERBY-1361.diff, DERBY-1361.stat, DERBY-1361v2.diff, > DERBY-1361v2.stat > > After a commit, the cursor should be positioned before the next row (not on a > row). However in Derby 10.2, I now see the following behavior if the table > has an index on the selected columns: > ij> create table t (id int primary key); > ij> commit; > ij> insert into t values 1,2,3,4,5,6,7,8,9; > 9 rows inserted/updated/deleted > ij> commit; > ij> get cursor c1 as 'select * from t for update'; > ij> next c1; > ID > --- > 1 > ij> commit; > ij> update t set id=id+1000 where current of c1; > 1 row inserted/updated/deleted > ij> commit; > ij> update t set id=id+1000 where current of c1; > 1 row inserted/updated/deleted > ij> > The expected behavior is that the UPDATE .. WHERE CURRENT OF fails with: > ERROR 24000: Invalid cursor state - no current row. > The problem applies to both scrollable and forward-only updatable cursors. > Note: If the table is created *without* the index, I do see the expected > behavior. > I am marking this as a regression, since this issue is not reproducible on > older, released versions of derby (I have tested with 10.1.2.1). -- 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-1271) Release documentation for JDBC4 release
Thanks, Jean. The Edition line turns up in the visible text which appears in the printed document. That makes me think that it applies to something that the customer, the reader, cares about. I don't think the reader is particularly concerned about our transition to dita. If that is what Edition is supposed to capture, perhaps the Edition lines should be moved to a comments section so that they will not be visible/confusing to customers. Regards, -Rick Jean T. Anderson wrote: Rick Hillegas (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick Hillegas updated DERBY-1271: - Attachment: derby-1271_copyrights.diff Attaching derby-1271_copyrights.diff. This adjusts dates in the visible copyright notices in the user guides. Touches the following files: The update of the copyright line looks fine to me, but I'm not so sure about the change of the "Second Edition (July 2005)" line to "Third Edition (July 2006)". I don't know the "Edition" history -- suspect it maps to the conversion of the source docs to DITA. Does anyone know for sure? -jean
Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table
David Van Couvering wrote: Rick Hillegas wrote: Hi David, I had a couple more comments on the compatibility commitments. Cheers-Rick - Changes to stored procedures: We will have to change column order if we add Derby-specific columns to a metadata ResultSet and then a later JDBC also adds more columns. See Lance's email; OK to leave as is? I thought the gist of Lance's response was this: It's ok to add vendor-specific columns to metadata ResultSets. However, the leading columns of the ResultSet must be the columns described in the JDBC spec and those columns must appear in the specified order. After that the order of vendor-specific columns doesn't matter. However, the names of those vendor-specific columns do matter; those names are the stable interface. I don't think the existing text on the compatibility webpage captures this. - Changes to Database Tables: We should be allowed to drop indexes on System tables. OK - Changes to Command Line Interfaces. I don't understand why error message text can't be changed. This contradicts what is said in the Interface Table below. Hm, good point. I suppose changing the error message text *is* an incompatible change, but given that the interface is private, it's OK to do it. But it is a confusing message. Any suggestions? I can (a) remove error message text from the list of incompatible changes (b) keep it, but clarify that this is a private interface (c) make error message text a public interface My vote is for (a). Anyone disagree? That's my vote too, thanks. - Other miscellaneous formats. I'm not clear on what these miscellaneou files and strings are. For example, I'd like to make sure that we're not enshrining the current RUNTIMESTATISTICS output. Again, I think this goes back to the same point. It's not clear what the relationship is to the classification of an interface in the interfaces table and what it means to make an incompatible change. I think you're assuming incompatible changes can only apply to public interfaces, because it's really kind of moot/inapplicable for private interfaces. I think there's value in describing what it means to make an incompatible interface change, but I think the ultimate "truth" in terms of what we actually support in terms of interface stability across releases is described in the interfaces table. I think some text in the "incompatible changes" section clarifying this would be helpful. Any thoughts? I can see that Private Stable applies to the client/server api. These apis should remain forward/backward compatible within a release family. Do Private Stable interfaces turn up in other situations? - Interface table: o Shouldn't the public client api be stable like the embedded api? Yes o What is meant by "Defaults returned by DatabaseMetadata methods"? I don't know, I think I put this in as feedback from someone else. Can anyone clarify? o I think that the format of RUNTIMESTATISTICS output is unstable. OK, anyone disagree? Thanks for your review, Rick! David David Van Couvering wrote: Hi, all. I am thinking of setting up two separate votes based on the Wiki page at http://wiki.apache.org/db-derby/ForwardCompatibility The first one would be on our overall model/approach to making compatibility commitments, as described in the Wiki page. The second would be specifically for the interface table, targetted at the 10.2 release. The reason for separating these out is because, for each release, we should update the interface table and have a new vote; the overall model/approach does not need to be updated or voted on for each release. I would copy the appropriate text directly into the email for the vote, so that the thing we're voting on is a frozen snapshot, not a live document like the Wiki page. I'd like your feedback on this approach. I'd also like to make sure there aren't any lingering issues with the Wiki page as it stands, before I go through the process of running a vote. Thanks, David
[jira] Created: (DERBY-1437) Add new LRU Cache Manager
Add new LRU Cache Manager - Key: DERBY-1437 URL: http://issues.apache.org/jira/browse/DERBY-1437 Project: Derby Type: Improvement Components: Services Reporter: Gokul Soundararajan Assigned to: Gokul Soundararajan In databases, caching plays an important role in performance. To obtain high performance, we need to cache pages from disk in memory to reduce access time. The problem stated is that the existing replacement algorithm performs poorly so we need to research new algorithms for page replacement and implement it in Apache Derby. The benefit of a better algorithm is improved performance. In this project, I first have to look at existing work to quantify the different replacement algorithms used in databases. I have run simulation experiments on several cache replacement algorithms from FIFO, Clock, Clock-Pro, TwoQueue, CAR, and CART. CAR/CART are patented by IBM so we cannot implement them in Derby. Two Queue has a large synchronization overhead (seen by Postgres community). Clock-Pro performs well and is being implemented in Linux. Oystein and I have agreed to implement Clock-Pro inside Derby. See the wiki for more details and simulation results: http://wiki.apache.org/db-derby/DerbyLruCacheManager I will implement it in Derby. In addition, I will implement unit tests. Finally, I will perform experiments showing the benefit of the new algorithm over the existing algorithm. -- 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
Tuncation of trailing blanks and lengthless streaming overloads
Hello, I'm working on DERBY-1417; adding new lengthless overloads to the streaming API. So far, I have only been looking at implementing this in the embedded driver. Based on some comments in the code, I have a few questions and observations regarding truncation of trailing blanks in the various character data types. TypeTrail. blank trunc. Where CHARallowed SQLChar.normalize VARCHAR allowed SQLVarchar.normalize LONG VARCHAR disallowed SQLLongVarchar.normalize CLOBallowed streaming or SQLVarchar.normalize, depending on source. As can be seen, only data for CLOB is truncated for trailing blanks in the streaming class. We must still read all the data, or so much as we need to know the insertion will fail, but we don't have to store it all in memory. Truncation of trailing blanks is not allowed at all for LONG VARCHAR (according to code comments and bug 5592 - haven't found the place this is stated in the specs). My question is, should we do the truncate check for CHAR and VARCHAR on the streaming level as well? If we don't add this feature, inserting a 10GB file into a VARCHAR field by mistake will cause 10GB to be loaded into memory even though the max size allowed is ~32K, possibly causing out-of-memory errors. The error could be generated at an earlier stage (possibly after reading ~32K +1 bytes). As far as I can tell, adding this feature is a matter of modifying the 'ReaderToUTF8' class and the 'EmbedPrearedStatement.setCharacterStreamInternal' method. One could also optimize the reading of data into LONG VARCHAR, where one would abort the reading as soon as you can instead of taking it all into memory first. This would require some special case handling in the mentioned locations. Another matter is that streams will not be checked for exact length match when using the lengthless overloads, as we don't have a specified length to compare against. I have a preliminary implementation for setAsciiStream, setCharacterStream and setClob (all without length specifications) in EmbedPreparedStatement. I will continue my work by adding methods throwing not-implemented-exceptions and implement the methods where appropriate. Thoughts and feedback appreciated :) -- Kristian
[jira] Assigned: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen reassigned DERBY-1393: - Assign To: Knut Anders Hatlen > PreparedStatement.setObject(Object,int,int) should throw for unsupported types > -- > > Key: DERBY-1393 > URL: http://issues.apache.org/jira/browse/DERBY-1393 > Project: Derby > Type: Bug > Components: JDBC, SQL > Versions: 10.2.0.0 > Environment: JDBC 4, jdk 1.6 > Reporter: Dyre Tjeldvoll > Assignee: Knut Anders Hatlen > Priority: Minor > Fix For: 10.2.0.0 > > From the javadoc: > Throws: > ... > SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, > CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, > ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this > data type > Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, > LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw > SQLFeatureNotSupportedException if used with any of these types. Currently a > general type conversion exception is thrown: > >>1) > >>testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL > >> Exception: An attempt was made to get a data value of type 'CLOB' from a > >>data value of type '2003'. > >>Caused by: SQL Exception: An attempt was made to get a data value of type > >>'CLOB' from a data value of type '2003'. -- 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-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger
[ http://issues.apache.org/jira/browse/DERBY-1435?page=comments#action_12417279 ] Øystein Grøvlen commented on DERBY-1435: I have sometimes seen the same error message in another context. See DERBY-637. No triggers involved in my case and not easily reproduced (but I have seen it several times). I had to shutdown and restart the database to make the error disappers. > Conglomerate does not exist occurs in a specific case after dropping a table > referenced by a trigger > > > Key: DERBY-1435 > URL: http://issues.apache.org/jira/browse/DERBY-1435 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.2.0.0 > Reporter: Deepa Remesh > Attachments: repro1435.sql > > This exception occurs in the following case: > 1. Create tables t1 and t2. Create a trigger on t2 whose triggering action is > to insert a row into t1 > 2. Insert a value v1 into t2. Verify the trigger was fired by looking at > contents of t1. > 3. Drop table t1. > 4. Insert a value v2 into t2. This will give an exception to indicate that > table t1 does not exist. > 5. Insert the same value v1 into t2. Instead of the exception in Step 4, this > gives "ERROR XSAI2: The conglomerate (896) requested does not exist." > 6. Re-create table t1. > 7. Insert v2 into t2. This succeeds. > 8. Try to insert the problem value v1 into t2. This still gives "ERROR XSAI2: > The conglomerate (896) requested does not exist." > 9. Shutdown and reconnect to the database. Try to insert the problem value v1 > into t2. Now this succeeds. > So the exception occurs only in the specific case where we try to insert the > same value that we had inserted before dropping the table referenced by the > trigger. I'll attach a sql script to repro this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1417) Add new, lengthless overloads to the streaming api
[ http://issues.apache.org/jira/browse/DERBY-1417?page=all ] Kristian Waagan reassigned DERBY-1417: -- Assign To: Kristian Waagan > Add new, lengthless overloads to the streaming api > -- > > Key: DERBY-1417 > URL: http://issues.apache.org/jira/browse/DERBY-1417 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Kristian Waagan > Fix For: 10.2.0.0 > Attachments: derby-1417-01-castsInTests.diff > > The JDBC4 Expert Group has approved a new set of overloads for the streaming > methods. These overloads do not take a length argument. Here are the new > overloads: > PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x) > PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x) > PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader > reader) > PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader > reader) > PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream) > PreparedStatement.setClob(int parameterIndex, java.io.Reader reader) > PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader) > CallableStatement.setAsciiStream(java.lang.String parameterName, > java.io.InputStream x) > CallableStatement.setBinaryStream(java.lang.String parameterName, > java.io.InputStream x) > CallableStatement.setCharacterStream(java.lang.String parameterName, > java.io.Reader reader) > CallableStatement.setNCharacterStream(java.lang.String parameterName, > java.io.Reader reader) > CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream > inputStream) > CallableStatement.setClob(java.lang.String parameterName, java.io.Reader > reader) > CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader > reader) > ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x) > ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream > x) > ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x) > ResultSet.updateBinaryStream(java.lang.String columnLabel, > java.io.InputStream x, int length) > ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x) > ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader > x) > ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x) > ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader > x) > ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream) > ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream > inputStream) > ResultSet.updateClob(int columnIndex, java.io.Reader reader) > ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader) > ResultSet.updateNClob(int columnIndex, java.io.Reader reader) > ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader) > We should add these new overloads soon so that the build will not break when > this methods turn up in a published Mustang build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - Derby 416051 - Sun DBTG
[Auto-generated mail] *Derby* 416051/2006-06-21 19:46:07 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 15715700 0 106.56% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-416051.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/416051.html *Jvm: 1.5* 3675672 2 109.05% CYGWIN_NT-5.1_i686-unknown 2675673 2 115.78% CYGWIN_NT-5.2_i686-unknown 0675675 2 120.56% Linux-2.6.14-1.1644_FC4_i686-i686 0675675 2 105.59% Linux-2.6.9-34.ELsmp_x86_64-x86_64 1675674 2 176.96% SunOS-5.10_i86pc-i386 0675675 2 137.18% SunOS-5.10_sun4u-sparc 0675675 2 108.09% SunOS-5.11_i86pc-i386 0675675 2 113.59% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-416051.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/416051.html *Jvm: 1.4* 2669667 4 105.30% CYGWIN_NT-5.1_i686-unknown 3669666 4 144.69% Linux-2.6.14-1.1644_FC4_i686-i686 0669669 4 105.85% Linux-2.6.9-34.ELsmp_x86_64-x86_64 2669667 4 209.67% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-416051.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/416051.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/416051.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Created: (DERBY-1436) setEmbeddedCP.ksh and setNetworkCleitn.ksh does not work or gives wrong error message
setEmbeddedCP.ksh and setNetworkCleitn.ksh does not work or gives wrong error message - Key: DERBY-1436 URL: http://issues.apache.org/jira/browse/DERBY-1436 Project: Derby Type: Bug Components: Demos/Scripts Environment: Linux atum01 2.6.16-1.2096_FC4 Reporter: Bernt M. Johnsen setEmbeddedCP.ksh (and setNetworkClient.ksh) gives the following message if neither DERBY_HOME nor DERBY_INSTALL is set: echo "\$DERBY_HOME or \$DERBY_INSTALL not set. Please set one of these variables" echo "to the location of your Derby installation." but the scripts do not work if only DERBY_HOME is set -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
