{
    "content": [
        {
            "type": "text",
            "text": "# SQL::Statement::Roadmap (perldoc)\n\n## NAME\n\nSQL::Statement::Roadmap - Planned Enhancements for SQL::Statement and SQL::Parser  Jens Rehsack - June 2010\n\n## SYNOPSIS\n\nThis document gives a high level overview of the future of SQL::Statement, SQL::Parser and its\nimpact.\nThe planned enhancements cover testing, performance, reliability, extensibility and more.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **CHANGES AND ENHANCEMENTS** (2 subsections)\n- **PRIORITIES**\n- **RESOURCES AND CONTRIBUTIONS**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "SQL::Statement::Roadmap",
        "section": "",
        "mode": "perldoc",
        "summary": "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\nimpact.\nThe planned enhancements cover testing, performance, reliability, extensibility and more.",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 4,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 5,
                "subsections": []
            },
            {
                "name": "CHANGES AND ENHANCEMENTS",
                "lines": 1,
                "subsections": [
                    {
                        "name": "Enhancements in SQL::Statement 1.xx",
                        "lines": 29
                    },
                    {
                        "name": "Enhancements in SQL::Statement 2.xx",
                        "lines": 118
                    }
                ]
            },
            {
                "name": "PRIORITIES",
                "lines": 6,
                "subsections": []
            },
            {
                "name": "RESOURCES AND CONTRIBUTIONS",
                "lines": 16,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "SQL::Statement::Roadmap - Planned Enhancements for SQL::Statement and SQL::Parser\n\nJens Rehsack - June 2010\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "This document gives a high level overview of the future of SQL::Statement, SQL::Parser and its\nimpact.\n\nThe planned enhancements cover testing, performance, reliability, extensibility and more.\n",
                "subsections": []
            },
            "CHANGES AND ENHANCEMENTS": {
                "content": "",
                "subsections": [
                    {
                        "name": "Enhancements in SQL::Statement 1.xx",
                        "content": "SQL::Statement 1.xx will not receive big changes, but a few enhancements may help us to design\nSQL::Statement 2.xx much better.\n\nCREATE and DROP of FUNCTION, KEYWORD, OPERATOR, TYPE\nSQL::Statement is missing some functions, types, operators etc. It's supported to add missing\nfunctionality - but the implementation was not picked up during the modernizing of column\nevaluation. See RT#52397 for some more information.\n\nThis should be done before SQL::Statement 1.xx reaches the end of its road.\n\nParser improvements\nThe SQL::Parser is implemented based on a lot of regular expressions and some manually developed\nlogic. This creates some issues like RT#53416 or RT#55190. Further, trailing \";\" causes\nSQL::Parser to croak. We need to decide what can be fixed without internal design changes and\nwhat has to wait.\n\nPerformance\nThere is no intention to work on performance improvements in SQL::Statement 1.xx. The\nperformance is good as it is and improvement requires design changes.\n\nReliability\nBugs will be fixed - where possible. SQL::Statement 1.28 is much more reliable than\nSQL::Statement 1.15. Even if a bug cannot be fixed all issues are gratefully received as they\nwill be considered in the design process for SQL::Statement 2.xx better.\n\nExtensibility\nSQL::Statement 1.xx is highly extensible, even if a more object oriented design would improve\nthat. The 1.xx branch will not be redesigned for greater extensibility on a coding level.\n"
                    },
                    {
                        "name": "Enhancements in SQL::Statement 2.xx",
                        "content": "Concerning the procedural design of SQL::Statement 1.xx a rewrite of the basic components is\nrequired.\n\nSQL::Parser rewrite\nThe SQL::Parser needs to be modified to be able to use a Backus Naur Form\n<http://en.wikipedia.org/wiki/BackusNaurForm>. This would allow users and developers to rely\non many different SQL dialects. This will allow better extensibility from a feature point of\nview without losing ANSI SQL compatibility.\n\nSQL::Statement rewrite\nSQL::Statement should be reduced to a simple coordinating engine. The executing tasks should be\norganized into separated commands. This will reduce side effects and will open the door for\nhigher level optimizations, reliability improvements or sub-selects (or other calculated\ntables).\n\nFeatures\nThere is a large list of missing features but not all table backends will be able to support\neach new feature. The most popular requested features need additional discussion and everyone is\nwelcome to do it on the mailto:dbi-dev@perl.org.\n\nLOCK TABLE\nLocking table within SQL scripts to manually control table consistence over several operations.\nThe current locking support is restricted to one statement.\n\nTransaction support\nExecuting statements on a temporary copy of the table data.\n\nThe easiest way to implement this would be to create a SQL::Statement::RAM on \"BEGIN\nTRANSACTION\" and write the entire table back on \"COMMIT\" or discard on \"ROLLBACK\".\n\nBetter performance could be achieved in cases where the implementation is enabled to memorize\npending modifications and apply them at \"COMMIT\". On the other hand there are already\ncapabilities to improve some operations, which might create confusion in case of transactions.\n\nThis needs more discussion.\n\nALTER TABLE\nAdding, removing or modifying columns is not supported for created tables. A generic \"ALTER\nTABLE\" seems to rely on the implementation of the transaction support - until better ideas are\nprovided.\n\nIndices\nCurrently some table backends have implicit support to access specified rows quicker than\nfetching each row and evaluating the where clause against the row data.\n\nAn interface would be required to configure fetching to return only rows matching a restricted\nwhere clause. Another (probably better) way to support indices would be to fetch index entries\nat first and have an interface to the table fetching lines based on an index key.\n\nSub-Selects\nIn most cases queries can be re-expressed without using sub-selects. But in any case, there are\ncircumstances where sub-selects are required.\n\nThe first implementation will do the sub-select before the primary statement is executed without\nany further optimization. Hopefully a later version will provide better Performance with some\noptimization.\n\nQuery based variables\nCurrently the only variable I can imagine is \"ROWNUM\". More suggestions are very welcome.\n\nBetter SQL Script support\nIn SQL::Statement 1.xx the function \"RUN ()\" provides SQL script execution. This function may\nhave limitations and side effects (at least when the executed SQL touched the same tables as the\nprimary statement).\n\nI plan to improve the SQL script support to remove the side effects on the one hand and have a\nmore flexible and easier way to execute them.\n\nFinally it should be possible to execute a script via:\n\n$dbh->do( join( \";\", @script ) );\n\nTrigger support\nMost important when doing complicated things is having callback functions for several events.\nWhile real triggers will not be possible for SQL::Statement and underlying pseudo-databases,\ncallbacks could be provided via triggers.\n\nPerformance\nThere are several performance optimizations required for SQL::Statement 2.xx.\n\nThe first one should be done on a very high level (query optimization) by implementing algebraic\nevaluation of queries and clean implementation of typical database algorithms. With respect to\nthe basic optimization rule *premature optimization is the root of all evil*, it is primarily\ntargeted to have an adequately fast, reliable implementation of many algorithms (e.g. early\nincomplete evaluation to reduce amount of rows, transpose where clause to evaluate constants\nfirst) and a clever controller choosing the right algorithm for a specific query.\n\nThe second optimization goal means: implementing most expensive methods in XS. This requires a\ngood performance test suite as well as some real world usage cases.\n\nReliability\nThis is one of the primary goals of SQL::Statement. I hope to reach it using test driven\ndevelopment and I hope I get some more todo's from the users for this.\n\nExtensibility\nThe currently high level of extensibility should be increased on a coding level. This will be\ndone by redesigning the entire parser and execution engine using object oriented techniques and\ndesign patterns.\n\nTesting\nMany tests in SQL::Statement are not well organized. The tests should be reorganized into\nseveral parts:\n\nBasic API\nThis part should test the entire basic API of SQL::Statement, SQL::Parser and probably the\nentire engine command classes.\n\nDBI / Table API\nThis part should test if the API to DBI drivers work (maybe an empty test driver will be\nneeded for that).\n\nFunctionality\nThis part should test the functionality of the SQL::Parser and the SQL::Statement engine.\n\nPerformance\nThis part should be used to implement full usage cases (ideally from real world projects) to\nallow for testing optimizations.\n"
                    }
                ]
            },
            "PRIORITIES": {
                "content": "Our priorities are localized to our current issues and proof of concept fixes for upcoming\nSQL::Statement 2.xx.\n\nAny additional priorities (as missing features, the SQL::Statement rewrite) will come later and\ncan be modified by (paying) users.\n",
                "subsections": []
            },
            "RESOURCES AND CONTRIBUTIONS": {
                "content": "See <http://dbi.perl.org/contributing> for *how you can help*.\n\nIf your company has benefited from the DBI or SQL::Statement, please consider if it could make a\ndonation to The Perl Foundation \"DBI Development\" or \"SQL::Statement Development\" fund at\n<http://dbi.perl.org/donate> to secure future development.\n\nAlternatively, if your company would benefit from a specific new DBI or SQL::Statement feature,\nplease consider sponsoring its development through the options listed in the section \"Commercial\nSupport from the Author\" on <http://dbi.perl.org/support/>.\n\nUsing such targeted financing allows you to contribute to DBI development (including\nSQL::Statement and PurePerl DBI drivers) and rapidly get something specific and directly\nvaluable to you in return.\n\nThank you.\n",
                "subsections": []
            }
        }
    }
}