=head1 NAME

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

Jens Rehsack - June 2010

=head1 SYNOPSIS

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

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

=head1 CHANGES AND ENHANCEMENTS

=head2 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.

=head3 CREATE and DROP of FUNCTION, KEYWORD, OPERATOR, TYPE

SQL::Statement misses 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 it's
road.

=head3 Parser improvements

The SQL::Parser is implemented based on a lot of regular expressions and
some manual developed logic. This creates some issues like RT#53416 or
RT#55190. Further, trailing C<;> makes SQL::Parser croaking. It should
be proved what can be fixed without deep changes and what has to wait.

=head3 Performance

SQL::Statement 1.xx will not receive additional time to improve it's
performance. The performance is good as it is and improvement requires
design changes.

=head3 Reliability

Bugs will be fixed - when possible. SQL::Statement 1.28 is much more
reliable than SQL::Statement 1.15. And even if no extra effort will put
into increase reliability, all remarked issues are thankful taken to learn
how to design SQL::Statement 2.xx better.

=head3 Extensibility

SQL::Statement 1.xx is highly extensible, even if a more object oriented
design would improve that. The 1.xx branch will not receive redesign to
reach higher extensibility on coding level.

=head2 Enhancements in SQL::Statement 2.xx

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

=head3 SQL::Parser rewrite

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

=head3 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).

=head3 Performance

There are several performance optimizations wanted 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
I<premature optimization is the root of all evil>, it's primarily targeted
to have adequate fast, reliable implemtation 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 use cases.

=head3 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.

=head3 Extensibility

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

=head3 Testing

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

=over 4

=item Basic API

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

=item DBI / Table API

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

=item Functionality

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

=item Performance

This part should be used to implement full use cases (ideally got from
real world projects) to allow doing optimizations.

=back

=head1 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.

=head1 RESOURCES AND CONTRIBUTIONS

See L<http://dbi.perl.org/contributing> for I<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
L<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 L<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.

=cut
