NAME
    SQL::SplitStatement - Split any SQL code into atomic statements

VERSION
    Version 0.05001

SYNOPSIS
        my $sql_code = <<'SQL';
        CREATE TABLE parent(a, b, c   , d    );
        CREATE TABLE child (x, y, "w;", "z;z");
        /* C-style comment; */
        CREATE TRIGGER "check;delete;parent;" BEFORE DELETE ON parent WHEN
            EXISTS (SELECT 1 FROM child WHERE old.a = x AND old.b = y)
        BEGIN
            SELECT RAISE(ABORT, 'constraint failed;'); -- Inlined SQL comment
        END;
        -- Standalone SQL; comment; with semicolons;
        INSERT INTO parent (a, b, c, d) VALUES ('pippo;', 'pluto;', NULL, NULL);
        SQL

        use SQL::SplitStatement;

        my $sql_splitter = SQL::SplitStatement->new;
        my @statements = $sql_splitter->split($sql_code);

        # @statements now is:
        #
        # (
        #     'CREATE TABLE parent(a, b, c   , d    )',
        #     'CREATE TABLE child (x, y, "w;", "z;z")',
        #     'CREATE TRIGGER "check;delete;parent;" BEFORE DELETE ON parent WHEN
        #     EXISTS (SELECT 1 FROM child WHERE old.a = x AND old.b = y)
        # BEGIN
        #     SELECT RAISE(ABORT, \'constraint failed;\');
        # END',
        #     'INSERT INTO parent (a, b, c, d) VALUES (\'pippo;\', \'pluto;\', NULL, NULL)'
        # )

DESCRIPTION
    This is a simple module which tries to split any SQL code (even when
    containing procedural extensions) into the atomic statements it is
    composed of.

    The logic used to split the SQL code is more sophisticated than a raw
    "split" on the *statement terminator token*, so that SQL::SplitStatement
    is able to correctly handle the presence of said token inside
    identifiers, values, comments, "BEGIN ... END" blocks (even nested) and
    procedural code, as (partially) exemplified in the synopsis above (see
    also the "LIMITATIONS" section below).

    Consider however that this is by no mean a validating parser: it
    requests its input to be syntactically valid SQL, otherwise it can
    return unusable statements (that shouldn't be a problem though, as the
    original SQL code would have been unusable anyway).

    If the given SQL code is valid, it is guaranteed however that it will be
    split correctly (otherwise it is a bug, that will be corrected, once
    reported).

    If your atomic statements are to be fed to a DBMS, you are encouraged to
    use DBIx::MultiStatementDo instead, which uses this module and also
    (optionally) offers automatic transactions support, so that you'll have
    the *all-or-nothing* behavior you would probably want.

