Derby
  1. Derby
  2. DERBY-5690

Give users a way to run an ij script programmatically so they can filter errors.

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: None
    • Component/s: Tools
    • Labels:
      None

      Description

      Sometimes users need a way to run an ij script programmatically and handle the errors. It would be nice if they could use ij's StatementFinder to parse a semi-colon delimited file of sql statements, throwing away comments. StatementFinder itself can't be used because it is not part of the public api and it has some small dependencies on other Derby code. I will attach a standalone class which applications can use.

      1. SQLRunner.java
        4 kB
        Rick Hillegas
      2. StatementReader.java
        0.5 kB
        Rick Hillegas

        Activity

        Hide
        Rick Hillegas added a comment -

        Attaching StatementReader.java. This class can be used to parse a batch of sql statements the way that ij does. You construct an instance of this class from an InputStream (e.g., a FileInputStream created from your statement batch) and then you loop, calling StatementReader.nextStatement() to drain the batch. Each nextStatement() call returns a single statement. The final call returns null.

        Show
        Rick Hillegas added a comment - Attaching StatementReader.java. This class can be used to parse a batch of sql statements the way that ij does. You construct an instance of this class from an InputStream (e.g., a FileInputStream created from your statement batch) and then you loop, calling StatementReader.nextStatement() to drain the batch. Each nextStatement() call returns a single statement. The final call returns null.
        Hide
        Dag H. Wanvik added a comment -

        Doesn't the StatementFinder class in ij take two arguments in its constructor?

        Show
        Dag H. Wanvik added a comment - Doesn't the StatementFinder class in ij take two arguments in its constructor?
        Hide
        Rick Hillegas added a comment -

        Hi Dag,

        Yes, StatementFinder has different constructors. Getting rid of those constructors is a large part of what you need to do in order to break the dependency on Derby internals and expose this useful functionality to end-users. Thanks.

        Show
        Rick Hillegas added a comment - Hi Dag, Yes, StatementFinder has different constructors. Getting rid of those constructors is a large part of what you need to do in order to break the dependency on Derby internals and expose this useful functionality to end-users. Thanks.
        Hide
        Rick Hillegas added a comment -

        Note that I am advocating the use of StatementReader by applications, not StatementFinder. Thanks.

        Show
        Rick Hillegas added a comment - Note that I am advocating the use of StatementReader by applications, not StatementFinder. Thanks.
        Hide
        Rick Hillegas added a comment -

        Attaching SQLRunner.java. This program shows how to use StatementReader to loop through a batch of SQL statements, exiting with error code 1 as soon as an error occurs.

        Here is the usage diagnostic from this program:

        USAGE:

        java SQLRunner connectionURL scriptName

        E.g.:

        java SQLRunner "jdbc:derby:memory:db;create=true" "/Users/me/sql/w.sql"

        Show
        Rick Hillegas added a comment - Attaching SQLRunner.java. This program shows how to use StatementReader to loop through a batch of SQL statements, exiting with error code 1 as soon as an error occurs. Here is the usage diagnostic from this program: USAGE: java SQLRunner connectionURL scriptName E.g.: java SQLRunner "jdbc:derby:memory:db;create=true" "/Users/me/sql/w.sql"
        Hide
        Kim Haase added a comment -

        Would it be helpful to make one or both of these a documented Derby tool?

        Show
        Kim Haase added a comment - Would it be helpful to make one or both of these a documented Derby tool?
        Hide
        Rick Hillegas added a comment -

        Hi Kim. Since the need for StatementReader has come up a couple times, it might make sense to move it to org.apache.derby.tools, add it to the public api, and document it as you suggest. There's a lot of overlap with StatementFinder, so we would probably want to refactor the two classes to eliminate the overlap. Sounds like a pleasant afternoon's work. Thanks.

        Show
        Rick Hillegas added a comment - Hi Kim. Since the need for StatementReader has come up a couple times, it might make sense to move it to org.apache.derby.tools, add it to the public api, and document it as you suggest. There's a lot of overlap with StatementFinder, so we would probably want to refactor the two classes to eliminate the overlap. Sounds like a pleasant afternoon's work. Thanks.

          People

          • Assignee:
            Unassigned
            Reporter:
            Rick Hillegas
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development