[jira] Closed: (DERBY-460) Create error message documentation out of code
[ http://issues.apache.org/jira/browse/DERBY-460?page=all ] Jeff Levitt closed DERBY-460: - Resolution: Duplicate David Van Couvering long ago submitted a script that takes care of this, so I am cancelling my own bug Create error message documentation out of code -- Key: DERBY-460 URL: http://issues.apache.org/jira/browse/DERBY-460 Project: Derby Type: Improvement Components: Build tools Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 As David suggested in the following thread: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] We need a way to generate a DITA file for the Reference Manual from the messages themselves, so that when new messages are added or changes are made, they are propogated to the documentation. The requirements are: - Some way of keeping metadata for the DITA file (parameter values, user response, explanation) in comments within the messages file, or perhaps using an XML document to store the data and the strings? - A script or xsl transform that reads the messages and generates the DITA file, adding the metadata where necessary. - A script to do a one-time conversion of the DITA file to the messages file (whether it be the current method of storing message plus comments or an XML file) so that existing messages will be in the new format. Then, any new messages must follow the format. -- 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] Closed: (DERBY-460) Create error message documentation out of code
David, do you know the JIRA issue number under which you submitted the script? --- David Van Couvering [EMAIL PROTECTED] wrote: I submitted a script, but it does not appear to be being used. Unless I'm missing something? David Jeff Levitt (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-460?page=all ] Jeff Levitt closed DERBY-460: - Resolution: Duplicate David Van Couvering long ago submitted a script that takes care of this, so I am cancelling my own bug Create error message documentation out of code -- Key: DERBY-460 URL: http://issues.apache.org/jira/browse/DERBY-460 Project: Derby Type: Improvement Components: Build tools Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 As David suggested in the following thread: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] We need a way to generate a DITA file for the Reference Manual from the messages themselves, so that when new messages are added or changes are made, they are propogated to the documentation. The requirements are: - Some way of keeping metadata for the DITA file (parameter values, user response, explanation) in comments within the messages file, or perhaps using an XML document to store the data and the strings? - A script or xsl transform that reads the messages and generates the DITA file, adding the metadata where necessary. - A script to do a one-time conversion of the DITA file to the messages file (whether it be the current method of storing message plus comments or an XML file) so that existing messages will be in the new format. Then, any new messages must follow the format. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Closed: (DERBY-460) Create error message documentation out of code
Ah I remember now, we wanted to get the DITA file correct for 10.1, and worry about the script later. Now that it's later, what do people think about using David's script in the nightly builds? Is this something that is even possible? --- David Van Couvering [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/DERBY-296 Jeff Levitt wrote: David, do you know the JIRA issue number under which you submitted the script? --- David Van Couvering [EMAIL PROTECTED] wrote: I submitted a script, but it does not appear to be being used. Unless I'm missing something? David Jeff Levitt (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-460?page=all ] Jeff Levitt closed DERBY-460: - Resolution: Duplicate David Van Couvering long ago submitted a script that takes care of this, so I am cancelling my own bug Create error message documentation out of code -- Key: DERBY-460 URL: http://issues.apache.org/jira/browse/DERBY-460 Project: Derby Type: Improvement Components: Build tools Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 As David suggested in the following thread: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] We need a way to generate a DITA file for the Reference Manual from the messages themselves, so that when new messages are added or changes are made, they are propogated to the documentation. The requirements are: - Some way of keeping metadata for the DITA file (parameter values, user response, explanation) in comments within the messages file, or perhaps using an XML document to store the data and the strings? - A script or xsl transform that reads the messages and generates the DITA file, adding the metadata where necessary. - A script to do a one-time conversion of the DITA file to the messages file (whether it be the current method of storing message plus comments or an XML file) so that existing messages will be in the new format. Then, any new messages must follow the format. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Closed: (DERBY-460) Create error message documentation out of code
--- David Van Couvering [EMAIL PROTECTED] wrote: I would like to support Andrew's suggestion, with a minor amendment. I think it makes sense to run this for every snapshot as well as for the release, to bring the messages up-to-date for the snapshot build. David Andrew McIntyre wrote: On 6/26/06, Jeff Levitt [EMAIL PROTECTED] wrote: Ah I remember now, we wanted to get the DITA file correct for 10.1, and worry about the script later. Now that it's later, what do people think about using David's script in the nightly builds? Is this something that is even possible? -0.9 To integrate it into the doc build, the doc build would need to guarantee that you have the latest build from the code tree available. Currently the doc and code builds are not coupled together in any way. I think the fact that the doc build is not dependent on the code build is an advantage, especially for contributors who are just interested in building the documentation. Maybe this is something that could be done maybe once a release, or whenever someone notices the doc and code have drifted apart significantly. andrew Sounds reasonable to me... __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
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] Commented: (DERBY-1268) Add description of derby.drda.streamOutBufferSize to Derby Server and Administration Guide
[ http://issues.apache.org/jira/browse/DERBY-1268?page=comments#action_12414656 ] Jeff Levitt commented on DERBY-1268: Looks great! Just a legal nit (I think). Since this is a newly contributed source file in 2006, shouldn't the Apache copyright statement at the beginning of the dita source file be 2006 instead of 2005? Add description of derby.drda.streamOutBufferSize to Derby Server and Administration Guide Key: DERBY-1268 URL: http://issues.apache.org/jira/browse/DERBY-1268 Project: Derby Type: Sub-task Components: Documentation Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama Attachments: DERBY-1268.patch, DERBY-1268_2.patch New property , derby.drda.streamOutBufferSize was added in DERBY-326. We need to reflect this modification to Derby Server and Administration Guide url of the repository : https://svn.apache.org/repos/asf/db/derby/docs/trunk/src/adminguide/tadminconfigsettingnetwrokserverproperties.dita url of html rendered : http://db.apache.org/derby/docs/10.1/adminguide/tadminconfigsettingnetwrokserverproperties.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1359) Developers guide: example showing shut down of Derby system should not contain a database name
[ http://issues.apache.org/jira/browse/DERBY-1359?page=all ] Jeff Levitt updated DERBY-1359: --- Derby Info: [Patch Available] Developers guide: example showing shut down of Derby system should not contain a database name -- Key: DERBY-1359 URL: http://issues.apache.org/jira/browse/DERBY-1359 Project: Derby Type: Bug Components: Documentation Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.1.2.4, 10.2.0.0, 10.1.3.0 Reporter: Olav Sandstaa Priority: Trivial Attachments: derby1359.diff, tdevdvlp20349.html In the Developers Guide the chapter Shutting Down the System gives the following command to shut down the Derby system: DriverManager.getConnection(jdbc:derby:cs;shutdown=true); This command should not include the name of a database (cs). The correct command should be: DriverManager.getConnection(jdbc:derby:;shutdown=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: [VOTE] Halley Pacheco de Oliveira as committer
I'll throw my vote in now as well... [X] +1 Yes, Halley should become a committer -Jeff
Re: [jira] Updated: (DERBY-1175) Derby Server and Administration Guide - Accessing the Network Server by using the DB2 Universal Driver
Hi Halley, Sorry, what I meant was to attach HTML output of the documentation showing your changes in them. I didnt mean to create an html version of the patch file itself. But dont worry about it, your patch has already been committed. On future patches, just remember to create html output using the dita toolkit and include them for other people to review. Thanks! Jeff --- Halley Pacheco de Oliveira (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-1175?page=all ] Halley Pacheco de Oliveira updated DERBY-1175: -- Attachment: cadminapps810777.diff.html Jeff, the file cadminapps810777.diff.html attached is the file cadminapps810777.diff HTMLized using a jEdit plugin. I hope this is what you want, but if it is not what you want please let me know. Derby Server and Administration Guide - Accessing the Network Server by using the DB2 Universal Driver -- Key: DERBY-1175 URL: http://issues.apache.org/jira/browse/DERBY-1175 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.3 Environment: DITA files Reporter: Halley Pacheco de Oliveira Fix For: 10.1.2.3 Attachments: cadminapps810777.diff, cadminapps810777.diff.html In Accessing the Network Server by using the DB2 Universal Driver is written: logWriter A character output stream. All logging and tracing messages print to the logWriter property. traceLevel Specifies the granularity of logging messages to the logWriter property. traceFile Provides an explicit file location for the trace output. and in Accessing the Network Server by using the network client driver is written: traceLevel The level of client tracing if traceFile or traceDirectory are set. So I think that in Accessing the Network Server by using the DB2 Universal Driver logging should be replaced by tracing in traceLevel: traceLevel Specifies the granularity of tracing messages to the logWriter property. -- 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-283) On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server .
[ http://issues.apache.org/jira/browse/DERBY-283?page=comments#action_12373035 ] Jeff Levitt commented on DERBY-283: --- If there are no objections with this patch, can it be committed? I have called for a review several times with no response, so I am assuming no one has any negative votes. On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server . -- Key: DERBY-283 URL: http://issues.apache.org/jira/browse/DERBY-283 Project: Derby Type: Bug Components: Network Server Versions: 10.0.2.1 Reporter: Manjula Kutty Priority: Minor Attachments: derby283.diff, tadminconfigipx.html On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server . -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true This is a Windows OS problem and have to track to to see when MS is going to fix and then make the appropriate changes in our docs -- 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-724) Derby supports JDBC date escape format but this is not documented
[
http://issues.apache.org/jira/browse/DERBY-724?page=comments#action_12373036 ]
Jeff Levitt commented on DERBY-724:
---
If there are no objections with this patch, can it be committed? I have called
for a review several times with no response, so I am assuming no one has any
negative votes.
Derby supports JDBC date escape format but this is not documented
-
Key: DERBY-724
URL: http://issues.apache.org/jira/browse/DERBY-724
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.2.1
Reporter: Daniel John Debrunner
Priority: Minor
Attachments: derby724.diff, rrefjdbcescapedate.html
The JDBC escape format section in the reference manual, page 198 in the pdf
for 10.1, documents the time and timestamp support, but not the date format.
{d '-mm-dd'}
e.g.
{d '1995-12-19'}
See section 13.4.2 of JDBC 3.0 specifiction.
--
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: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
--- David W. Van Couvering [EMAIL PROTECTED] wrote: I agree that you can't really advertise a new feature as really available unless it's documented, and that in this scratch-your-itch world, this would seem to be something that the person writing the feature would be motivated to do. I think having a requirement that some specification is required before an interface is considered public is worth considering. Of course, the other people who may be itching to document a feature are those who want to use it, so I could imagine it being a collaborative effort. I can add a note to the effect that no interface can be considered a public interface (e.g. Stable, Unstable or Standard) unless it is documented in the user documentation. Would this get the point across? David Thats a huge step in the right direction. It states in writing the link between documentation and stability. Perhaps the next step would be linking the documentation in the developer's mind to their code, so that both are one and the same.
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
Hi David, Yes I thinnk thats what I'm trying to say. Of course something can be implemented and not documented, or the other way around, but my sense is that we are trying to make acontract here for ourselves, and with our users, and I think that if part of that contract is to tell our users that what they see in the doc is fact, then we should strive to always make that true. That means a new contribution would not be accepted unless it included corresponding documentation. If we add a new function then either a patch to the DITA source referencing that function is included, or at the very least a full function spec is submitted so that documentation can be written by someone else. The bottom line would be that documentation would be considered as important as codeline itself; quality considerations would include documentation, just as proper code consistency and standards are required. Most contributors are not documentation specialists, so maybe it is too much to ask, but I think if we are telling users to accept the doc as the final word, then we need to have some sort of MINIMUM doc contribution requirement. What do other people think? --- David W. Van Couvering [EMAIL PROTECTED] wrote: Hi, Jeff. I've been quiet on this comment because I didn't fully understand it. I *think* what you're saying is that an interface can not be considered Stable or Unstable unless it's actually documented. Is that right? David Jeff Levitt wrote: From a documentation perspective, I think if we are going to say on this page that items are stable AS DOCUMENTED in the user documentation, then we also need to put in some sort of requirement on this page that says any changes made to the stability of an item MUST be documented as well in order to be committed an considered stable. Its not stable if its not documented and we are telling people that it is stable as documented. Agreed? I think this is something that would be good to put in to make sure that developers understand the importance of documenting their work, whether its something new or a change to something that exists, and that its not just going to magically show up in the documentation if they put it in the code (unless its javadoc) :) --- David W. Van Couvering [EMAIL PROTECTED] wrote: Thanks for your comments, Kathey, and yes, it can definitely wait a week. It was just so quiet that I thought I'd do a ping and see if there was more to come from everyone. Responses below... Kathey Marsden wrote: I wish I had more time to look at this but I think that I would add these things. - In general any documented behaviour is a stable interface, unless specifically documented here or in the documentation as unstable. I'm not sure how to handle this. What does it mean to incompatibly change documented behavior? Usually the behavior is in relation to a given interface. So perhaps in our definition of what it means to incompatibly change an interface means you can't change the documented behavior of that interface (e.g. the contract of that interface). I think it's also fair to say that unless explicitly called out in the table as otherwise, one can assume a publicly documented interface is Stable. - Derby will at a minimum negotiate down to the lower interface revision level: - When different versions of Derby client and server are used together (in the same or different JVM's) - When different jvm versions are used on client and server. I think this is a solution that provides a guarantee of stability to the client/server interfaces. I can add this as a note, however. I think by calling out the *specific* interfaces that the client depends upon (DRDA, metadata procedures, system stored procedures, ???) and marking them as Stable or Private Stable is a Really Good Idea in our attempts to provide the guarantee of client/server compatiblity. Note, for example, some of us newbies changing the metadata procedures willy nilly because we were unaware of the impact on compatibility. Having these called out will make us all more conscious of what we can and can't do within the system. In the interface table I would add: - Defaults returned by DatabaseMetaData methods Stable - Documented defaults Stable - console output format for tools and network server Unstable - System stored procedures Stable OK, I'll add these. I think the console output format for tools and server should actually be marked Private -- it's not documented in the user documentation, and can change at any time. Dumb question: are system stored procedures in the user documentation? If not, perhaps they should be Private Stable rather than
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
P.S. David, I read my original reply and even I didn't understand it! I think my latest response is slightly more clear Sorry all, Jeff --- David W. Van Couvering [EMAIL PROTECTED] wrote: Hi, Jeff. I've been quiet on this comment because I didn't fully understand it. I *think* what you're saying is that an interface can not be considered Stable or Unstable unless it's actually documented. Is that right? David Jeff Levitt wrote: From a documentation perspective, I think if we are going to say on this page that items are stable AS DOCUMENTED in the user documentation, then we also need to put in some sort of requirement on this page that says any changes made to the stability of an item MUST be documented as well in order to be committed an considered stable. Its not stable if its not documented and we are telling people that it is stable as documented. Agreed? I think this is something that would be good to put in to make sure that developers understand the importance of documenting their work, whether its something new or a change to something that exists, and that its not just going to magically show up in the documentation if they put it in the code (unless its javadoc) :) --- David W. Van Couvering [EMAIL PROTECTED] wrote: Thanks for your comments, Kathey, and yes, it can definitely wait a week. It was just so quiet that I thought I'd do a ping and see if there was more to come from everyone. Responses below... Kathey Marsden wrote: I wish I had more time to look at this but I think that I would add these things. - In general any documented behaviour is a stable interface, unless specifically documented here or in the documentation as unstable. I'm not sure how to handle this. What does it mean to incompatibly change documented behavior? Usually the behavior is in relation to a given interface. So perhaps in our definition of what it means to incompatibly change an interface means you can't change the documented behavior of that interface (e.g. the contract of that interface). I think it's also fair to say that unless explicitly called out in the table as otherwise, one can assume a publicly documented interface is Stable. - Derby will at a minimum negotiate down to the lower interface revision level: - When different versions of Derby client and server are used together (in the same or different JVM's) - When different jvm versions are used on client and server. I think this is a solution that provides a guarantee of stability to the client/server interfaces. I can add this as a note, however. I think by calling out the *specific* interfaces that the client depends upon (DRDA, metadata procedures, system stored procedures, ???) and marking them as Stable or Private Stable is a Really Good Idea in our attempts to provide the guarantee of client/server compatiblity. Note, for example, some of us newbies changing the metadata procedures willy nilly because we were unaware of the impact on compatibility. Having these called out will make us all more conscious of what we can and can't do within the system. In the interface table I would add: - Defaults returned by DatabaseMetaData methods Stable - Documented defaults Stable - console output format for tools and network server Unstable - System stored procedures Stable OK, I'll add these. I think the console output format for tools and server should actually be marked Private -- it's not documented in the user documentation, and can change at any time. Dumb question: are system stored procedures in the user documentation? If not, perhaps they should be Private Stable rather than Stable? If they're not documented, what is driving the requirement that they be stable - client/server compatibility? Under notes It would be good to mention: . OK Could we wait a week for a vote?I think I need to study this some more. Thanks David for doing this. Yes, sure, and you're welcome. David Kathey
[doc: System stored procedures] WAS: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
--- David W. Van Couvering [EMAIL PROTECTED] wrote: snip Dumb question: are system stored procedures in the user documentation? If not, perhaps they should be Private Stable rather than Stable? If they're not documented, what is driving the requirement that they be stable - client/server compatibility? /snip Is this what you were looking for David? This is in the Reference Manual: http://db.apache.org/derby/docs/dev/ref/crefsqlbuiltinsystemprocedures.html
Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)
From a documentation perspective, I think if we are going to say on this page that items are stable AS DOCUMENTED in the user documentation, then we also need to put in some sort of requirement on this page that says any changes made to the stability of an item MUST be documented as well in order to be committed an considered stable. Its not stable if its not documented and we are telling people that it is stable as documented. Agreed? I think this is something that would be good to put in to make sure that developers understand the importance of documenting their work, whether its something new or a change to something that exists, and that its not just going to magically show up in the documentation if they put it in the code (unless its javadoc) :) --- David W. Van Couvering [EMAIL PROTECTED] wrote: Thanks for your comments, Kathey, and yes, it can definitely wait a week. It was just so quiet that I thought I'd do a ping and see if there was more to come from everyone. Responses below... Kathey Marsden wrote: I wish I had more time to look at this but I think that I would add these things. - In general any documented behaviour is a stable interface, unless specifically documented here or in the documentation as unstable. I'm not sure how to handle this. What does it mean to incompatibly change documented behavior? Usually the behavior is in relation to a given interface. So perhaps in our definition of what it means to incompatibly change an interface means you can't change the documented behavior of that interface (e.g. the contract of that interface). I think it's also fair to say that unless explicitly called out in the table as otherwise, one can assume a publicly documented interface is Stable. - Derby will at a minimum negotiate down to the lower interface revision level: - When different versions of Derby client and server are used together (in the same or different JVM's) - When different jvm versions are used on client and server. I think this is a solution that provides a guarantee of stability to the client/server interfaces. I can add this as a note, however. I think by calling out the *specific* interfaces that the client depends upon (DRDA, metadata procedures, system stored procedures, ???) and marking them as Stable or Private Stable is a Really Good Idea in our attempts to provide the guarantee of client/server compatiblity. Note, for example, some of us newbies changing the metadata procedures willy nilly because we were unaware of the impact on compatibility. Having these called out will make us all more conscious of what we can and can't do within the system. In the interface table I would add: - Defaults returned by DatabaseMetaData methods Stable - Documented defaults Stable - console output format for tools and network server Unstable - System stored procedures Stable OK, I'll add these. I think the console output format for tools and server should actually be marked Private -- it's not documented in the user documentation, and can change at any time. Dumb question: are system stored procedures in the user documentation? If not, perhaps they should be Private Stable rather than Stable? If they're not documented, what is driving the requirement that they be stable - client/server compatibility? Under notes It would be good to mention: . OK Could we wait a week for a vote?I think I need to study this some more. Thanks David for doing this. Yes, sure, and you're welcome. David Kathey
Re: tests for doc examples?
--- Rajesh Kartha [EMAIL PROTECTED] wrote: Myrna van Lunteren wrote: Hi, I've been wondering and worrying about our doc examples. Before contribution to apache, we did a couple of passes to test and verify all doc examples. But this is a very time-consuming and error-prone process for various reasons: easy for an individual to miss a snippet, snippets are not written with tests in mind and don't easily follow on each other and so every snippet needs to have a separate test written...or get tested manually... Also examples continue to get changed and for new code we should get new examples, and we now have a demo database (toursdb) that we probably should try to use...And I don't see that anyone has time available to test all the snippets. I think we should have automated tests for the doc examples. Or at least as many as possible. I am thinking, it should be possible to extract the example code from the dita files and automatically build tests based on it. We could mark the snippets that are easy to be wrapped into an SQL examples one way, java snippets another, full java classes yet another, extract them, and refresh the tests that way...(nightly? monthly? at code freeze dates?) Maybe add a specific string to each example so we can search the dita files for that. Or maybe there already is a specific sort of property/tag for code snippets? This also has implications for the examples - they should be (re)written with wrapping into a test in mind. Does this seem doable/feasible/sensible? Myrna +1. Would be really useful. With the toursdb demo availabe in the codeline, I think all the queries should work as is. A great deal of attention needs to be paid to the results returned by the sample queries. I noticed, for ex. DERBY-994, LEFT/RIGHT OUTER JOIN examples, the queries worked just fine - but the results and description did not make sense at all. -Rajesh I think it would be useful. I'm pretty sure if you searched the DITA for the content inside codeblock tags, you'de have the examples. But you'd need some way of differentiating snippets, full code, etc. Wht would need to be done is: A. Define the kinds of examples (snippet, full code, etc.) B. Do a one-time search of the codeblocks, and determine what type each example is. C. Put something in the codeblock tag, whether it is an attribute on the codeblock tag itself (for example: codeblock type=snippet) or by leading the example with a comment (for example: -- Example: SNIPPET title=CREATE TABLE statement example I'll look into the attribute method. Great idea!
[jira] Updated: (DERBY-1123) Derby Reference Manual - SYSCS_UTIL.SYSCS_CHECK_TABLE
[ http://issues.apache.org/jira/browse/DERBY-1123?page=all ] Jeff Levitt updated DERBY-1123: --- Attachment: SYSCS_CHECK_TABLE_JEFF_modified.diff Here's my own patch based on Halley's patch. I just thought we should add the singular table to the sentences. So now it checks the table and indexes, instead of just the indexes. Derby Reference Manual - SYSCS_UTIL.SYSCS_CHECK_TABLE - Key: DERBY-1123 URL: http://issues.apache.org/jira/browse/DERBY-1123 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.3 Environment: DITA files Reporter: Halley Pacheco de Oliveira Fix For: 10.2.0.0 Attachments: SYSCS_CHECK_TABLE.diff, SYSCS_CHECK_TABLE_JEFF_modified.diff In SYSCS_UTIL.SYSCS_CHECK_TABLE is written: The SYSCS_UTIL.SYSCS_CHECK_TABLE function checks the specified table, ensuring that all of its indexes are consistent with the base table. When tables are consistent, the method returns a SMALLINT with value 1. If the tables are inconsistent, the function will throw an exception. I think that in the last two sentences of this paragraph the word tables should be changed to indexes, because it is the indexes that are being tested for consistency with the base table, and to maintain the word tables it should be in the singular (table) and not in the plural (tables), because the function tests just one table at each call. So the patched paragraph becomes: The SYSCS_UTIL.SYSCS_CHECK_TABLE function checks the specified table, ensuring that all of its indexes are consistent with the base table. When indexes are consistent, the method returns a SMALLINT with value 1. If the indexes are inconsistent, the function will throw an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [doc] Java(TM) not getting rendered properly for html
--- Andrew McIntyre [EMAIL PROTECTED] wrote: On 3/21/06, Jean T. Anderson [EMAIL PROTECTED] wrote: What browser are you using that it works on? I had been using Safari, but now I'm wondering if I had changed the default encoding, because using a different version of Safari on a different machine, I also see the problem. It is fixed by switching the default encoding of Safari to UTF-8 on that machine. Grepping through the DITA toolkit, there is a pathological use of lowercase 'utf-8'. We should report the problem to the DITA folks. andrew Here is the bug I reported to the DITA toolkit, along with some responses: https://sourceforge.net/tracker/?func=detailatid=725074aid=1456430group_id=132728 It sounds like the problem is on our end. Does anyone have an idea what the problem might be if itsnot with the Toolkit?
[doc] http://dita.xml.org/
The DITA community release a new website today at: http://dita.xml.org/ This is THE go-to place for knowledge, instruction, information, and discussion about DITA. Anyone who wants to learn more about DITA, how to write DITA, etc. should go to this website. Jean, should we put a link to this in the DITA source page on the site? I think this takes care of the teaching users how to use DITA section we wanted there.
[jira] Created: (DERBY-1150) [web] Add new section to DITA source page describing how to edit DITA files
[web] Add new section to DITA source page describing how to edit DITA files --- Key: DERBY-1150 URL: http://issues.apache.org/jira/browse/DERBY-1150 Project: Derby Type: Improvement Components: Web Site Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 We need a new section on the Derby DITA Source page: http://db.apache.org/derby/manuals/dita.html The new section needs to describe how to edit DITA files, use XML editors, provide some example XML editors, and provide the new website for learning and using DITA resources at http://dita.xml.org. -- 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-1150) [web] Add new section to DITA source page describing how to edit DITA files
[ http://issues.apache.org/jira/browse/DERBY-1150?page=all ] Jeff Levitt updated DERBY-1150: --- Attachment: derby1150.diff The attached patch creates the new section as described. [web] Add new section to DITA source page describing how to edit DITA files --- Key: DERBY-1150 URL: http://issues.apache.org/jira/browse/DERBY-1150 Project: Derby Type: Improvement Components: Web Site Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 Attachments: derby1150.diff We need a new section on the Derby DITA Source page: http://db.apache.org/derby/manuals/dita.html The new section needs to describe how to edit DITA files, use XML editors, provide some example XML editors, and provide the new website for learning and using DITA resources at http://dita.xml.org. -- 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-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=comments#action_12371456 ] Jeff Levitt commented on DERBY-1057: Has anyone had a chance to look at the grant/revoke doc patches? It would be cool if grant/revoke could get committed soon, but if there is feedback to be made, we should get it now...Thanks! documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Assignee: Eric Radzinski Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide_html.zip, derby1057_ref.diff, derby1057_ref_html.zip -- 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: [doc] Java(TM) not getting rendered properly for html
--- Dag H. Wanvik [EMAIL PROTECTED] wrote: Andrew McIntyre [EMAIL PROTECTED] writes: On 3/21/06, Andrew McIntyre [EMAIL PROTECTED] wrote: I'm guessing this is a problem with Firefox as well, but I don't have that handy right now to check. The problem could be fixed in Mozilla I can conform it is a problem with firefox as well (1.5.0.1). Dag as well, if they just ignored case when examining the charset attribute. I found a couple of bugs in Bugzilla that looked like they might be this one, but nothing that was an exact match. andrew I have submitted the following bug to the DITA toolkit project: http://sourceforge.net/tracker/index.php?func=detailaid=1456430group_id=132728atid=725074
[jira] Updated: (DERBY-1057) documentation to address Grant/Revoke (Derby-464)
[ http://issues.apache.org/jira/browse/DERBY-1057?page=all ] Jeff Levitt updated DERBY-1057: --- Attachment: derby1057_devguide.diff derby1057_devguide_html.zip The patch I am attaching (derby1057_devguide.diff) complements Eric Radzinski's patch for the reference manual. My patch makes changes to the User Authorization section of the Developer's Guide. I have included an html zip file including sample output for the Developer's Guide relevant html files. I would appreciate any feedbackso that we can get these two patches committed soon. Remember that the two patches complement each other, and that together, they patch the ref guide and dev guide to include the total information needed for grant/revoke. Also, in the devguide, note that i did not remove information about the legacy authorization functionality, as that still works. I simply integrated the grant/revoke information into it in the section on User Authorization. Thanks again in advance for your quick feedback! documentation to address Grant/Revoke (Derby-464) - Key: DERBY-1057 URL: http://issues.apache.org/jira/browse/DERBY-1057 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Assignee: Eric Radzinski Fix For: 10.2.0.0 Attachments: derby1057_devguide.diff, derby1057_devguide_html.zip, derby1057_ref.diff, derby1057_ref_html.zip -- 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-539) Update the Create Index statement in the Derby documentation with additional information
[ http://issues.apache.org/jira/browse/DERBY-539?page=comments#action_12370408 ] Jeff Levitt commented on DERBY-539: --- Can someone take a look at the most recent patch so it can commit if it looks good? Thanks! Update the Create Index statement in the Derby documentation with additional information Key: DERBY-539 URL: http://issues.apache.org/jira/browse/DERBY-539 Project: Derby Type: Improvement Components: Documentation Reporter: Susan Cline Priority: Minor Attachments: derby539-take2.diff, derby539.diff, rrefsqlj20937.html In the 'Create Index' statement documentation of the 10.1 Reference Guide (derby/docs/10.1/ref/rrefsqlj20937.html) this statement is made about creating indexes and constraints: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a UNIQUE or PRIMARY KEY constraint on it, you can not create an index on those columns. Derby has already created it for you with a system-generated name. This is true, but I think it can be expanded upon to be clearer. A suggestion for this is below: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a PRIMARY KEY constraint on it, you can not create an index on those columns. If a column or set of columns has a UNIQUE constraint on it, you can not create an index on those columns, but you can create a PRIMARY KEY constraint on it. Addtionally, if this is the case, a backing index will be created for the PRIMARY KEY constraint so two indexes will now exist on the column or set of columns that had the UNIQUE constraint on it. This issue came up when I noticed that I could create a unique index on a column, then create a PK on that column. When I used a tool to generate DDL for the table I noticed one constraint and two indexes on the column which didn't make sense at first when reading the existing documentation. With the additional information above I think it explains the real behaviour better. -- 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-769) CLOB and BLOB descriptions do not specify the default length
[ http://issues.apache.org/jira/browse/DERBY-769?page=comments#action_12370409 ] Jeff Levitt commented on DERBY-769: --- Can this be committed by a committer please? Thanks! CLOB and BLOB descriptions do not specify the default length Key: DERBY-769 URL: http://issues.apache.org/jira/browse/DERBY-769 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Priority: Trivial Attachments: derby769-2.diff, derby769.diff, rrefblob.html, rrefclob.html BLOB without a length has a default length of 1 mega byte, ie. same as BLOB(1M) CLOB without a length has a default length of 1 mega characters, ie. same as CLOB(1M) http://db.apache.org/derby/docs/10.1/ref/rrefblob.html http://db.apache.org/derby/docs/10.1/ref/rrefclob.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1077) [doc] Add relationship table for Developer's Guide
[ http://issues.apache.org/jira/browse/DERBY-1077?page=comments#action_12370410 ] Jeff Levitt commented on DERBY-1077: Has someone had a chance to look at this patch? If so, can you comment on it ASAP? The sooner it can get committed, the better. Thanks, Jeff [doc] Add relationship table for Developer's Guide -- Key: DERBY-1077 URL: http://issues.apache.org/jira/browse/DERBY-1077 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 Attachments: devguidereltable.diff I am creating this issue to submit a patch for the Developer's Guide doc source. This patch fixes the same problems in the Dev Guide that Derby-489 fixed in the Getting Started Guide having to do with related links: http://issues.apache.org/jira/browse/DERBY-489 The relevant discussion as to why these patches are necessary is discussed there as well. -- 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-724) Derby supports JDBC date escape format but this is not documented
[
http://issues.apache.org/jira/browse/DERBY-724?page=comments#action_12370411 ]
Jeff Levitt commented on DERBY-724:
---
Can someone comment on this patch so that it can be committed if all looks OK?
Thanks!
Derby supports JDBC date escape format but this is not documented
-
Key: DERBY-724
URL: http://issues.apache.org/jira/browse/DERBY-724
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.2.1
Reporter: Daniel John Debrunner
Priority: Minor
Attachments: derby724.diff, rrefjdbcescapedate.html
The JDBC escape format section in the reference manual, page 198 in the pdf
for 10.1, documents the time and timestamp support, but not the date format.
{d '-mm-dd'}
e.g.
{d '1995-12-19'}
See section 13.4.2 of JDBC 3.0 specifiction.
--
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-283) On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server .
[ http://issues.apache.org/jira/browse/DERBY-283?page=comments#action_12370412 ] Jeff Levitt commented on DERBY-283: --- Can someone take a look at this patch and comment on it so that it can be committed if all looks OK? Thanks! On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server . -- Key: DERBY-283 URL: http://issues.apache.org/jira/browse/DERBY-283 Project: Derby Type: Bug Components: Network Server Versions: 10.0.2.1 Reporter: Manjula Kutty Priority: Minor Attachments: derby283.diff, tadminconfigipx.html On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server . -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true This is a Windows OS problem and have to track to to see when MS is going to fix and then make the appropriate changes in our docs -- 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: [doc] booktitle and copyright intermediate fix
--- scott hutinger [EMAIL PROTECTED] wrote: BTW, I think the thought was to have even-page and odd-page headers. What exactly should be on the header? Is the the chapter title and copyright, or some other layout? I guess Jeff knows what the layout should be... :-) thanks, scott Well, based on what I've seen in other books, you want the book title on the even pages and the chapter name on the odd. But on chapter title pages, you want the copyright. Make sesne?
Re: [doc] booktitle and copyright intermediate fix
Looks good Scott, great idea. Is there a place we can view your output with this patch? Maybe if you have a server set up, or you can email the pdf or single html file...? Thanks! --- scott hutinger [EMAIL PROTECTED] wrote: I noticed that booktitle is somehow or another set as Copyright I haven't been able to find out where this is set yet. I did add some xslt to dita2fo-shell.xsl so it shows Copyright©1997, 2005: Apache Software Foundation Which isn't completely correct, but it took a while to find where Copyright was (or what). Also, the following doesn't follow the way (c) was supposed to be implemented. But this could be an intermediate fix. Or modified the way it should be displayed till it was fixed the way it was intended to work. scott Index: lib/dita2fo-shell.xsl === --- lib/dita2fo-shell.xsl (revision 384602) +++ lib/dita2fo-shell.xsl (working copy) @@ -87,6 +87,12 @@ !--xsl:call-template name=back-covers/-- /fo:root /xsl:template + !-- create Derby Copyright for static area -- +xsl:template name=derby-copyright + xsl:textcopyr;/xsl:text + xsl:value-of select=//*[contains(@class,' topic/copyright ')]/copyryear/@year/:nbsp; + xsl:value-of select=//*[contains(@class,' topic/copyright ')]/*[contains(@class,' topic/copyrholder ')]/xsl:text /xsl:text +/xsl:template !-- create FOP outline elements for PDF bookmarks -- xsl:template match=* mode=outline xsl:if test=contains(@class,' topic/topic ') @@ -160,6 +166,7 @@ !--Jeff is adding this section to replace what was originally there below -- fo:flow flow-name=xsl-region-body + xsl:call-template name=derby-copyright/ !-- Custom cover art/text goes here -- xsl:call-template name=place-cover-art/ !-- End of custom art section -- @@ -279,6 +286,7 @@ /xsl:variable fo:block font-size=8pt line-height=8pt xsl:value-of select=$booktitle/ + xsl:call-template name=derby-copyright/xsl:call-template /fo:block /fo:static-content !-- footer -- @@ -338,6 +346,7 @@ /xsl:variable fo:block font-size=8pt line-height=8pt xsl:value-of select=$booktitle/ + xsl:call-template name=derby-copyright/xsl:call-template /fo:block /fo:static-content !-- footer static stuff --
[jira] Commented: (DERBY-916) documentation to address Derby-239: online backup
[ http://issues.apache.org/jira/browse/DERBY-916?page=comments#action_12369529 ] Jeff Levitt commented on DERBY-916: --- Can a committer please commit this? It looks like there are no objections to the latest patch. Thanks Suresh! documentation to address Derby-239: online backup - Key: DERBY-916 URL: http://issues.apache.org/jira/browse/DERBY-916 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Assignee: Eric Radzinski Attachments: derby916-1.diff, derby916-2.diff, derby916-2html.zip, derby916_html_files.zip -- 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-283) On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server .
[ http://issues.apache.org/jira/browse/DERBY-283?page=all ] Jeff Levitt updated DERBY-283: -- Attachment: derby283.diff tadminconfigipx.html Attached patch adds the information to the Admin Guide in the section about Starting the Network Server. HTML output included for review. Please let me know if it looks good so a committer can commit. Thanks! On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server . -- Key: DERBY-283 URL: http://issues.apache.org/jira/browse/DERBY-283 Project: Derby Type: Bug Components: Network Server Versions: 10.0.2.1 Reporter: Manjula Kutty Priority: Minor Attachments: derby283.diff, tadminconfigipx.html On IPv6/Ipv4 dual stack windows machines, the network server needs the following jvm properties to be prefixed while starting the server . -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true This is a Windows OS problem and have to track to to see when MS is going to fix and then make the appropriate changes in our docs -- 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-60) Documentation refers to SYSIBM system schema
[ http://issues.apache.org/jira/browse/DERBY-60?page=comments#action_12369125 ] Jeff Levitt commented on DERBY-60: -- So I am going to create a page in the Ref manual that lists system schemas, and I am going to include the following: APP NULLID SQLJ SYS SYSCAT SYSCS_DIAG SYSCS_UTIL SYSFUN SYSIBM SYSPROC SYSSTAT Is there any information I should include about them or about these in general? Thanks! Documentation refers to SYSIBM system schema Key: DERBY-60 URL: http://issues.apache.org/jira/browse/DERBY-60 Project: Derby Type: Bug Components: Documentation Reporter: John Sisson Priority: Trivial http://incubator.apache.org/derby/manuals/tools/tools109.html refers to the SYSIBM system schema as an example, but SYSIBM is not mentioned anywhere else in the Derby documentation (when I searched for it). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-724) Derby supports JDBC date escape format but this is not documented
[ http://issues.apache.org/jira/browse/DERBY-724?page=all ]
Jeff Levitt updated DERBY-724:
--
Attachment: derby724.diff
rrefjdbcescapedate.html
Attached patch adds a new topic in the JDBC escaped formats area of the ref
manual. The new topic describes the date escaped syntax. The attached output
file is included for review. Please let me know if there is anything else
needed to do or if this is ready for a commit. Thanks!
Derby supports JDBC date escape format but this is not documented
-
Key: DERBY-724
URL: http://issues.apache.org/jira/browse/DERBY-724
Project: Derby
Type: Bug
Components: Documentation
Versions: 10.1.2.1
Reporter: Daniel John Debrunner
Priority: Minor
Attachments: derby724.diff, rrefjdbcescapedate.html
The JDBC escape format section in the reference manual, page 198 in the pdf
for 10.1, documents the time and timestamp support, but not the date format.
{d '-mm-dd'}
e.g.
{d '1995-12-19'}
See section 13.4.2 of JDBC 3.0 specifiction.
--
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-571) Virtual Table Mapping for no argument Diagnostic tables
[
http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12368962 ]
Jeff Levitt commented on DERBY-571:
---
I looked, and our current doc does not have any information for any of the now
replaced org.apache.derby.diag.whatever tables. Do we want a new section to
document the SYSCS_DIAG.whatever tanles, and if so, where and in which
manual? Or is the javadoc satisfactory?
Virtual Table Mapping for no argument Diagnostic tables
---
Key: DERBY-571
URL: http://issues.apache.org/jira/browse/DERBY-571
Project: Derby
Type: Improvement
Components: SQL
Reporter: Daniel John Debrunner
Assignee: Daniel John Debrunner
Priority: Minor
Fix For: 10.2.0.0
Currently four no-argument diagnostic tables exist that provide information
about the running state of Derby, or its error messages.
These tables are invoked using an awkward, non-standard syntax. As an example:
SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
The improvement will provide an internal mapping from a regular table name in
the SYSCS_DIAG schema
to the runtime virtual table code. Thus the above example would be replaced
by:
SELECT * FROM SYSCS_DIAG.LOCK_TABLE
These diagnostic table expressions are regular table expressions (as is the
NEW VTI construct) and
can be used wherever a normal table can.
Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a
diagnostic table
will result in an exception.
The old style syntax will remain in place for 10.2, but become deprecated.
The tables to be implemented in this change are:
SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable
SYSCS_DIAG.STATEMENT_CACHEreplaces org.apache.derby.diag.StatementCache
SYSCS_DIAG.TRANSACTION_TABLEreplaces
org.apache.derby.diag.TransactionTable
SYSCS_DIAG.ERROR_MESSAGESreplaces org.apache.derby.diag.ErrorMessages
Adding such a table will be table driven, thus easy for others to provide
additional diagnostics.
Information about these diagnostic tables will not appear in the system
catalogs or JDBC DatabaseMetaData.
The ResultSetMetaData for the any query involving a diagnostic table will be
valid.
This is a first step in a progression towards supporing a fully
application/user defined virtual table.
These steps are not part of this jira issue, but added for information
purposes.
- second step - supporting diagnostic tables with parameters, e.g.
SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
- third step - providing a create virtual table statement (most databases
support
some form of virtual table, or wrappers). The DDL would be non-standard
but the
data access would be standard. [need to check table functions in part 13
of SQL standard]
E.g. syntax yet to be defined, but to give the general idea
CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END
TIMESTAMP)
LANGUAGE JAVA
PARAMETER STYLE JAVA
EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';
--
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-931) Until Derby-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly
[ http://issues.apache.org/jira/browse/DERBY-931?page=comments#action_12368909 ] Jeff Levitt commented on DERBY-931: --- OK thanks. So do I just want to add a bullet that says that setReadOnly ignores options in a client-server mode, but works fine in embedded mode? Until Derby-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly Key: DERBY-931 URL: http://issues.apache.org/jira/browse/DERBY-931 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.1 Reporter: Mamta A. Satoor Derby 911 Connection.setReadOnly is a no-op in Network Client. It works fine with embedded client. has more details on this issue but basically, we should document the difference in behavior for setReadOnly between Network Driver and Embedded Driver. -- 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-1077) [doc] Add relationship table for Developer's Guide
[doc] Add relationship table for Developer's Guide -- Key: DERBY-1077 URL: http://issues.apache.org/jira/browse/DERBY-1077 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Assigned to: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 I am creating this issue to submit a patch for the Developer's Guide doc source. This patch fixes the same problems in the Dev Guide that Derby-489 fixed in the Getting Started Guide having to do with related links: http://issues.apache.org/jira/browse/DERBY-489 The relevant discussion as to why these patches are necessary is discussed there as well. -- 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-1077) [doc] Add relationship table for Developer's Guide
[ http://issues.apache.org/jira/browse/DERBY-1077?page=all ] Jeff Levitt updated DERBY-1077: --- Attachment: devguidereltable.diff Attached patch fixes the links in the Dev Guide as discussed. A relationship table has been added to keep linking within the guide easy. I created sample output on my own server for review here: http://derby.mylevita.com/devguide/ [doc] Add relationship table for Developer's Guide -- Key: DERBY-1077 URL: http://issues.apache.org/jira/browse/DERBY-1077 Project: Derby Type: Improvement Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 Attachments: devguidereltable.diff I am creating this issue to submit a patch for the Developer's Guide doc source. This patch fixes the same problems in the Dev Guide that Derby-489 fixed in the Getting Started Guide having to do with related links: http://issues.apache.org/jira/browse/DERBY-489 The relevant discussion as to why these patches are necessary is discussed there as well. -- 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: [doc] future docs
--- scott hutinger [EMAIL PROTECTED] wrote: Since bookmarks and TOC (in url form) sort of clash, any good ideas about where to put links (not bookmarks). I am thinking it might be wise to jump up to the DITA-2.1 beta (except for the build). Although my initial investigation into this showed a difference in the globals that we use, which broke the build. Hopefully it will fix some of the broken items, as xslt gets a bit messy (to me). Also the FOP changes coming down the pipeline seem to have a direct impact on what direction (I take) with fixes (ie TOC (table of contents)). Currently my build at work is having problems (linux) from a fresh co yesterday. Any ideas on the best method to do the switch? I still have some changes that haven't been incorporated into the build, and are hanging around somewhere. Possibly a working svn branch? XSLT debugging is sometimes a pain to setup; depending on the build target... thanks, scott Hi Scott, I've played around with the DITA 1.2 (not 2.1, its the other way around) :) a little bit these past few weeks. There are some problems with the java files in it that they have submitted patches for, but you need to get the dita source files, apply the patch, and recompile in order to get it working. Otherwise, the toolkit doesnt build our Derby project. I agree that we should move to 1.2 though, as soon as they release a binary distribution that includes the patches. 1.2 handles links a lot better, as you stated, and it moves us closer and closer to not having to mod the xsl file each time.
Re: [doc] future docs
--- scott hutinger [EMAIL PROTECTED] wrote: Jeff Levitt wrote: --- scott hutinger [EMAIL PROTECTED] wrote: Since bookmarks and TOC (in url form) sort of clash, any good ideas about where to put links (not bookmarks). I am thinking it might be wise to jump up to the DITA-2.1 beta (except for the build). Although my initial investigation into this showed a difference in the globals that we use, which broke the build. Hopefully it will fix some of the broken items, as xslt gets a bit messy (to me). Also the FOP changes coming down the pipeline seem to have a direct impact on what direction (I take) with fixes (ie TOC (table of contents)). Currently my build at work is having problems (linux) from a fresh co yesterday. Any ideas on the best method to do the switch? I still have some changes that haven't been incorporated into the build, and are hanging around somewhere. Possibly a working svn branch? XSLT debugging is sometimes a pain to setup; depending on the build target... thanks, scott Hi Scott, I've played around with the DITA 1.2 (not 2.1, its the other way around) :) a little bit these past few weeks. There are some problems with the java files in it that they have submitted patches for, but you need to get the dita source files, apply the patch, and recompile in order to get it working. Otherwise, the toolkit doesnt build our Derby project. I agree that we should move to 1.2 though, as soon as they release a binary distribution that includes the patches. 1.2 handles links a lot better, as you stated, and it moves us closer and closer to not having to mod the xsl file each time. Hi Jeff, Are those (or that) patch on the DITA-OT public patches? If not, could you send me the patch? Yes, 1.2 (not 2.1). Sometimes I jump too far :-) I don't have a problem with re-building something, as that's the norm isn't it? (just kidding). I'll look at the patches at DITA-OT... thanks, scott Hey Scott, Here is the link to the info about the bug and the download for the patch they supplied to it. This is exactly the bug I get when I try to build derby docs using the 1.2 binaries. http://sourceforge.net/tracker/index.php?func=detailaid=1431229group_id=132728atid=725074
[jira] Updated: (DERBY-916) documentation to address Derby-239: online backup
[ http://issues.apache.org/jira/browse/DERBY-916?page=all ] Jeff Levitt updated DERBY-916: -- Attachment: derby916-2.diff derby916-2html.zip I went ahead and made these final minor changes to the patch because it was so close to commit. The derby916-2.diff is the new patch file, and contains the latest comments from Suresh. The derby916-2html.zip file contains new html ouput files for review. Thanks! documentation to address Derby-239: online backup - Key: DERBY-916 URL: http://issues.apache.org/jira/browse/DERBY-916 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Assignee: Eric Radzinski Attachments: derby916-1.diff, derby916-2.diff, derby916-2html.zip, derby916_html_files.zip -- 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-769) CLOB and BLOB descriptions do not specify the default length
[ http://issues.apache.org/jira/browse/DERBY-769?page=all ] Jeff Levitt updated DERBY-769: -- Attachment: derby769.diff rrefblob.html rrefclob.html Attached patch (derby769.diff) adds a default section in both topics, each saying that the default length for these types is one megabyte if no length is specified, See html output files included for review. Thanks! CLOB and BLOB descriptions do not specify the default length Key: DERBY-769 URL: http://issues.apache.org/jira/browse/DERBY-769 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Priority: Trivial Attachments: derby769.diff, rrefblob.html, rrefclob.html BLOB without a length has a default length of 1 mega byte, ie. same as BLOB(1M) CLOB without a length has a default length of 1 mega characters, ie. same as CLOB(1M) http://db.apache.org/derby/docs/10.1/ref/rrefblob.html http://db.apache.org/derby/docs/10.1/ref/rrefclob.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-769) CLOB and BLOB descriptions do not specify the default length
[ http://issues.apache.org/jira/browse/DERBY-769?page=all ] Jeff Levitt updated DERBY-769: -- Attachment: derby769-2.diff rrefblob.html rrefclob.html Thanks Dan, Attached patch (derby769-2.diff) takes care of those syntax errors, and htmlfiles are once again included for review. Thanks for the quick feedback! Letme know if everything looks OK. CLOB and BLOB descriptions do not specify the default length Key: DERBY-769 URL: http://issues.apache.org/jira/browse/DERBY-769 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Priority: Trivial Attachments: derby769-2.diff, derby769.diff, rrefblob.html, rrefclob.html BLOB without a length has a default length of 1 mega byte, ie. same as BLOB(1M) CLOB without a length has a default length of 1 mega characters, ie. same as CLOB(1M) http://db.apache.org/derby/docs/10.1/ref/rrefblob.html http://db.apache.org/derby/docs/10.1/ref/rrefclob.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-769) CLOB and BLOB descriptions do not specify the default length
[ http://issues.apache.org/jira/browse/DERBY-769?page=all ] Jeff Levitt updated DERBY-769: -- Attachment: (was: rrefblob.html) CLOB and BLOB descriptions do not specify the default length Key: DERBY-769 URL: http://issues.apache.org/jira/browse/DERBY-769 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Priority: Trivial Attachments: derby769-2.diff, derby769.diff, rrefblob.html, rrefclob.html BLOB without a length has a default length of 1 mega byte, ie. same as BLOB(1M) CLOB without a length has a default length of 1 mega characters, ie. same as CLOB(1M) http://db.apache.org/derby/docs/10.1/ref/rrefblob.html http://db.apache.org/derby/docs/10.1/ref/rrefclob.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-769) CLOB and BLOB descriptions do not specify the default length
[ http://issues.apache.org/jira/browse/DERBY-769?page=all ] Jeff Levitt updated DERBY-769: -- Attachment: (was: rrefclob.html) CLOB and BLOB descriptions do not specify the default length Key: DERBY-769 URL: http://issues.apache.org/jira/browse/DERBY-769 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Daniel John Debrunner Priority: Trivial Attachments: derby769-2.diff, derby769.diff, rrefblob.html, rrefclob.html BLOB without a length has a default length of 1 mega byte, ie. same as BLOB(1M) CLOB without a length has a default length of 1 mega characters, ie. same as CLOB(1M) http://db.apache.org/derby/docs/10.1/ref/rrefblob.html http://db.apache.org/derby/docs/10.1/ref/rrefclob.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-671) Clob.getCharacterStream documented as not supported when it actually is
[ http://issues.apache.org/jira/browse/DERBY-671?page=all ] Jeff Levitt updated DERBY-671: -- Attachment: derby671.diff rrefjdbc96386.html This patch removes the offending NOT SUPPORTED text from the file. If this looks OK, please post approval so the patch can be committed. Thanks! Clob.getCharacterStream documented as not supported when it actually is --- Key: DERBY-671 URL: http://issues.apache.org/jira/browse/DERBY-671 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Lars Clausen Priority: Minor Attachments: derby671.diff, rrefjdbc96386.html In the online documentation for Blob and Clob at http://db.apache.org/derby/docs/10.1/ref/rrefjdbc96386.html#rrefjdbc96386, the Clob.getCharacterStream() method is listed as NOT SUPPORTED[sic], but it is in fact supported, at least in the embedded driver. This misleading documentation led us to use an alternative and noninternationalizable way of reading clobs, so it is not just a cosmetic 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
[jira] Commented: (DERBY-671) Clob.getCharacterStream documented as not supported when it actually is
[ http://issues.apache.org/jira/browse/DERBY-671?page=comments#action_12368810 ] Jeff Levitt commented on DERBY-671: --- Hmmm, I just openedit again. It looksfine. Can a committer see if the patch looks good to them, and commit if so? Thanks! Clob.getCharacterStream documented as not supported when it actually is --- Key: DERBY-671 URL: http://issues.apache.org/jira/browse/DERBY-671 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Lars Clausen Priority: Minor Attachments: derby671.diff, rrefjdbc96386.html In the online documentation for Blob and Clob at http://db.apache.org/derby/docs/10.1/ref/rrefjdbc96386.html#rrefjdbc96386, the Clob.getCharacterStream() method is listed as NOT SUPPORTED[sic], but it is in fact supported, at least in the embedded driver. This misleading documentation led us to use an alternative and noninternationalizable way of reading clobs, so it is not just a cosmetic 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: Updating copyrights for 2006
If you want, I can do the copyright dates and the DTD declarations in one patch and get them all out of the way. --- Jean T. Anderson [EMAIL PROTECTED] wrote: I have been making quite a few changes to the web site since the first of the year and finally got around to updating the forrest skinconf.xml to include 2006 in the copyright. Here's the tail end of a good discussion on the topic that hit the legal-discuss list in January: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200601.mbox/[EMAIL PROTECTED] Forrest generates the copyright at the bottom of each page, so the change is more sweeping than is strictly desirable, but I don't know of a way around that. At any rate, with the code and doc updates that are occurring, probably the copyrights in the headers of some files should be changed to include 2006. -jean
[jira] Updated: (DERBY-539) Update the Create Index statement in the Derby documentation with additional information
[ http://issues.apache.org/jira/browse/DERBY-539?page=all ] Jeff Levitt updated DERBY-539: -- Attachment: derby539-take2.diff rrefsqlj20937.html My second attempt at this patch. Derby539-take2.diff includes Dan's comment. I added the sentence he requests and left the rest of the paragraph alone. HTML file included for review. Update the Create Index statement in the Derby documentation with additional information Key: DERBY-539 URL: http://issues.apache.org/jira/browse/DERBY-539 Project: Derby Type: Improvement Components: Documentation Reporter: Susan Cline Priority: Minor Attachments: derby539-take2.diff, derby539.diff, rrefsqlj20937.html, rrefsqlj20937.html In the 'Create Index' statement documentation of the 10.1 Reference Guide (derby/docs/10.1/ref/rrefsqlj20937.html) this statement is made about creating indexes and constraints: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a UNIQUE or PRIMARY KEY constraint on it, you can not create an index on those columns. Derby has already created it for you with a system-generated name. This is true, but I think it can be expanded upon to be clearer. A suggestion for this is below: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a PRIMARY KEY constraint on it, you can not create an index on those columns. If a column or set of columns has a UNIQUE constraint on it, you can not create an index on those columns, but you can create a PRIMARY KEY constraint on it. Addtionally, if this is the case, a backing index will be created for the PRIMARY KEY constraint so two indexes will now exist on the column or set of columns that had the UNIQUE constraint on it. This issue came up when I noticed that I could create a unique index on a column, then create a PK on that column. When I used a tool to generate DDL for the table I noticed one constraint and two indexes on the column which didn't make sense at first when reading the existing documentation. With the additional information above I think it explains the real behaviour better. -- 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-539) Update the Create Index statement in the Derby documentation with additional information
[ http://issues.apache.org/jira/browse/DERBY-539?page=all ] Jeff Levitt updated DERBY-539: -- Attachment: (was: rrefsqlj20937.html) Update the Create Index statement in the Derby documentation with additional information Key: DERBY-539 URL: http://issues.apache.org/jira/browse/DERBY-539 Project: Derby Type: Improvement Components: Documentation Reporter: Susan Cline Priority: Minor Attachments: derby539-take2.diff, derby539.diff, rrefsqlj20937.html In the 'Create Index' statement documentation of the 10.1 Reference Guide (derby/docs/10.1/ref/rrefsqlj20937.html) this statement is made about creating indexes and constraints: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a UNIQUE or PRIMARY KEY constraint on it, you can not create an index on those columns. Derby has already created it for you with a system-generated name. This is true, but I think it can be expanded upon to be clearer. A suggestion for this is below: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a PRIMARY KEY constraint on it, you can not create an index on those columns. If a column or set of columns has a UNIQUE constraint on it, you can not create an index on those columns, but you can create a PRIMARY KEY constraint on it. Addtionally, if this is the case, a backing index will be created for the PRIMARY KEY constraint so two indexes will now exist on the column or set of columns that had the UNIQUE constraint on it. This issue came up when I noticed that I could create a unique index on a column, then create a PK on that column. When I used a tool to generate DDL for the table I noticed one constraint and two indexes on the column which didn't make sense at first when reading the existing documentation. With the additional information above I think it explains the real behaviour better. -- 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-571) Virtual Table Mapping for no argument Diagnostic tables
[
http://issues.apache.org/jira/browse/DERBY-571?page=comments#action_12368401 ]
Jeff Levitt commented on DERBY-571:
---
Eric recently asked if there are any tables to doc for this. I second that
motion. Could someone please provide information so that this can get
documented? Thanks!
Virtual Table Mapping for no argument Diagnostic tables
---
Key: DERBY-571
URL: http://issues.apache.org/jira/browse/DERBY-571
Project: Derby
Type: Improvement
Components: SQL
Reporter: Daniel John Debrunner
Assignee: Daniel John Debrunner
Priority: Minor
Fix For: 10.2.0.0
Currently four no-argument diagnostic tables exist that provide information
about the running state of Derby, or its error messages.
These tables are invoked using an awkward, non-standard syntax. As an example:
SELECT * FROM NEW org.apache.derby.diag.LockTable() as LOCK_TABLE
The improvement will provide an internal mapping from a regular table name in
the SYSCS_DIAG schema
to the runtime virtual table code. Thus the above example would be replaced
by:
SELECT * FROM SYSCS_DIAG.LOCK_TABLE
These diagnostic table expressions are regular table expressions (as is the
NEW VTI construct) and
can be used wherever a normal table can.
Any DDL, INSERT/UPDATE/DELETE, compression procedure etc. that references a
diagnostic table
will result in an exception.
The old style syntax will remain in place for 10.2, but become deprecated.
The tables to be implemented in this change are:
SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable
SYSCS_DIAG.STATEMENT_CACHEreplaces org.apache.derby.diag.StatementCache
SYSCS_DIAG.TRANSACTION_TABLEreplaces
org.apache.derby.diag.TransactionTable
SYSCS_DIAG.ERROR_MESSAGESreplaces org.apache.derby.diag.ErrorMessages
Adding such a table will be table driven, thus easy for others to provide
additional diagnostics.
Information about these diagnostic tables will not appear in the system
catalogs or JDBC DatabaseMetaData.
The ResultSetMetaData for the any query involving a diagnostic table will be
valid.
This is a first step in a progression towards supporing a fully
application/user defined virtual table.
These steps are not part of this jira issue, but added for information
purposes.
- second step - supporting diagnostic tables with parameters, e.g.
SELECT * FROM SYSCS_DIAG.SPACE_TABLE('sales', 'orders');
- third step - providing a create virtual table statement (most databases
support
some form of virtual table, or wrappers). The DDL would be non-standard
but the
data access would be standard. [need to check table functions in part 13
of SQL standard]
E.g. syntax yet to be defined, but to give the general idea
CREATE VIRTUAL TABLE (TICKER VARCHAR(10), START TIMESTAMP, END
TIMESTAMP)
LANGUAGE JAVA
PARAMETER STYLE JAVA
EXTERNAL NAME 'com.acme.stocks.historyFromYahooFinance';
--
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-627) Documentation needs to be updated with correct return type for COUNT functions
[ http://issues.apache.org/jira/browse/DERBY-627?page=comments#action_12368406 ] Jeff Levitt commented on DERBY-627: --- Could someone possibly review this patch please? Documentation needs to be updated with correct return type for COUNT functions -- Key: DERBY-627 URL: http://issues.apache.org/jira/browse/DERBY-627 Project: Derby Type: Bug Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby627.diff, rrefsqlj38716.html, rrefsqlj66113.html Derby Reference manual (Section 'Built-in functions', pg80-81) specifies the resulting data type of COUNT and COUNT(*) functions as BIGINT. Whereas, Derby returns INTEGER type for these functions. -- 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-629) Update documentation with correct default values for network server properties
[ http://issues.apache.org/jira/browse/DERBY-629?page=comments#action_12368407 ] Jeff Levitt commented on DERBY-629: --- Could someone please review this patch? Thanks in advance! Update documentation with correct default values for network server properties -- Key: DERBY-629 URL: http://issues.apache.org/jira/browse/DERBY-629 Project: Derby Type: Sub-task Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby629.diff, radmindrdamaxthreads.html, radmindrdaminthreads.html, radmindrdatimeslice.html Derby Server and Admin guide needs to be updated with the correct default value for the following network server properties: derby.drda.maxThreads derby.drda.minThreads derby.drda.timeSlice The default value for the above properties is 0. This information has to be updated in section 'Setting Network Server properties', pg 28 -29 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
Thanks Kristian, We usually do an edit before any release, and capitalization consistency gets picked up then. So I think we should commit it. Thanks again! --- Kristian Waagan (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12367995 ] Kristian Waagan commented on DERBY-809: --- I reviewed Jeff's patch (derby809.diff), and it looks good. I do have two comments: 1) The DOCTYPE tags have been changed, but I don't know what they should be like. Since Jeff has built the HTML files, I take they are good. 2) The capitalization of connection number should be consistent. Both ..connection number... and ...Connection Number... are used. These are not blockers, and I leave it up to the committers whether it is a go or not. Thank you for updating the manuals Jeff! Incorrect documentation for 'NetworkServerControl.logConnections(boolean)' -- Key: DERBY-809 URL: http://issues.apache.org/jira/browse/DERBY-809 Project: Derby Type: Bug Components: Documentation, Javadoc Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1 Reporter: Kristian Waagan Priority: Minor Fix For: 10.2.0.0, 10.1.3.0 Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html The documentation for 'NetworkServerControl.logConnections(boolean)' states that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) earlier releases, this is not true. The documentation should be corrected to avoid confusing users. The thought of adding logging of disconnections has also been posted on derby-dev. Byran Pendleton identified the following documentation with the incorrect description: http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html Should we fix this in 10.0? If yes, please update fix versions for 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: Derby HTML book manuals - invalid anchors in TOC? (DERBY-753)
I can tell you that this is a problem that could be hard to fix. The single-html books are not a normal result of the DITA transform. However, some time ago Andrew found an xsl file on the web that we were able to use to transform the half-processed PDF transforms from the DITA process and convert them to html. Unfortunately, since that XSL file came from outside of DITA, it is not supported by their project. If someone has time they can try to modify that xsl file to fix this problem, but I think the single-html files were put in place as sort of a bonus when Andrew found that xsl file, so I wouldnt expect to see as much progress on the quality of those books as the other two types of output, unless someone else knows what they are doing and can fix this (I dont!) :) Also, Andrew, do you know if the xsl file is legally modifiable? --- Kristian Waagan [EMAIL PROTECTED] wrote: John Embretsen wrote: Kristian Waagan wrote: Hello, Some time ago I created DERBY-753 (http://issues.apache.org/jira/browse/DERBY-753), but there has not been any activity on it since then. It says that the links in the table of contents of the HTML book manuals do not work. Can anyone confirm that the problem (still) exists? I can confirm that the problem still exists with the 10.2 reference manual. I have not tried the others. I also tried the link (from the Jira issue) that was supposed to work, but it did not work either. I.e.: http://db.apache.org/derby/docs/dev/ref/ref-single.html#crefsqlj95081 does not work; http://db.apache.org/derby/docs/dev/ref/ref-single.html#N1223F does not work; but http://db.apache.org/derby/docs/dev/ref/ref-single.html#N1227F works. Okay, thanks for confirming the problem. For the links, the point was to illustrate that there are anchors in the files, but they are not used. To me, it looks like there has been some kind of mapping error or something during the build process. I do not know how the anchors are defined and how the documentation build process works. Can anyone with more Derby documentation building experience see the reason for this problem? Since I believe we don't exactly score Top rated on our documentation, I would say this problem should be fixed pretty quickly! It hinders navigation severely. -- Kristian
Re: [jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
Yep! I've done it the last few releases. Its not that bad really. I do a spell check and look for consistency and grammar fixes like this. I'm definitely glad to welcome additional help if someone wants to contribute! We also do technical reviews of each manual before each release. Everyone is given a time frame in which to review the manuals. So there are lots of avenues for QA on the books. --- John Embretsen [EMAIL PROTECTED] wrote: Monday, February 27, 2006, 7:01:25 PM CET, Jeff Levitt wrote: Thanks Kristian, We usually do an edit before any release, and capitalization consistency gets picked up then. So I think we should commit it. I'm just curious; who edits what before any release? Are you saying that you (?) are planning to go through all derby manuals and look for issues of this type before the next release? Sounds like a rather large undertaking... not that I don't want it to happen ;) Kristian Waagan commented on DERBY-809: --- I reviewed Jeff's patch (derby809.diff), and it looks good. I do have two comments: 1) The DOCTYPE tags have been changed, but I don't know what they should be like. Since Jeff has built the HTML files, I take they are good. Here's Jeff's justification for changing the DOCTYPE: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200602.mbox/[EMAIL PROTECTED] I have also looked at the patch (html), and agree with Kristian. -- John
Re: [jira] Commented: (DERBY-936) Main branch docs display version as 10.1, should be 10.2.
OK, thanks Andrew. We'll try again after some of those issues settle down later on. --- Andrew McIntyre (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-936?page=comments#action_12367613 ] Andrew McIntyre commented on DERBY-936: --- Hi Jeff, it looks like we can't do a straight search-and-replace here. Even in the first few diffs I see places where if 10.1 is changed to 10.2, the text may no longer be correct. In some cases, the functionality in question is still under development for 10.2. I think we should revisit this issue at a later date. Main branch docs display version as 10.1, should be 10.2. - Key: DERBY-936 URL: http://issues.apache.org/jira/browse/DERBY-936 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.0 Reporter: Andrew McIntyre Attachments: derby936.diff Currently the output for the PDF and HTML Book formats of the manuals on the main branch display the version 10.1. Documentation changes have been committed which make the main branch of the documentation no longer proper for 10.1, so the version the main branch of the documentation displays should be 10.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section.
[ http://issues.apache.org/jira/browse/DERBY-482?page=comments#action_12367232 ] Jeff Levitt commented on DERBY-482: --- Thats so strange. It did it to me too, and I looked at the original copy on my local machine and it looked fine. Mamtam when you try again, maybe just force it to an html extension by stripping the .xml it adds to the file name. Then open it up again and you should read it fine. GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section. Key: DERBY-482 URL: http://issues.apache.org/jira/browse/DERBY-482 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Mamta A. Satoor Attachments: ctoolsimportidentitycol.html, derby482.diff Tomohito added support for import into identity columns by adding GENERATED BY DEFAULT option. This is documented in the Reference Guide but not in the Tools and Utilites Guide which is where a user would look for details on import. IMHO, there should be information about this in Importing into tables with identity columns section in Tools and Utilities Guide. -- 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-931) Until Derby-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly
[ http://issues.apache.org/jira/browse/DERBY-931?page=comments#action_12367064 ] Jeff Levitt commented on DERBY-931: --- The following section in the Server-Admin guide: http://db.apache.org/derby/docs/dev/adminguide/cadminapps.html describes differences between embedded and network server mode. Which topic in this section do you want to see this documented? Until Derby-911 gets fixed, document the difference in behavior between Nework Client Driver and Embedded Driver for setReadOnly Key: DERBY-931 URL: http://issues.apache.org/jira/browse/DERBY-931 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.1 Reporter: Mamta A. Satoor Derby 911 Connection.setReadOnly is a no-op in Network Client. It works fine with embedded client. has more details on this issue but basically, we should document the difference in behavior for setReadOnly between Network Driver and Embedded Driver. -- 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-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
[ http://issues.apache.org/jira/browse/DERBY-809?page=all ] Jeff Levitt updated DERBY-809: -- Attachment: derby809.diff radminconfigdb2jdrdalogconnections.html tadminlogfile.html This patch complements the javadoc patch that Kristian submitted. The HTML output is included for review. If acceptable, the commits should port back to previous versions as well. Incorrect documentation for 'NetworkServerControl.logConnections(boolean)' -- Key: DERBY-809 URL: http://issues.apache.org/jira/browse/DERBY-809 Project: Derby Type: Bug Components: Documentation, Javadoc Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1 Reporter: Kristian Waagan Priority: Minor Fix For: 10.2.0.0, 10.1.3.0 Attachments: DERBY-809-1a-javadoc.diff, DERBY-809-1a-javadoc.stat, derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html The documentation for 'NetworkServerControl.logConnections(boolean)' states that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) earlier releases, this is not true. The documentation should be corrected to avoid confusing users. The thought of adding logging of disconnections has also been posted on derby-dev. Byran Pendleton identified the following documentation with the incorrect description: http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html Should we fix this in 10.0? If yes, please update fix versions for 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
[jira] Commented: (DERBY-870) Update documentation on setting up LDAP user authentication.
[ http://issues.apache.org/jira/browse/DERBY-870?page=comments#action_12366998 ] Jeff Levitt commented on DERBY-870: --- Has this been verified? If someone can confirm what is now needed, I would be happy to make a patch to update this part of the doc. Update documentation on setting up LDAP user authentication. Key: DERBY-870 URL: http://issues.apache.org/jira/browse/DERBY-870 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2 Reporter: Sunitha Kambhampati Priority: Minor http://db.apache.org/derby/docs/dev/devguide/rdevcsecure608.html This talks about needing jndi.jar , ldap.jar and providerUtil.jar. I think this is not true anymore with the latest 1.4.2 vms atleast, and should be updated. It seems like with 1.4.2 etc, all these classes are in rt.jar. Need to verify and the doc needs to be updated. -- 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-820) path name incorrect in simple example doc
[ http://issues.apache.org/jira/browse/DERBY-820?page=all ] Jeff Levitt updated DERBY-820: -- Attachment: derby820.diff Pretty simple fix; I took out the program/ in the directory in the two places it was displayed. This is ready for a commitif no one objects... path name incorrect in simple example doc - Key: DERBY-820 URL: http://issues.apache.org/jira/browse/DERBY-820 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.1 Reporter: Tim Ellison Priority: Minor Attachments: derby820.diff The simple example doc (installed for me in file:///C:/db-derby-10.1.2.1-bin/demo/simple/example.html) contains a minor error: Section : How to run this sample application... and change directories to the %DERBY_INSTALL%\demo\programs\simple directory. should be and change directories to the %DERBY_INSTALL%\demo\simple directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: derby.service property mentioned in the Developer's Guide
--- Jean T. Anderson [EMAIL PROTECTED] wrote: These Developer's Guide sections reference derby.service: http://db.apache.org/derby/docs/dev/devguide/cdevdeploy11201.html http://db.apache.org/derby/docs/dev/devguide/cdevdvlp27610.html http://db.apache.org/derby/docs/dev/devguide/cdevdvlp846402.html The last 2 refer the reader to the Tuning guide, which doesn't mention this property anywhere and, probably most importantly, it isn't on the list of properties: http://db.apache.org/derby/docs/dev/tuning/ctunproper22250.html I didn't spot derby.service in engine/org/apache/derby/iapi/reference/Property.java . Are the references in the Developer's Guide old and should be removed? Or is there such a property that needs to get documented? thanks, -jean Jean brought this issue up awhile back, and I dont remember seeing a response or a JIRA issue filed for it. Does anyone know if derby.service should be removed from the docs? If so, I can file a JIRA issue and submit a patch.
[jira] Commented: (DERBY-784) Document predicate push down through union clause in Tuning guide where other similar optimizations are discussed.
[ http://issues.apache.org/jira/browse/DERBY-784?page=comments#action_12367000 ] Jeff Levitt commented on DERBY-784: --- I want to take a stab at a patch to the documentation for this, but in reading the other two connected issues, I wasn't able to discern what needed to be added/changed in the docs. Ifsomeone can provide me with alittle info to get started, I'd be happy to work on this... Document predicate push down through union clause in Tuning guide where other similar optimizations are discussed. -- Key: DERBY-784 URL: http://issues.apache.org/jira/browse/DERBY-784 Project: Derby Type: Sub-task Components: Documentation Versions: 10.1.2.0, 10.2.0.0 Reporter: Satheesh Bandaram Priority: Minor Fix For: 10.2.0.0 Document optimization implemented under DERBY-649 and DERBY-772 in tuning guide where similar such optimizations are discussed. -- 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-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
[ http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12367001 ] Jeff Levitt commented on DERBY-809: --- Can someone confirm that the problem is that disconnections are documented as being logable when they are in fact not? If that's the case, I'd be happy to submit a patch that removes the references to disconnection logging. However, one of the links above is to the javadoc, which i am not familiar with, so I can patch the normal docs, but hopefully someone else can patch the javadoc. Incorrect documentation for 'NetworkServerControl.logConnections(boolean)' -- Key: DERBY-809 URL: http://issues.apache.org/jira/browse/DERBY-809 Project: Derby Type: Bug Components: Documentation, Javadoc Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1 Reporter: Kristian Waagan Priority: Minor Fix For: 10.2.0.0, 10.1.3.0 The documentation for 'NetworkServerControl.logConnections(boolean)' states that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) earlier releases, this is not true. The documentation should be corrected to avoid confusing users. The thought of adding logging of disconnections has also been posted on derby-dev. Byran Pendleton identified the following documentation with the incorrect description: http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html Should we fix this in 10.0? If yes, please update fix versions for 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
[jira] Updated: (DERBY-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=all ] Jeff Levitt updated DERBY-402: -- Attachment: (was: rrefselectexpression.html) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=all ] Jeff Levitt updated DERBY-402: -- Attachment: (was: rrefsqlj1083019.html) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=all ] Jeff Levitt updated DERBY-402: -- Attachment: (was: derby402.diff) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=all ] Jeff Levitt updated DERBY-402: -- Attachment: derby402Final.diff rrefselectexpression.html rrefsqlj1083019.html This patch needed to be updated since Eric Radzinski recently contributed a patch that modified one of the files in this patch. As a result, this patch would have caused a conflict, so I deleted the old patch and am replacing it with a new one with the same changes except it was made at a higher revision number. HTML files included for review. INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 Attachments: derby402Final.diff, rrefselectexpression.html, rrefsqlj1083019.html I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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-748) Should document the default schemas in a newly created database
[ http://issues.apache.org/jira/browse/DERBY-748?page=comments#action_12366932 ] Jeff Levitt commented on DERBY-748: --- If someone can provide me with the columns for these tables as well as other metadata such as those doc'd in the reference manuals for other tables (for example): http://db.apache.org/derby/docs/dev/ref/rrefsistabs28114.html If I get that kind of information I would be happy to place it in similar topics within the reference manual. Should document the default schemas in a newly created database --- Key: DERBY-748 URL: http://issues.apache.org/jira/browse/DERBY-748 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.2.1 Reporter: Oyvind Bakksjo A newly created database will contain the following schemas: NULLID SQLJ SYS SYSCAT SYSCS_DIAG SYSCS_UTIL SYSFUN SYSIBM SYSPROC SYSSTAT These should be documented, at least in the Reference Guide. -- 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-936) Main branch docs display version as 10.1, should be 10.2.
[ http://issues.apache.org/jira/browse/DERBY-936?page=all ] Jeff Levitt updated DERBY-936: -- Attachment: derby936.diff This patch is a simple search and replace of Version 10.1 in the docs and replacesit with 10.2. Subsequent output html and PDF's will have version 10.2 displayed. Main branch docs display version as 10.1, should be 10.2. - Key: DERBY-936 URL: http://issues.apache.org/jira/browse/DERBY-936 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.0 Reporter: Andrew McIntyre Attachments: derby936.diff Currently the output for the PDF and HTML Book formats of the manuals on the main branch display the version 10.1. Documentation changes have been committed which make the main branch of the documentation no longer proper for 10.1, so the version the main branch of the documentation displays should be 10.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-936) Main branch docs display version as 10.1, should be 10.2.
[ http://issues.apache.org/jira/browse/DERBY-936?page=all ] Jeff Levitt updated DERBY-936: -- Other Info: [Patch available] Main branch docs display version as 10.1, should be 10.2. - Key: DERBY-936 URL: http://issues.apache.org/jira/browse/DERBY-936 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.0 Reporter: Andrew McIntyre Attachments: derby936.diff Currently the output for the PDF and HTML Book formats of the manuals on the main branch display the version 10.1. Documentation changes have been committed which make the main branch of the documentation no longer proper for 10.1, so the version the main branch of the documentation displays should be 10.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-629) Update documentation with correct default values for network server properties
[ http://issues.apache.org/jira/browse/DERBY-629?page=all ] Jeff Levitt updated DERBY-629: -- Attachment: derby629.diff radmindrdamaxthreads.html radmindrdaminthreads.html Thispatch changes the indicated default values to 0. HTML included for review... Update documentation with correct default values for network server properties -- Key: DERBY-629 URL: http://issues.apache.org/jira/browse/DERBY-629 Project: Derby Type: Sub-task Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby629.diff, radmindrdamaxthreads.html, radmindrdaminthreads.html Derby Server and Admin guide needs to be updated with the correct default value for the following network server properties: derby.drda.maxThreads derby.drda.minThreads derby.drda.timeSlice The default value for the above properties is 0. This information has to be updated in section 'Setting Network Server properties', pg 28 -29 -- 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-629) Update documentation with correct default values for network server properties
[ http://issues.apache.org/jira/browse/DERBY-629?page=all ] Jeff Levitt updated DERBY-629: -- Attachment: radmindrdatimeslice.html Update documentation with correct default values for network server properties -- Key: DERBY-629 URL: http://issues.apache.org/jira/browse/DERBY-629 Project: Derby Type: Sub-task Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby629.diff, radmindrdamaxthreads.html, radmindrdaminthreads.html, radmindrdatimeslice.html Derby Server and Admin guide needs to be updated with the correct default value for the following network server properties: derby.drda.maxThreads derby.drda.minThreads derby.drda.timeSlice The default value for the above properties is 0. This information has to be updated in section 'Setting Network Server properties', pg 28 -29 -- 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-629) Update documentation with correct default values for network server properties
[ http://issues.apache.org/jira/browse/DERBY-629?page=all ] Jeff Levitt updated DERBY-629: -- Other Info: [Patch available] Update documentation with correct default values for network server properties -- Key: DERBY-629 URL: http://issues.apache.org/jira/browse/DERBY-629 Project: Derby Type: Sub-task Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby629.diff, radmindrdamaxthreads.html, radmindrdaminthreads.html, radmindrdatimeslice.html Derby Server and Admin guide needs to be updated with the correct default value for the following network server properties: derby.drda.maxThreads derby.drda.minThreads derby.drda.timeSlice The default value for the above properties is 0. This information has to be updated in section 'Setting Network Server properties', pg 28 -29 -- 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-627) Documentation needs to be updated with correct return type for COUNT functions
[ http://issues.apache.org/jira/browse/DERBY-627?page=all ] Jeff Levitt updated DERBY-627: -- Attachment: derby627.diff rrefsqlj38716.html rrefsqlj66113.html Attached patch changes the indicated datatype to INTEGER in both files. HTML output included for review. Documentation needs to be updated with correct return type for COUNT functions -- Key: DERBY-627 URL: http://issues.apache.org/jira/browse/DERBY-627 Project: Derby Type: Bug Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby627.diff, rrefsqlj38716.html, rrefsqlj66113.html Derby Reference manual (Section 'Built-in functions', pg80-81) specifies the resulting data type of COUNT and COUNT(*) functions as BIGINT. Whereas, Derby returns INTEGER type for these functions. -- 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-627) Documentation needs to be updated with correct return type for COUNT functions
[ http://issues.apache.org/jira/browse/DERBY-627?page=all ] Jeff Levitt updated DERBY-627: -- Other Info: [Patch available] Documentation needs to be updated with correct return type for COUNT functions -- Key: DERBY-627 URL: http://issues.apache.org/jira/browse/DERBY-627 Project: Derby Type: Bug Components: Documentation Versions: 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby627.diff, rrefsqlj38716.html, rrefsqlj66113.html Derby Reference manual (Section 'Built-in functions', pg80-81) specifies the resulting data type of COUNT and COUNT(*) functions as BIGINT. Whereas, Derby returns INTEGER type for these functions. -- 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-542) Update documentation for DERBY-470
[ http://issues.apache.org/jira/browse/DERBY-542?page=all ] Jeff Levitt updated DERBY-542: -- Attachment: derby542.diff rtoolsijcomref88554.html Attached patch adds the note to the topic as requested. HTML output included for review. Update documentation for DERBY-470 -- Key: DERBY-542 URL: http://issues.apache.org/jira/browse/DERBY-542 Project: Derby Type: Sub-task Components: Documentation Versions: 10.1.1.0, 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby542.diff, rtoolsijcomref88554.html To reflect the change for DERBY-470, the following information has to be added to Derby Tools and Utilities Guide: Section ij commands and errors reference--LocalizedDisplay: NUMERIC and DECIMAL values are not localized on J2ME/CDC/Foundation Profile because of platform limitations. Please review this. Also, is there any other place in the documents where this info needs to be added? It would be great if someone working on documents can make this change. -- 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-542) Update documentation for DERBY-470
[ http://issues.apache.org/jira/browse/DERBY-542?page=all ] Jeff Levitt updated DERBY-542: -- Other Info: [Patch available] Update documentation for DERBY-470 -- Key: DERBY-542 URL: http://issues.apache.org/jira/browse/DERBY-542 Project: Derby Type: Sub-task Components: Documentation Versions: 10.1.1.0, 10.2.0.0 Reporter: Deepa Remesh Priority: Minor Attachments: derby542.diff, rtoolsijcomref88554.html To reflect the change for DERBY-470, the following information has to be added to Derby Tools and Utilities Guide: Section ij commands and errors reference--LocalizedDisplay: NUMERIC and DECIMAL values are not localized on J2ME/CDC/Foundation Profile because of platform limitations. Please review this. Also, is there any other place in the documents where this info needs to be added? It would be great if someone working on documents can make this change. -- 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-539) Update the Create Index statement in the Derby documentation with additional information
[ http://issues.apache.org/jira/browse/DERBY-539?page=all ] Jeff Levitt updated DERBY-539: -- Attachment: derby539.diff rrefsqlj20937.html Attached patch adds the sentences and modifies the existing text as requested. Please review the included HTML files to approve the commit. Thanks! Update the Create Index statement in the Derby documentation with additional information Key: DERBY-539 URL: http://issues.apache.org/jira/browse/DERBY-539 Project: Derby Type: Improvement Components: Documentation Reporter: Susan Cline Priority: Minor Attachments: derby539.diff, rrefsqlj20937.html In the 'Create Index' statement documentation of the 10.1 Reference Guide (derby/docs/10.1/ref/rrefsqlj20937.html) this statement is made about creating indexes and constraints: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a UNIQUE or PRIMARY KEY constraint on it, you can not create an index on those columns. Derby has already created it for you with a system-generated name. This is true, but I think it can be expanded upon to be clearer. A suggestion for this is below: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a PRIMARY KEY constraint on it, you can not create an index on those columns. If a column or set of columns has a UNIQUE constraint on it, you can not create an index on those columns, but you can create a PRIMARY KEY constraint on it. Addtionally, if this is the case, a backing index will be created for the PRIMARY KEY constraint so two indexes will now exist on the column or set of columns that had the UNIQUE constraint on it. This issue came up when I noticed that I could create a unique index on a column, then create a PK on that column. When I used a tool to generate DDL for the table I noticed one constraint and two indexes on the column which didn't make sense at first when reading the existing documentation. With the additional information above I think it explains the real behaviour better. -- 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-539) Update the Create Index statement in the Derby documentation with additional information
[ http://issues.apache.org/jira/browse/DERBY-539?page=all ] Jeff Levitt updated DERBY-539: -- Other Info: [Patch available] Update the Create Index statement in the Derby documentation with additional information Key: DERBY-539 URL: http://issues.apache.org/jira/browse/DERBY-539 Project: Derby Type: Improvement Components: Documentation Reporter: Susan Cline Priority: Minor Attachments: derby539.diff, rrefsqlj20937.html In the 'Create Index' statement documentation of the 10.1 Reference Guide (derby/docs/10.1/ref/rrefsqlj20937.html) this statement is made about creating indexes and constraints: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a UNIQUE or PRIMARY KEY constraint on it, you can not create an index on those columns. Derby has already created it for you with a system-generated name. This is true, but I think it can be expanded upon to be clearer. A suggestion for this is below: Indexes and constraints Unique, primary key, and foreign key constraints generate indexes that enforce or back the constraint (and are thus sometimes called backing indexes). If a column or set of columns has a PRIMARY KEY constraint on it, you can not create an index on those columns. If a column or set of columns has a UNIQUE constraint on it, you can not create an index on those columns, but you can create a PRIMARY KEY constraint on it. Addtionally, if this is the case, a backing index will be created for the PRIMARY KEY constraint so two indexes will now exist on the column or set of columns that had the UNIQUE constraint on it. This issue came up when I noticed that I could create a unique index on a column, then create a PK on that column. When I used a tool to generate DDL for the table I noticed one constraint and two indexes on the column which didn't make sense at first when reading the existing documentation. With the additional information above I think it explains the real behaviour better. -- 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-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=comments#action_12366845 ] Jeff Levitt commented on DERBY-402: --- So I'm trying to understand the doc impact of this bug. Should the offending sentences just be removed? Thanks! INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
[ http://issues.apache.org/jira/browse/DERBY-402?page=all ] Jeff Levitt updated DERBY-402: -- Other Info: [Patch available] INTERSECT/EXCEPT/UNION operators don't agree with documented behavior. -- Key: DERBY-402 URL: http://issues.apache.org/jira/browse/DERBY-402 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0, 10.0.2.2 Reporter: A B Fix For: 10.2.0.0 Attachments: derby402.diff, rrefselectexpression.html, rrefsqlj1083019.html I noticed the following two differences between what the documentation (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the actual Derby behavior is. I'm filing this issue as a single bug against Derby, but if it turns out later that this is really just a documentation issue, or that these are improvements instead of bugs, anyone should feel free to change the relevant fields in this issue... 1) -- p. 63 of the Reference Manual (PDF version): SelectExpression - Naming columns First paragraph in this section includes the following: When the SelectExpression appears in a UNION, INTERSECT, or EXCEPT operator, the names from the first SelectExpression are taken as the names for the columns in the result of the operation. But this doesn't appear to be true. Ex: ij select a from t1 union select b from t2; 1 // This 1 should be A, according to doc. --- 1 2 If this behavior is intentional, then an ORDER BY clause on a UNION/INTERSECT/EXCEPT result set can only reference the result columns by position (ex. would have to use order by 1 in the above query since order by a doesn't work (because the name of the result column isn't a)). Note that if both SelectExpressions have the same column name, then things work differently: ij select a from t1 union select b as a from t2; A // Now it's A instead of 1. --- 1 2 So what needs to be corrected here? The documentation or the code? 2) -- p. 133 of the Reference Manual: Dynamic Parameters - Where dynamic parameters are allowed Number 16 says a dynamic parameter is allowed to represent a column if it appears in a UNION, INTERSECT, or EXCEPT expression. But the two examples that it gives both fail: ij SELECT ? FROM t UNION SELECT 1 FROM t; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. ij VALUES 1 UNION VALUES ?; ERROR 42X34: There is a ? parameter in the select list. This is not allowed. I also tried preparing these statements using JDBC, but they failed there with the same error.. -- 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-994) SQL examples for LEFT OUTER JOIN and RIGHT OUTER JOIN in the Derby Reference manual are incorrect
[ http://issues.apache.org/jira/browse/DERBY-994?page=all ] Jeff Levitt updated DERBY-994: -- Other Info: [Patch available] SQL examples for LEFT OUTER JOIN and RIGHT OUTER JOIN in the Derby Reference manual are incorrect - Key: DERBY-994 URL: http://issues.apache.org/jira/browse/DERBY-994 Project: Derby Type: Bug Components: Documentation Versions: 10.0.2.0 Reporter: Rajesh Kartha Fix For: 10.2.0.0 Attachments: derby994.diff, rrefsqlj18922.html, rrefsqlj57522.html The SQL examples for the following in the reference manual are wrong: - LEFT OUTER JOIN - RIGHT OUTER JOIN The incorrectness are pointed out below. Also the fix (correct sql and descriptions) that should replace these are provided. Can someone please review this and commit into the codeline. LEFT OUTER JOIN : (v10.1) http://db.apache.org/derby/docs/10.1/ref/rrefsqlj18922.html (trunk) http://db.apache.org/derby/docs/dev/ref/rrefsqlj18922.html The manual shows: quote --match cities to countries [wrong description: should mention cities to countries in Asia] == SELECT CITIES.COUNTRY, REGION FROM Countries LEFT OUTER JOIN Cities ON CITY_ID=CITY_ID WHERE REGION = 'Asia'; [wrong sql: This will return 1305 rows meaningless rows] == -- use the synonymous syntax, RIGHT JOIN, to achieve exactly -- the same results as in the example above [wrong description: The synonymous syntax is LEFT JOIN] == SELECT COUNTRIES.COUNTRY, REGION FROM Countries LEFT JOIN Cities ON CITY_ID=CITY_ID; [wrong sql: Returns a Cartesian product of the two tables: 9918 rows selected] == /quote The correct description and sql for LEFT OUTER JOIN should be: --- --match cities to countries in Asia SELECT COUNTRIES.COUNTRY, CITIES.CITY_NAME,REGION FROM COUNTRIES LEFT OUTER JOIN CITIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE WHERE REGION='Asia'; -- use the synonymous syntax, LEFT JOIN, to achieve exactly -- the same results as in the example above SELECT COUNTRIES.COUNTRY, CITIES.CITY_NAME,REGION FROM COUNTRIES LEFT JOIN CITIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE WHERE REGION='Asia'; [Both the above queries will return COUNTRY |CITY_NAME |REGION -- Afghanistan |Kabul |Asia Bangladesh|NULL|Asia Cambodia |NULL|Asia China |Hong Kong |Asia China |Shanghai|Asia India |Bombay |Asia India |Calcutta|Asia Indonesia |Jakarta |Asia Japan |Osaka |Asia Japan |Tokyo |Asia Korea, Republic of|Seoul |Asia Malaysia |NULL|Asia Nepal |NULL|Asia Philippines |Manila |Asia Singapore |Singapore |Asia Sri Lanka |NULL|Asia Thailand |NULL|Asia Viet Nam |NULL|Asia 18 rows selected] == RIGHT OUTER JOIN: = (v10.1) http://db.apache.org/derby/docs/10.1/ref/rrefsqlj57522.html (trunk) http://db.apache.org/derby/docs/dev/ref/rrefsqlj57522.html The manual shows: quote -- get all countries and corresponding cities, including -- countries without any cities SELECT CITY_NAME, CITIES.COUNTRY FROM CITIES RIGHT OUTER JOIN COUNTRIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE; [wrong sql: Return meaningless 156 rows ] == -- get all countries in Africa and corresponding cities, including -- countries without any cities SELECT CITY_NAME, CITIES.COUNTRY FROM CITIES RIGHT OUTER JOIN COUNTRIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE; WHERE Countries.region = 'frica'; [wrong sql: 1) 'frica' is incorrect in the WHERE clause 2) incorrect results with NULL country values 3) incorrect ';' before WHERE clause] == -- use the synonymous syntax, RIGHT JOIN, to achieve exactly -- the same results as in the example above SELECT CITY_NAME, CITIES.COUNTRY FROM CITIES RIGHT JOIN COUNTRIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE WHERE Countries.region = 'Africa'; [wrong sql: Incorrect results with NULL country values] == /quote The correct description and sql for RIGHT OUTER JOIN should
[jira] Updated: (DERBY-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section.
[ http://issues.apache.org/jira/browse/DERBY-482?page=all ] Jeff Levitt updated DERBY-482: -- Attachment: derby482.diff ctoolsimportidentitycol.html For this patch, I copied the information in the Reference Manual on GENERATED BY DEFAULT and placed it in the Importing into tables with identity columns topic in the Tools and Utilities Guide after the information on GENERATED ALWAYS. I then modified the introductory paragraph of the topic to mention both options. I am including an HTML output file for review with this patch. I'd appreciate any feedback. Thanks! GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section. Key: DERBY-482 URL: http://issues.apache.org/jira/browse/DERBY-482 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Mamta A. Satoor Attachments: ctoolsimportidentitycol.html, derby482.diff Tomohito added support for import into identity columns by adding GENERATED BY DEFAULT option. This is documented in the Reference Guide but not in the Tools and Utilites Guide which is where a user would look for details on import. IMHO, there should be information about this in Importing into tables with identity columns section in Tools and Utilities Guide. -- 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-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section.
[ http://issues.apache.org/jira/browse/DERBY-482?page=all ] Jeff Levitt updated DERBY-482: -- Other Info: [Patch available] GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under Importing into tables with identity columns section. Key: DERBY-482 URL: http://issues.apache.org/jira/browse/DERBY-482 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Mamta A. Satoor Attachments: ctoolsimportidentitycol.html, derby482.diff Tomohito added support for import into identity columns by adding GENERATED BY DEFAULT option. This is documented in the Reference Guide but not in the Tools and Utilites Guide which is where a user would look for details on import. IMHO, there should be information about this in Importing into tables with identity columns section in Tools and Utilities Guide. -- 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
[doc] Derby DITA documentation source DTD declarations
Hi all, I noticed that in the DITA doc source files that we have DTD declarations at the top that look like this: !DOCTYPE reference PUBLIC -//IBM//DTD DITA Reference//EN ../dtd/reference.dtd Note that the declarations have the word IBM in them. This is because they are based on an old DTD that DITA used before it was contributed to the open source OASIS foundation. Currently, the correct OASIS DTD declaration looks like this: !DOCTYPE reference PUBLIC -//OASIS//DTD DITA Reference//EN reference.dtd While I dont see any problems with the old IBM declaration right now, we will miss out on features in the future if we dont migrate to the new OASIS declaration. We could do a search and replace, but we'd have to be sure to do it correctly. I dont think this is a crucial requirement right now, so alternatively I suggest that as doc contributors submit patches to doc code, they should change the declaration to the files they change as they go. It wont hurt anything to have different DTD declarations in different files, and this solution allows us to continue to work on the files without having to commit time and resources to a migration. If no one has any problems with this, I'll begin submitting patches with the new declaration. Also, is there some place we can make this directive moreprominent so future contributors will see it? Any suggestions? Of course, if someone wants to make a script that fixes the problem, that's alright too. It would require changing the word IBM in the declaration to OASIS, and the ../ before the concept.dtd, reference.dtd, and task.dtd to be removed. Jeff
Re: [doc] Derby DITA documentation source DTD declarations
--- Jeff Levitt [EMAIL PROTECTED] wrote: Of course, if someone wants to make a script that fixes the problem, that's alright too. It would require changing the word IBM in the declaration to OASIS, and the ../ before the concept.dtd, reference.dtd, and task.dtd to be removed. Jeff Ooops, what I meant to say is that ../dtd/ would have to be removed, not just ../
[jira] Updated: (DERBY-994) SQL examples for LEFT OUTER JOIN and RIGHT OUTER JOIN in the Derby Reference manual are incorrect
[ http://issues.apache.org/jira/browse/DERBY-994?page=all ] Jeff Levitt updated DERBY-994: -- Attachment: derby994.diff rrefsqlj18922.html rrefsqlj57522.html Attached patch fixes the examples as requested. HTML output included for review. SQL examples for LEFT OUTER JOIN and RIGHT OUTER JOIN in the Derby Reference manual are incorrect - Key: DERBY-994 URL: http://issues.apache.org/jira/browse/DERBY-994 Project: Derby Type: Bug Components: Documentation Versions: 10.0.2.0 Reporter: Rajesh Kartha Fix For: 10.2.0.0 Attachments: derby994.diff, rrefsqlj18922.html, rrefsqlj57522.html The SQL examples for the following in the reference manual are wrong: - LEFT OUTER JOIN - RIGHT OUTER JOIN The incorrectness are pointed out below. Also the fix (correct sql and descriptions) that should replace these are provided. Can someone please review this and commit into the codeline. LEFT OUTER JOIN : (v10.1) http://db.apache.org/derby/docs/10.1/ref/rrefsqlj18922.html (trunk) http://db.apache.org/derby/docs/dev/ref/rrefsqlj18922.html The manual shows: quote --match cities to countries [wrong description: should mention cities to countries in Asia] == SELECT CITIES.COUNTRY, REGION FROM Countries LEFT OUTER JOIN Cities ON CITY_ID=CITY_ID WHERE REGION = 'Asia'; [wrong sql: This will return 1305 rows meaningless rows] == -- use the synonymous syntax, RIGHT JOIN, to achieve exactly -- the same results as in the example above [wrong description: The synonymous syntax is LEFT JOIN] == SELECT COUNTRIES.COUNTRY, REGION FROM Countries LEFT JOIN Cities ON CITY_ID=CITY_ID; [wrong sql: Returns a Cartesian product of the two tables: 9918 rows selected] == /quote The correct description and sql for LEFT OUTER JOIN should be: --- --match cities to countries in Asia SELECT COUNTRIES.COUNTRY, CITIES.CITY_NAME,REGION FROM COUNTRIES LEFT OUTER JOIN CITIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE WHERE REGION='Asia'; -- use the synonymous syntax, LEFT JOIN, to achieve exactly -- the same results as in the example above SELECT COUNTRIES.COUNTRY, CITIES.CITY_NAME,REGION FROM COUNTRIES LEFT JOIN CITIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE WHERE REGION='Asia'; [Both the above queries will return COUNTRY |CITY_NAME |REGION -- Afghanistan |Kabul |Asia Bangladesh|NULL|Asia Cambodia |NULL|Asia China |Hong Kong |Asia China |Shanghai|Asia India |Bombay |Asia India |Calcutta|Asia Indonesia |Jakarta |Asia Japan |Osaka |Asia Japan |Tokyo |Asia Korea, Republic of|Seoul |Asia Malaysia |NULL|Asia Nepal |NULL|Asia Philippines |Manila |Asia Singapore |Singapore |Asia Sri Lanka |NULL|Asia Thailand |NULL|Asia Viet Nam |NULL|Asia 18 rows selected] == RIGHT OUTER JOIN: = (v10.1) http://db.apache.org/derby/docs/10.1/ref/rrefsqlj57522.html (trunk) http://db.apache.org/derby/docs/dev/ref/rrefsqlj57522.html The manual shows: quote -- get all countries and corresponding cities, including -- countries without any cities SELECT CITY_NAME, CITIES.COUNTRY FROM CITIES RIGHT OUTER JOIN COUNTRIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE; [wrong sql: Return meaningless 156 rows ] == -- get all countries in Africa and corresponding cities, including -- countries without any cities SELECT CITY_NAME, CITIES.COUNTRY FROM CITIES RIGHT OUTER JOIN COUNTRIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE; WHERE Countries.region = 'frica'; [wrong sql: 1) 'frica' is incorrect in the WHERE clause 2) incorrect results with NULL country values 3) incorrect ';' before WHERE clause] == -- use the synonymous syntax, RIGHT JOIN, to achieve exactly -- the same results as in the example above SELECT CITY_NAME, CITIES.COUNTRY FROM CITIES RIGHT JOIN COUNTRIES ON CITIES.COUNTRY_ISO_CODE = COUNTRIES.COUNTRY_ISO_CODE WHERE Countries.region = 'Africa
Re: [doc] lost pdf table of contents page numbers
Whoa,you're right Scott. I'll look into this too...Thanks for finding it... --- scott hutinger [EMAIL PROTECTED] wrote: I just noticed the the build of the current alpha page numbers has lost page numbers. I noticed this when Jeff sent out his last patch, but didn't know it went into the build this way. I can get diffs of what happened unless someone knows what happened :-) Although the pdf bookmarks are working fine (from what I see). thanks, scott
[jira] Commented: (DERBY-486) Fix Error message X0X07 in doc to match string changes in code
[ http://issues.apache.org/jira/browse/DERBY-486?page=comments#action_12362914 ] Jeff Levitt commented on DERBY-486: --- The patch looks good to me; the changes bring the error message text in the doc in line with the code change. I recommend a commit. Thanks! Fix Error message X0X07 in doc to match string changes in code -- Key: DERBY-486 URL: http://issues.apache.org/jira/browse/DERBY-486 Project: Derby Type: Sub-task Components: Documentation Environment: all Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-486.patch This is a subtask of DERBY-483 to match the string changes in the documentation. -- 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
Derby-391 and Derby-725 ready for commit
Both Derby-391 and Derby-725 are ready for commit having either received approval or have had no objections. Thanks! Jeff
Re: [jira] Commented: (DERBY-391) Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password
--- John H. Embretsen (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-391?page=comments#action_12360411 ] John H. Embretsen commented on DERBY-391: - The html files seem fine to me now - thanks for doing the changes! I'm not familiar with the DITA source format - will the ij properties reference page be updated with this patch too? http://db.apache.org/derby/docs/dev/tools/rtoolsijpropref29864.html Hi John, Yes, that list is dynamically generated. The three newly documented properties will show up on that page as links. Jeff
[jira] Updated: (DERBY-391) Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password
[ http://issues.apache.org/jira/browse/DERBY-391?page=all ] Jeff Levitt updated DERBY-391: -- Attachment: (was: rtoolsijproprefpassword.html) Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password --- Key: DERBY-391 URL: http://issues.apache.org/jira/browse/DERBY-391 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 The Tools and Utilities guide documents the ij properties. However, it does not have any documentation about the following properties ij.datasource ij.password ij.user I suggest something like this (but someone else should review): ij.dataSource Function This property allows one to specify the datasource that should be used to access the database. When specifying a datasource, Derby does *not* use the DriverManager mechanism to establish connections. For more information about DataSources, refer to the JDBC documentation and to the Derby Developer's Guide, section Using Derby as a J2EE Resource Manager. To establish a connection using ij.dataSource, you need to use additional ij.dataSource properties to set some additional properties: ij.dataSource.databaseName ij.dataSource.createDatabase Syntax ij.dataSource=datasourcename ij.dataSource.databaseName=databaseName [ij.dataSource.createDatabase=create] Example java -Dij.dataSource=org.apache.derby.jdbc.EmbeddedDataSource -Dij.dataSource.databaseName=toursDB -Dij.dataSource.createDatabase=create ij.password Function Specifies the password used to make connections with. When you connect like this, and ij creates the database, you will allways need to know that password in order to access the database, unless you set up additional users. For more information about authentication see the Derby Developer's Guide. Syntax ij.pasword=password Example java -Dij.user=me -Dij.password=mine org.apache.derby.tools.ij See also ij.user; Derby Developer's Guide - Derby and Security ij.user Function Specifies the user with which connections are made by default. When you connect like this, ij assumes that the database schema to be used is the same as the username provided. However, certain database objects cannot be created until a schema exists, i.e. until a create schema name has been issued, followed by a set schema name, or fully qualifying the database objects to be created. If no user is specified, no set schema has been issued, or create statements do not qualify the schema, all database objects are assumed to be under schema 'APP'. Syntax ij.user=username Example java -Dij.user=me -Dij.password=mine org.apache.derby.tools.ij ij version 10.1 ij set schema finance; ij select * from accounts; ij.password; Derby Developer's Guide - Derby and Security -- 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-391) Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password
[ http://issues.apache.org/jira/browse/DERBY-391?page=all ] Jeff Levitt updated DERBY-391: -- Attachment: (was: rtoolsijproprefuser.html) Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password --- Key: DERBY-391 URL: http://issues.apache.org/jira/browse/DERBY-391 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 The Tools and Utilities guide documents the ij properties. However, it does not have any documentation about the following properties ij.datasource ij.password ij.user I suggest something like this (but someone else should review): ij.dataSource Function This property allows one to specify the datasource that should be used to access the database. When specifying a datasource, Derby does *not* use the DriverManager mechanism to establish connections. For more information about DataSources, refer to the JDBC documentation and to the Derby Developer's Guide, section Using Derby as a J2EE Resource Manager. To establish a connection using ij.dataSource, you need to use additional ij.dataSource properties to set some additional properties: ij.dataSource.databaseName ij.dataSource.createDatabase Syntax ij.dataSource=datasourcename ij.dataSource.databaseName=databaseName [ij.dataSource.createDatabase=create] Example java -Dij.dataSource=org.apache.derby.jdbc.EmbeddedDataSource -Dij.dataSource.databaseName=toursDB -Dij.dataSource.createDatabase=create ij.password Function Specifies the password used to make connections with. When you connect like this, and ij creates the database, you will allways need to know that password in order to access the database, unless you set up additional users. For more information about authentication see the Derby Developer's Guide. Syntax ij.pasword=password Example java -Dij.user=me -Dij.password=mine org.apache.derby.tools.ij See also ij.user; Derby Developer's Guide - Derby and Security ij.user Function Specifies the user with which connections are made by default. When you connect like this, ij assumes that the database schema to be used is the same as the username provided. However, certain database objects cannot be created until a schema exists, i.e. until a create schema name has been issued, followed by a set schema name, or fully qualifying the database objects to be created. If no user is specified, no set schema has been issued, or create statements do not qualify the schema, all database objects are assumed to be under schema 'APP'. Syntax ij.user=username Example java -Dij.user=me -Dij.password=mine org.apache.derby.tools.ij ij version 10.1 ij set schema finance; ij select * from accounts; ij.password; Derby Developer's Guide - Derby and Security -- 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-391) Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password
[ http://issues.apache.org/jira/browse/DERBY-391?page=all ] Jeff Levitt updated DERBY-391: -- Attachment: derby391firsthalf.diff Here's the patch! Tools and Utilities guide does not document ij.datasource, ij.user, nor ij.password --- Key: DERBY-391 URL: http://issues.apache.org/jira/browse/DERBY-391 Project: Derby Type: Improvement Components: Documentation Versions: 10.1.1.0 Reporter: Myrna van Lunteren Priority: Minor Fix For: 10.2.0.0 Attachments: derby391firsthalf.diff, rtoolsijproprefdatasource.html, rtoolsijproprefpassword.html, rtoolsijproprefuser.html The Tools and Utilities guide documents the ij properties. However, it does not have any documentation about the following properties ij.datasource ij.password ij.user I suggest something like this (but someone else should review): ij.dataSource Function This property allows one to specify the datasource that should be used to access the database. When specifying a datasource, Derby does *not* use the DriverManager mechanism to establish connections. For more information about DataSources, refer to the JDBC documentation and to the Derby Developer's Guide, section Using Derby as a J2EE Resource Manager. To establish a connection using ij.dataSource, you need to use additional ij.dataSource properties to set some additional properties: ij.dataSource.databaseName ij.dataSource.createDatabase Syntax ij.dataSource=datasourcename ij.dataSource.databaseName=databaseName [ij.dataSource.createDatabase=create] Example java -Dij.dataSource=org.apache.derby.jdbc.EmbeddedDataSource -Dij.dataSource.databaseName=toursDB -Dij.dataSource.createDatabase=create ij.password Function Specifies the password used to make connections with. When you connect like this, and ij creates the database, you will allways need to know that password in order to access the database, unless you set up additional users. For more information about authentication see the Derby Developer's Guide. Syntax ij.pasword=password Example java -Dij.user=me -Dij.password=mine org.apache.derby.tools.ij See also ij.user; Derby Developer's Guide - Derby and Security ij.user Function Specifies the user with which connections are made by default. When you connect like this, ij assumes that the database schema to be used is the same as the username provided. However, certain database objects cannot be created until a schema exists, i.e. until a create schema name has been issued, followed by a set schema name, or fully qualifying the database objects to be created. If no user is specified, no set schema has been issued, or create statements do not qualify the schema, all database objects are assumed to be under schema 'APP'. Syntax ij.user=username Example java -Dij.user=me -Dij.password=mine org.apache.derby.tools.ij ij version 10.1 ij set schema finance; ij select * from accounts; ij.password; Derby Developer's Guide - Derby and Security -- 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-725) NULLIF and CASE expressions section in reference manual contains two stale paragraphs.
[ http://issues.apache.org/jira/browse/DERBY-725?page=all ] Jeff Levitt updated DERBY-725: -- Attachment: derby725.diff rrefcasenullif.html Attached patch removes the two paragraphs as requested. HTML output included for review... NULLIF and CASE expressions section in reference manual contains two stale paragraphs. -- Key: DERBY-725 URL: http://issues.apache.org/jira/browse/DERBY-725 Project: Derby Type: Bug Components: Documentation Versions: 10.1.2.1 Reporter: Daniel John Debrunner Priority: Trivial Attachments: derby725.diff, rrefcasenullif.html The two paragraphs below from 10.1 ref manual, page 78 in pdf can be removed. You do not need to use the CASE expression for avoiding NullPointerExceptions when a nullable column becomes a method receiver. If the value of the instance specified in an instance method invocation is null, the result of the invocation is null (SQL NULL). However, you still might need to use the CASE expression for when a nullable column is a primitive method parameter. -- 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
Derby-391
Hi all, Derby-391 has a comment in it that I'd like to separate out into a new issue. http://issues.apache.org/jira/browse/DERBY-391 John Embretsen writes: I believe the following boolean ij properties are not mentioned in the documentation (tools guide) either: ij.showNoConnectionsAtStart ij.showNoCountForSelect (I noticed that these properties are used in trunk/java/tools/org/apache/derby/impl/tools/ij/utilMain.java) I would like to create a new JIRA issue and place John's comment there, because I do not have enough information yet to create the documentation for those properties. However, I do have enough to create documentation for the first three properties mentioned in this issue, and I would like to submit a patch to add those and resolve this issue if approved. This way, the patch does not get held up. Does anyone have any objections to that? John? If not, I'll create the new issue, add a comment to it asking for more info (that I can use very soon to add docs for if someone provides that info) and then add a comment to this issue referring to the new one. Finally, I can submit a patch for this issue :)