METHODS
  "new"
    *   "SQL::SplitStatement->new( \%options )"

    It creates and returns a new SQL::SplitStatement object. It accepts its
    options either as a hash or a hashref.

    "new" takes the following Boolean options, which all default to false.

    *   "keep_semicolon"

        WARNING! This option (and its getter/set method) is now deprecated
        and it will be removed in some future version. It has been renamed
        to: "keep_terminator", so please use that instead. Currently any
        value assigned to "keep_semicolon" is assigned to "keep_terminator".

    *   "keep_terminator"

        A Boolean option which causes, when set to a false value (which is
        the default), the trailing terminator token to be discarded in the
        returned atomic statements. When set to a true value, the
        terminators are kept instead.

        If your statements are to be fed to a DBMS, you are advised to keep
        this option to its default (false) value, since some drivers/DBMS
        don't want the terminator to be present at the end of the (single)
        statement.

        The strings currently recognized as terminator tokens are:

        *   ";" (the *semicolon* character)

        *   "/" (the *forward-slash* character)

        *   a semicolon followed by a forward-slash on its own line

            This latter string is treated as a single token (it is used to
            terminate PL/SQL procedures).

        (Note that the last, possibly empty, statement of a given SQL text,
        never has a trailing terminator. See below for an example.)

    *   "keep_extra_spaces"

        A Boolean option which causes, when set to a false value (which is
        the default), the spaces ("\s") around the statements to be trimmed.
        When set to a true value, these spaces are kept instead.

        When "keep_terminator" is set to false as well, the terminator is
        discarded first (regardless of the spaces around it) and the
        trailing spaces are trimmed then. This ensures that if
        "keep_extra_spaces" is set to false, the returned statements will
        never have trailing (nor leading) spaces, regardless of the
        "keep_terminator" value.

    *   "keep_comments"

        A Boolean option which causes, when set to a false value (which is
        the default), the comments to be discarded in the returned
        statements. When set to a true value, they are kept with the
        statements instead.

        Both SQL and multi-line C-style comments are recognized.

        When kept, each comment is returned in the same string with the
        atomic statement it belongs to. A comment belongs to a statement if
        it appears, in the original SQL code, before the end of that
        statement and after the terminator of the previous statement (if it
        exists), as shown in this meta-SQL snippet:

            /* This comment
            will be returned
            with statement1 */
            <statement1>; -- This will go with statement2
                          -- (note the semicolon which closes statement1)

            <statement2>
            -- This with statement2 as well

    *   "keep_empty_statements"

        A Boolean option which causes, when set to a false value (which is
        the default), the empty statements to be discarded. When set to a
        true value, the empty statements are returned instead.

        A statement is considered empty when it contains no character other
        than the terminator and space characters ("\s").

        A statement composed solely of comments is not recognized as empty
        and may therefore be returned even when "keep_empty_statements" is
        false. To avoid this, it is sufficient to leave "keep_comments" to
        false as well.

        Note instead that an empty statement is recognized as such
        regardless of the value of the options "keep_terminator" and
        "keep_extra_spaces".

    These options are basically to be kept to their default (false) values,
    especially if the atomic statements are to be given to a DBMS.

    They are intended mainly for *cosmetic* reasons, or if you want to count
    by how many atomic statements, including the empty ones, your original
    SQL code was composed of.

    Another situation where they are useful (in the general case necessary,
    really), is when you want to retain the ability to verbatim rebuild the
    original SQL string from the returned statements:

        my $verbatim_splitter = SQL::SplitStatement->new(
            keep_terminator       => 1,
            keep_extra_spaces     => 1,
            keep_comments         => 1,
            keep_empty_statements => 1
        );

        my @verbatim_statements = $verbatim_splitter->split($sql_string);

        $sql eq join '', @verbatim_statements; # Always true, given the constructor above.

    Other than this, again, you are highly recommended to stick with the
    defaults.

  "split"
    *   "$sql_splitter->split( $sql_string )"

    This is the method which actually splits the SQL code into its atomic
    components.

    It returns a list containing the atomic statements, in the same order
    they appear in the original SQL code. The atomic statements are returned
    according to the options explained above.

    Note that, as mentioned above, an SQL string which terminates with a
    terminator token (for example a semicolon), contains a trailing empty
    statement: this is correct and it is treated accordingly (if
    "keep_empty_statements" is set to a true value):

        my $sql_splitter = SQL::SplitStatement->new(
            keep_empty_statements => 1
        );

        my @statements = $sql_splitter->split( 'SELECT 1;' );

        print 'The SQL code contains ' . scalar(@statements) . ' statements.';
        # The SQL code contains 2 statements.

  "split_with_placeholders"
    *   "$sql_splitter->split_with_placeholders( $sql_string )"

    It works exactly as the "split" method explained above, except that it
    returns also a list of integers, each of which is the number of the
    (*unnamed*) *placeholders* (aka *parameter markers* - represented by the
    "?" character) contained in the corresponding atomic statements.

    Its return value is a list of two elemnts: the first one is a reference
    to the list of the atomic statements (exactly as returned by the "split"
    method), and the second is a reference to the list of the numbers of
    placeholders as explained above.

    Here is an example:

        # 4 statements (valid SQLite SQL)
        my $sql_code = <<'SQL';
        CREATE TABLE state (id, name);
        INSERT INTO  state (id, name) VALUES (?, ?);
        CREATE TABLE city  (id, name, state_id);
        INSERT INTO  city  (id, name, state_id) VALUES (?, ?, ?)
        SQL

        my $splitter = SQL::SplitStatement->new;

        my ( $statements, $placeholders )
            = $splitter->split_with_placeholders( $sql_code );

        # $placeholders is [0, 2, 0, 3]

    where the returned $placeholders list(ref) is to be read as follows: the
    first statement has 0 placeholders, the second 2, the third 0, the
    fourth 3.

  "keep_terminator"
    *   "$sql_splitter->keep_terminator"

    *   "$sql_splitter->keep_terminator( $boolean )"

        Getter/setter method for the "keep_terminator" option explained
        above.

  "keep_extra_spaces"
    *   "$sql_splitter->keep_extra_spaces"

    *   "$sql_splitter->keep_extra_spaces( $boolean )"

        Getter/setter method for the "keep_extra_spaces" option explained
        above.

  "keep_comments"
    *   "$sql_splitter->keep_comments"

    *   "$sql_splitter->keep_comments( $boolean )"

        Getter/setter method for the "keep_comments" option explained above.

  "keep_empty_statements"
    *   "$sql_splitter->keep_empty_statements"

    *   "$sql_splitter->keep_empty_statements( $boolean )"

        Getter/setter method for the "keep_empty_statements" option
        explained above.

LIMITATIONS
    The only procedural code currently recognized is PL/SQL, that is, blocks
    of code which start with a "DECLARE", a "CREATE" or *anonymous* "BEGIN
    ... END" blocks.

    If you need also other procedural languages to be recognized, please let
    me know (possibly attaching test cases).

DEPENDENCIES
    SQL::SplitStatement depends on the following modules:

    *   Moose

    *   List::MoreUtils

    *   SQL::Tokenizer

AUTHOR
    Emanuele Zeppieri, "<emazep@cpan.org>"

BUGS
    Please report any bugs or feature requests to "bug-sql-SplitStatement at
    rt.cpan.org", or through the web interface at
    <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=SQL-SplitStatement>. I
    will be notified, and then you'll automatically be notified of progress
    on your bug as I make changes.

SUPPORT
    You can find documentation for this module with the perldoc command.

        perldoc SQL::SplitStatement

    You can also look for information at:

    *   RT: CPAN's request tracker

        <http://rt.cpan.org/NoAuth/Bugs.html?Dist=SQL-SplitStatement>

    *   AnnoCPAN: Annotated CPAN documentation

        <http://annocpan.org/dist/SQL-SplitStatement>

    *   CPAN Ratings

        <http://cpanratings.perl.org/d/SQL-SplitStatement>

    *   Search CPAN

        <http://search.cpan.org/dist/SQL-SplitStatement/>

ACKNOWLEDGEMENTS
    Igor Sutton for his excellent SQL::Tokenizer, which made writing this
    module a joke.

SEE ALSO
    *   DBIx::MultiStatementDo

LICENSE AND COPYRIGHT
    Copyright 2010 Emanuele Zeppieri.

    This program is free software; you can redistribute it and/or modify it
    under the terms of either: the GNU General Public License as published
    by the Free Software Foundation, or the Artistic License.

    See http://dev.perl.org/licenses/ for more information.

