NAME

       SQL::Statement::Roadmap - Planned Enhancements for SQL::Statement and SQL::Parser

       Jens Rehsack - June 2010

SYNOPSIS

       This document gives a high level overview of the future of SQL::Statement, SQL::Parser and its impact.

       The planned enhancements cover testing, performance, reliability, extensibility and more.

CHANGES AND ENHANCEMENTS

   Enhancements in SQL::Statement 1.xx
       SQL::Statement 1.xx will not receive big changes, but a few enhancements may help us to design
       SQL::Statement 2.xx much better.

       CREATE and DROP of FUNCTION, KEYWORD, OPERATOR, TYPE

       SQL::Statement is missing some functions, types, operators etc. It's supported to add missing
       functionality - but the implementation wasn't picked up during the modernizing of column evaluation. See
       RT#52397 for some more information.

       This should be done before SQL::Statement 1.xx reaches the end of its road.

       Parser improvements

       The SQL::Parser is implemented based on a lot of regular expressions and some manually developed logic.
       This creates some issues like RT#53416 or RT#55190. Further, trailing ";" causes SQL::Parser to croak. We
       need to decide what can be fixed without internal design changes and what has to wait.

       Performance

       There is no intention to work on performance improvements in SQL::Statement 1.xx. The performance is good
       as it is and improvement requires design changes.

       Reliability

       Bugs will be fixed - where possible. SQL::Statement 1.28 is much more reliable than SQL::Statement 1.15.
       Even if a bug cannot be fixed all issues are gratefully received as they will be considered in the design
       process for SQL::Statement 2.xx better.

       Extensibility

       SQL::Statement 1.xx is highly extensible, even if a more object oriented design would improve that. The
       1.xx branch will not be redesigned for greater extensibility on a coding level.

   Enhancements in SQL::Statement 2.xx
       Concerning the procedural design of SQL::Statement 1.xx a rewrite of the basic components is required.

       SQL::Parser rewrite

       The SQL::Parser needs to be modified to be able to use a Backus Naur Form
       <http://en.wikipedia.org/wiki/Backus_Naur_Form>.  This would allow users and developers to rely on many
       different SQL dialects.  This will allow better extensibility from a feature point of view without losing
       ANSI SQL compatibility.

       SQL::Statement rewrite

       SQL::Statement should be reduced to a simple coordinating engine. The executing tasks should be organized
       into separated commands. This will reduce side effects and will open the door for higher level
       optimizations, reliability improvements or sub-selects (or other calculated tables).

       Features

       There is a large list of missing features but not all table backends will be able to support each new
       feature. The most popular requested features need additional discussion and everyone is welcome to do it
       on the mailto:dbi-dev@perl.org.

       LOCK TABLE

       Locking table within SQL scripts to manually control table consistence over several operations. The
       current locking support is restricted to one statement.

       Transaction support

       Executing statements on a temporary copy of the table data.

       The easiest way to implement this would be to create a SQL::Statement::RAM on "BEGIN TRANSACTION" and
       write the entire table back on "COMMIT" or discard on "ROLLBACK".

       Better performance could be achieved in cases where the implementation is enabled to memorize pending
       modifications and apply them at "COMMIT".  On the other hand there are already capabilities to improve
       some operations, which might create confusion in case of transactions.

       This needs more discussion.

       ALTER TABLE

       Adding, removing or modifying columns is not supported for created tables. A generic "ALTER TABLE" seems
       to rely on the implementation of the transaction support - until better ideas are provided.

       Indices

       Currently some table backends have implicit support to access specified rows quicker than fetching each
       row and evaluating the where clause against the row data.

       An interface would be required to configure fetching to return only rows matching a restricted where
       clause. Another (probably better) way to support indices would be to fetch index entries at first and
       have an interface to the table fetching lines based on an index key.

       Sub-Selects

       In most cases queries can be re-expressed without using sub-selects. But in any case, there are
       circumstances where sub-selects are required.

       The first implementation will do the sub-select before the primary statement is executed without any
       further optimization. Hopefully a later version will provide better Performance with some optimization.

       Query based variables

       Currently the only variable I can imagine is "ROWNUM". More suggestions are very welcome.

       Better SQL Script support

       In SQL::Statement 1.xx the function "RUN ()" provides SQL script execution. This function may have
       limitations and side effects (at least when the executed SQL touched the same tables as the primary
       statement).

       I plan to improve the SQL script support to remove the side effects on the one hand and have a more
       flexible and easier way to execute them.

       Finally it should be possible to execute a script via:

           $dbh->do( join( ";", @script ) );

       Trigger support

       Most important when doing complicated things is having callback functions for several events. While real
       triggers will not be possible for SQL::Statement and underlying pseudo-databases, callbacks could be
       provided via triggers.

       Performance

       There are several performance optimizations required for SQL::Statement 2.xx.

       The first one should be done on a very high level (query optimization) by implementing algebraic
       evaluation of queries and clean implementation of typical database algorithms. With respect to the basic
       optimization rule premature optimization is the root of all evil, it is primarily targeted to have an
       adequately fast, reliable implementation of many algorithms (e.g. early incomplete evaluation to reduce
       amount of rows, transpose where clause to evaluate constants first) and a clever controller choosing the
       right algorithm for a specific query.

       The second optimization goal means: implementing most expensive methods in XS. This requires a good
       performance test suite as well as some real world useage cases.

       Reliability

       This is one of the primary goals of SQL::Statement. I hope to reach it using test driven development and
       I hope I get some more todo's from the users for this.

       Extensibility

       The currently high level of extensibility should be increased on a coding level. This will be done by
       redesigning the entire parser and execution engine using object oriented techniques and design patterns.

       Testing

       Many tests in SQL::Statement are not well organized. The tests should be reorganized into several parts:

       Basic API
           This part should test the entire basic API of SQL::Statement, SQL::Parser and probably the entire
           engine command classes.

       DBI / Table API
           This part should test if the API to DBI drivers work (maybe an empty test driver will be needed for
           that).

       Functionality
           This part should test the functionality of the SQL::Parser and the SQL::Statement engine.

       Performance
           This part should be used to implement full useage cases (ideally from real world projects) to allow
           for testing optimizations.

PRIORITIES

       Our priorities are localized to our current issues and proof of concept fixes for upcoming SQL::Statement
       2.xx.

       Any additional priorities (as missing features, the SQL::Statement rewrite) will come later and can be
       modified by (paying) users.

RESOURCES AND CONTRIBUTIONS

       See <http://dbi.perl.org/contributing> for how you can help.

       If your company has benefited from the DBI or SQL::Statement, please consider if it could make a donation
       to The Perl Foundation "DBI Development" or "SQL::Statement Development" fund at
       <http://dbi.perl.org/donate> to secure future development.

       Alternatively, if your company would benefit from a specific new DBI or SQL::Statement feature, please
       consider sponsoring its development through the options listed in the section "Commercial Support from
       the Author" on <http://dbi.perl.org/support/>.

       Using such targeted financing allows you to contribute to DBI development (including SQL::Statement and
       PurePerl DBI drivers) and rapidly get something specific and directly valuable to you in return.

       Thank you.