.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{
.    if \nF \{
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "SQL::Statement::Roadmap 3"
.TH SQL::Statement::Roadmap 3 "2014-12-02" "perl v5.16.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
SQL::Statement::Roadmap \- Planned Enhancements for SQL::Statement and SQL::Parser
.PP
Jens Rehsack \- June 2010
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
This document gives a high level overview of the future of SQL::Statement,
SQL::Parser and its impact.
.PP
The planned enhancements cover testing, performance, reliability,
extensibility and more.
.SH "CHANGES AND ENHANCEMENTS"
.IX Header "CHANGES AND ENHANCEMENTS"
.SS "Enhancements in SQL::Statement 1.xx"
.IX Subsection "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.
.PP
\fI\s-1CREATE\s0 and \s-1DROP\s0 of \s-1FUNCTION, KEYWORD, OPERATOR, TYPE\s0\fR
.IX Subsection "CREATE and DROP of FUNCTION, KEYWORD, OPERATOR, TYPE"
.PP
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.
.PP
This should be done before SQL::Statement 1.xx reaches the end of its
road.
.PP
\fIParser improvements\fR
.IX Subsection "Parser improvements"
.PP
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 \f(CW\*(C`;\*(C'\fR causes SQL::Parser to
croak. We need to decide what can be fixed without internal design
changes and what has to wait.
.PP
\fIPerformance\fR
.IX Subsection "Performance"
.PP
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.
.PP
\fIReliability\fR
.IX Subsection "Reliability"
.PP
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.
.PP
\fIExtensibility\fR
.IX Subsection "Extensibility"
.PP
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.
.SS "Enhancements in SQL::Statement 2.xx"
.IX Subsection "Enhancements in SQL::Statement 2.xx"
Concerning the procedural design of SQL::Statement 1.xx a rewrite of the
basic components is required.
.PP
\fISQL::Parser rewrite\fR
.IX Subsection "SQL::Parser rewrite"
.PP
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
\&\s-1SQL\s0 dialects.  This will allow better extensibility from a feature
point of view without losing \s-1ANSI SQL\s0 compatibility.
.PP
\fISQL::Statement rewrite\fR
.IX Subsection "SQL::Statement rewrite"
.PP
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).
.PP
\fIFeatures\fR
.IX Subsection "Features"
.PP
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.
.PP
\s-1LOCK TABLE\s0
.IX Subsection "LOCK TABLE"
.PP
Locking table within \s-1SQL\s0 scripts to manually control table consistence over
several operations. The current locking support is restricted to one
statement.
.PP
Transaction support
.IX Subsection "Transaction support"
.PP
Executing statements on a temporary copy of the table data.
.PP
The easiest way to implement this would be to create a
SQL::Statement::RAM on \f(CW\*(C`BEGIN TRANSACTION\*(C'\fR
and write the entire table back on \f(CW\*(C`COMMIT\*(C'\fR or discard on \f(CW\*(C`ROLLBACK\*(C'\fR.
.PP
Better performance could be achieved in cases where the implementation is
enabled to memorize pending modifications and apply them at \f(CW\*(C`COMMIT\*(C'\fR.
On the other hand there are already
capabilities to
improve some operations, which might create confusion in case of
transactions.
.PP
This needs more discussion.
.PP
\s-1ALTER TABLE\s0
.IX Subsection "ALTER TABLE"
.PP
Adding, removing or modifying columns is not supported for created
tables. A generic \f(CW\*(C`ALTER TABLE\*(C'\fR seems to rely on the implementation
of the transaction support \- until better ideas are provided.
.PP
Indices
.IX Subsection "Indices"
.PP
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.
.PP
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.
.PP
Sub-Selects
.IX Subsection "Sub-Selects"
.PP
In most cases queries can be re-expressed without using sub-selects. But
in any case, there are circumstances where sub-selects are required.
.PP
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.
.PP
Query based variables
.IX Subsection "Query based variables"
.PP
Currently the only variable I can imagine is \f(CW\*(C`ROWNUM\*(C'\fR. More suggestions
are very welcome.
.PP
Better \s-1SQL\s0 Script support
.IX Subsection "Better SQL Script support"
.PP
In SQL::Statement 1.xx the function \f(CW\*(C`RUN ()\*(C'\fR provides \s-1SQL\s0 script
execution. This function may have limitations and side effects (at least
when the executed \s-1SQL\s0 touched the same tables as the primary statement).
.PP
I plan to improve the \s-1SQL\s0 script support to remove the side effects on
the one hand and have a more flexible and easier way to execute them.
.PP
Finally it should be possible to execute a script via:
.PP
.Vb 1
\&    $dbh\->do( join( ";", @script ) );
.Ve
.PP
Trigger support
.IX Subsection "Trigger support"
.PP
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.
.PP
\fIPerformance\fR
.IX Subsection "Performance"
.PP
There are several performance optimizations required for
SQL::Statement 2.xx.
.PP
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 \fIpremature optimization is the root of all
evil\fR, 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.
.PP
The second optimization goal means: implementing most expensive methods
in \s-1XS.\s0 This requires a good performance test suite as well as some real
world usage cases.
.PP
\fIReliability\fR
.IX Subsection "Reliability"
.PP
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.
.PP
\fIExtensibility\fR
.IX Subsection "Extensibility"
.PP
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.
.PP
\fITesting\fR
.IX Subsection "Testing"
.PP
Many tests in SQL::Statement are not well organized. The tests should be
reorganized into several parts:
.IP "Basic \s-1API\s0" 4
.IX Item "Basic API"
This part should test the entire basic \s-1API\s0 of SQL::Statement,
SQL::Parser and probably the entire engine command classes.
.IP "\s-1DBI /\s0 Table \s-1API\s0" 4
.IX Item "DBI / Table API"
This part should test if the \s-1API\s0 to \s-1DBI\s0 drivers work (maybe an empty test
driver will be needed for that).
.IP "Functionality" 4
.IX Item "Functionality"
This part should test the functionality of the SQL::Parser and the
SQL::Statement engine.
.IP "Performance" 4
.IX Item "Performance"
This part should be used to implement full usage cases (ideally from
real world projects) to allow for testing optimizations.
.SH "PRIORITIES"
.IX Header "PRIORITIES"
Our priorities are localized to our current issues and proof of concept
fixes for upcoming SQL::Statement 2.xx.
.PP
Any additional priorities (as missing features, the SQL::Statement rewrite)
will come later and can be modified by (paying) users.
.SH "RESOURCES AND CONTRIBUTIONS"
.IX Header "RESOURCES AND CONTRIBUTIONS"
See <http://dbi.perl.org/contributing> for \fIhow you can help\fR.
.PP
If your company has benefited from the \s-1DBI\s0 or SQL::Statement, please
consider if it could make a donation to The Perl Foundation
\&\*(L"\s-1DBI\s0 Development\*(R" or \*(L"SQL::Statement Development\*(R" fund at
<http://dbi.perl.org/donate> to secure future development.
.PP
Alternatively, if your company would benefit from a specific new
\&\s-1DBI\s0 or SQL::Statement feature, please consider sponsoring its development
through the options listed in the section \*(L"Commercial Support from the
Author\*(R" on <http://dbi.perl.org/support/>.
.PP
Using such targeted financing allows you to contribute to \s-1DBI\s0
development (including SQL::Statement and PurePerl \s-1DBI\s0 drivers) and rapidly
get something specific and directly valuable to you in return.
.PP
Thank you.