Derby
  1. Derby
  2. DERBY-2255

ij should indicate that it is waiting for more input in a multi-line interactive statement.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 10.2.2.0
    • Fix Version/s: 10.4.1.3
    • Component/s: Tools
    • Labels:
      None

      Description

      Many users have been confused by the lack of response from ij when they forget to end a statement with a semicolon, and believe that Derby is taking its sweet time answering their query, while ij is simply waiting for more input.

      This issue tries to address this by adding a short "> " prompt to the next line after a newline has been entered by the user without ending the statement with a semicolon.

      1. DERBY-2255_4.diff
        5 kB
        Myrna van Lunteren
      2. DERBY-2255_6.diff
        6 kB
        Myrna van Lunteren
      3. DERBY-2255-1.diff
        5 kB
        Anders Morken
      4. DERBY-2255-2.diff
        5 kB
        Anders Morken
      5. derby-2255-3.diff
        5 kB
        Andrew McIntyre

        Issue Links

          Activity

          Hide
          Anders Morken added a comment -

          DERBY-2255-1.diff is a first stab at adding "line continuation prompts" to interactive ij sessions. Probably needs a little kicking, reviews and testing on more platforms than Linux would be appreciated. I'm a bit worried about the difference between line breaks between platforms. =)

          StatementFinder.java | 42 +++++++++++++++++++++++++++++++++++++++---
          utilMain.java | 12 +++++++-----
          2 files changed, 46 insertions, 8 deletions

          Show
          Anders Morken added a comment - DERBY-2255 -1.diff is a first stab at adding "line continuation prompts" to interactive ij sessions. Probably needs a little kicking, reviews and testing on more platforms than Linux would be appreciated. I'm a bit worried about the difference between line breaks between platforms. =) StatementFinder.java | 42 +++++++++++++++++++++++++++++++++++++++--- utilMain.java | 12 +++++++----- 2 files changed, 46 insertions , 8 deletions
          Hide
          John H. Embretsen added a comment -

          I tried the patch on Windows XP. I get two continuation "prompts" instead of one:

          ij version 10.3
          ij> connect 'jdbc:derby:mydb;create=true';
          ij> create table test
          > > (a int);
          0 rows inserted/updated/deleted
          ij> create table
          > > test2
          > > (b int);
          0 rows inserted/updated/deleted
          ij>

          But it is still useful

          Show
          John H. Embretsen added a comment - I tried the patch on Windows XP. I get two continuation "prompts" instead of one: ij version 10.3 ij> connect 'jdbc:derby:mydb;create=true'; ij> create table test > > (a int); 0 rows inserted/updated/deleted ij> create table > > test2 > > (b int); 0 rows inserted/updated/deleted ij> But it is still useful
          Hide
          Bernt M. Johnsen added a comment -

          Works like a charm in Emacs on Linux in my IJ minor mode (in SQLi major mode). Works with multiple connections too.

          Show
          Bernt M. Johnsen added a comment - Works like a charm in Emacs on Linux in my IJ minor mode (in SQLi major mode). Works with multiple connections too.
          Hide
          Anders Morken added a comment -

          DERBY-2255-2.diff is a revised patch, which tries to avoid double continuation prompts by swallowing the LF after CR in DOS/Windows line separators (CRLF). It appears to work on Linux and Windows now - are there any Mac users out there who can verify that this works for them as well? =)

          Show
          Anders Morken added a comment - DERBY-2255 -2.diff is a revised patch, which tries to avoid double continuation prompts by swallowing the LF after CR in DOS/Windows line separators (CRLF). It appears to work on Linux and Windows now - are there any Mac users out there who can verify that this works for them as well? =)
          Hide
          Anders Morken added a comment -

          Oh, and yeah, derbyall seemed to run just fine, and here's the diffstat:

          StatementFinder.java | 52 +++++++++++++++++++++++++++++++++++++++++++++++++--
          utilMain.java | 8 ++++---
          2 files changed, 55 insertions, 5 deletions

          Show
          Anders Morken added a comment - Oh, and yeah, derbyall seemed to run just fine, and here's the diffstat: StatementFinder.java | 52 +++++++++++++++++++++++++++++++++++++++++++++++++-- utilMain.java | 8 ++++--- 2 files changed, 55 insertions , 5 deletions
          Hide
          Jean T. Anderson added a comment -

          This worked fine for me on max osx (10.4).

          It doesn't catch a carriage return inside a quote (and I'd argue it really shouldn't because a carriage return could be part of the data). For example, here's a query with a properly closed quote:

          ij> select
          > *
          > from
          > bar
          > where
          > description =
          > 'here is row 2';
          ID |DESCRIPTION
          --------------------------------
          2 |here is row 2

          1 row selected

          And here's a query without a close quote before the semicolon:

          ij> select *
          > from bar
          > where description='here is row 3;
          === hangs here with no continuation prompt ===

          I think users might still be confused – but hopefully less confused because they can see the continuation prompt on the preceding lines.

          Show
          Jean T. Anderson added a comment - This worked fine for me on max osx (10.4). It doesn't catch a carriage return inside a quote (and I'd argue it really shouldn't because a carriage return could be part of the data). For example, here's a query with a properly closed quote: ij> select > * > from > bar > where > description = > 'here is row 2'; ID |DESCRIPTION -------------------------------- 2 |here is row 2 1 row selected And here's a query without a close quote before the semicolon: ij> select * > from bar > where description='here is row 3; === hangs here with no continuation prompt === I think users might still be confused – but hopefully less confused because they can see the continuation prompt on the preceding lines.
          Hide
          Andrew McIntyre added a comment -

          The changes in derby-2255-2.diff look good, though I found an issue with the change to readSingleLineComment(). With the derby-2255-2 patch, if you begin a – comment in an interactive ij session, it is impossible to get out of the comment, at least on Mac OS X and I suspect Linux (haven't tried on Windows yet).

          There is something subtle going on with the input stream and prompting, because if I remove the single line:

          utilMain.doPrompt(false, promptwriter, "");

          from readSingleLineComment then it behaves as I would suspect: comments are consumed up to the newline and normal processing is resumed. Originally I removed this line from readSingleLineComment() because we don't want to prompt after consuming the contents of a single line comment, we want to continue normal statement processing. I was surprised that just removing the prompt fixed the problem of being stuck in comment-mode though.

          Attaching a patch which includes the previously mentioned change, along with some improved comments. I would appreciate it if any interested parties could review the new and old patches and perhaps look into the unusual comment behavior.

          Show
          Andrew McIntyre added a comment - The changes in derby-2255-2.diff look good, though I found an issue with the change to readSingleLineComment(). With the derby-2255-2 patch, if you begin a – comment in an interactive ij session, it is impossible to get out of the comment, at least on Mac OS X and I suspect Linux (haven't tried on Windows yet). There is something subtle going on with the input stream and prompting, because if I remove the single line: utilMain.doPrompt(false, promptwriter, ""); from readSingleLineComment then it behaves as I would suspect: comments are consumed up to the newline and normal processing is resumed. Originally I removed this line from readSingleLineComment() because we don't want to prompt after consuming the contents of a single line comment, we want to continue normal statement processing. I was surprised that just removing the prompt fixed the problem of being stuck in comment-mode though. Attaching a patch which includes the previously mentioned change, along with some improved comments. I would appreciate it if any interested parties could review the new and old patches and perhaps look into the unusual comment behavior.
          Hide
          Myrna van Lunteren added a comment -

          I refreshed the patch (because various changes have gone in to utilMain since the last posting), then tried the two versions of StatementFinder.readSingleLineComment (as per attachements _2 and _3.diff).

          But I found strange behavior with the code of _3.diff; a commented line, (i.e. starting with --) followed by a return, would result in a line without a prompt.
          Hitting return again, would give me a prompt again and I could go on...

          When I used the code of _2.diff I saw no such problem; no 'getting stuck' in comment mode...

          I have no access to a Mac, is there someone who does & can reconfirm this patch?

          Show
          Myrna van Lunteren added a comment - I refreshed the patch (because various changes have gone in to utilMain since the last posting), then tried the two versions of StatementFinder.readSingleLineComment (as per attachements _2 and _3.diff). But I found strange behavior with the code of _3.diff; a commented line, (i.e. starting with --) followed by a return, would result in a line without a prompt. Hitting return again, would give me a prompt again and I could go on... When I used the code of _2.diff I saw no such problem; no 'getting stuck' in comment mode... I have no access to a Mac, is there someone who does & can reconfirm this patch?
          Hide
          Myrna van Lunteren added a comment -

          Attaching another patch.

          This patch tries to figure out if a singlelinecomment just read is actually part of a statement started earlier.
          If it is, it prints the continuation prompt ('>'). If it is not part of a statement it prints the ij prompt ('ij>').

          I had alternatively thought of not providing any prompt after a single line comment, but I found myself wondering what ij was up to (we now get a prompt in all other situations).

          If someone could review this and indicate if this is acceptable?

          My one concern is that normally, if you start a second named connection for example, 'as me', the prompt turns into: ij (me)> for a new statement, instead of ij>.
          Before the first patch, the next line would not get a prompt.
          Now, (as with the first patch) you will see a > prompt, or (this patch) if the statement was a single line comment, you will see an ij> prompt on the next line. That is, you will not see the named connection.

          I've run a number of tests, but it seems our tests are not affected by this...So, only interactively do you see a difference. I can not imagine how that could break anyone's application.

          The only incompatibility I can think of is that if before you used to try out a statement interactively and then cut-and-paste into a script, you may now have to remove some prompt characters...

          Show
          Myrna van Lunteren added a comment - Attaching another patch. This patch tries to figure out if a singlelinecomment just read is actually part of a statement started earlier. If it is, it prints the continuation prompt ('>'). If it is not part of a statement it prints the ij prompt ('ij>'). I had alternatively thought of not providing any prompt after a single line comment, but I found myself wondering what ij was up to (we now get a prompt in all other situations). If someone could review this and indicate if this is acceptable? My one concern is that normally, if you start a second named connection for example, 'as me', the prompt turns into: ij (me)> for a new statement, instead of ij>. Before the first patch, the next line would not get a prompt. Now, (as with the first patch) you will see a > prompt, or (this patch) if the statement was a single line comment, you will see an ij> prompt on the next line. That is, you will not see the named connection. I've run a number of tests, but it seems our tests are not affected by this...So, only interactively do you see a difference. I can not imagine how that could break anyone's application. The only incompatibility I can think of is that if before you used to try out a statement interactively and then cut-and-paste into a script, you may now have to remove some prompt characters...
          Hide
          Dyre Tjeldvoll added a comment -

          IMHO it would be good to commit this patch, and let our esteemed Mac users report any problems that may surface. If those problems can't be easily fixed one can always back out the change.

          Show
          Dyre Tjeldvoll added a comment - IMHO it would be good to commit this patch, and let our esteemed Mac users report any problems that may surface. If those problems can't be easily fixed one can always back out the change.
          Hide
          Knut Anders Hatlen added a comment -

          +1

          This patch has waited too long already. Judging by the interest till now, it doesn't seem likely that we'll get more testing of it until it has been committed. And as you say, if there are problems that are too difficult to fix, we can always back it out.

          Show
          Knut Anders Hatlen added a comment - +1 This patch has waited too long already. Judging by the interest till now, it doesn't seem likely that we'll get more testing of it until it has been committed. And as you say, if there are problems that are too difficult to fix, we can always back it out.
          Hide
          Andrew McIntyre added a comment -

          Checked with the _6 patch and the current Mac OS JVMs and was unable to reproduce the previous behavior that I had noted, where semicolons were no longer accepted a statement and it was impossible to get out of comment mode.

          +1 to commit.

          Show
          Andrew McIntyre added a comment - Checked with the _6 patch and the current Mac OS JVMs and was unable to reproduce the previous behavior that I had noted, where semicolons were no longer accepted a statement and it was impossible to get out of comment mode. +1 to commit.
          Hide
          Myrna van Lunteren added a comment -

          I intend to do some verifications and then commit.

          Show
          Myrna van Lunteren added a comment - I intend to do some verifications and then commit.
          Hide
          Myrna van Lunteren added a comment -

          I committed this with revision 592500. Thx, Anders, for the work, and thx Dyre, Knut Anders and Andrew for your review.

          Show
          Myrna van Lunteren added a comment - I committed this with revision 592500. Thx, Anders, for the work, and thx Dyre, Knut Anders and Andrew for your review.
          Hide
          Martin Zaun added a comment -

          I noticed that the continutation marker is not shown when just hitting Enter (or any whitespace followed by Enter) until a semicolon terminates the "query":

          ij version 10.5
          ij>

          ;
          ij>

          Contrast this with the Bash shell's behaviour, which shows a marker as long as the line's being continued:

          MD@sunny ~/derby/trunk
          $ \
          > \
          > \
          >

          My preference: ij should display a continuation marker until the terminating semicolon, regardless of what's been typed so far or not.

          Martin

          Show
          Martin Zaun added a comment - I noticed that the continutation marker is not shown when just hitting Enter (or any whitespace followed by Enter) until a semicolon terminates the "query": ij version 10.5 ij> ; ij> Contrast this with the Bash shell's behaviour, which shows a marker as long as the line's being continued: MD@sunny ~/derby/trunk $ \ > \ > \ > My preference: ij should display a continuation marker until the terminating semicolon, regardless of what's been typed so far or not. Martin
          Hide
          Myrna van Lunteren added a comment -

          I admit, I never considered the 'empty' command.
          I'd consider adjusting that a further improvement, but would suggest a new bug, leaving this bug as fixed.

          Show
          Myrna van Lunteren added a comment - I admit, I never considered the 'empty' command. I'd consider adjusting that a further improvement, but would suggest a new bug, leaving this bug as fixed.

            People

            • Assignee:
              Anders Morken
              Reporter:
              Anders Morken
            • Votes:
              2 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development