[TYPO3-project-4-3] Deprecating SQL parser in TYPO3 4.3

[Ernesto Baschny [cron IT]]

Xavier Perseguers schrieb:

> Martin Kutschker wrote:
>> Ernesto Baschny [cron IT] schrieb:
>>>> The code in the installer does too many checks based on string
>>>> comparisons. This breaks even with
>>>> different version of the Mysql server.
>>> How else should the checks compare stuff if not by string comparisons?
>>
>> By feature! Don't compare "varchar(11) NOT NULL" but
>> array('type'=>'VARCHAR','notNull'=>true).
>>
>>> The data should be more structured of course, so that we don't have a
>>> string like "int(10) unsigned auto_increment whatever" to compare with,
>>> but properties like "isAutoIncrement" etc.
> 
> Then you'll need to provide some good SQL schema dumper as it is now
> quite easy to dump a MySQL schema to be copied to ext_table.php.
> 
> It would be really great to be able to use the SQL parser within TYPO3
> of course.
> 
> I just thought of some ideas/problems:
> 
> - Extension developers should have a way when "debugging" or "testing"
> their extension to force parsing of all their query with the integrated
> SQL parser. This would lead to much better usage of such an extension
> when using something else than MySQL, typically when using DBAL with
> PostgreSQL or Oracle. This certainly would not solve all problems but
> would prevent many bugs to be found only when someone tries to use the
> extension in a DBAL environment. Currently this is easily done by simply
> installing DBAL without further configuration but it may be more clear
> and could be some flag in $TYPO3_CONF_VARS. Just as we have debug level
> option and devIpMask, ...

Great idea!

> - Taking the SQL parser to a real usable level, with support of
> subqueries and the rest is not something really trivial although I would
> like to start enhancing it. Now enhancing the Core SQL parser may only
> be done in conjunction with testing and enhancing in DBAL are they are
> both highly coupled. This leads to third point:
> 
> - Main (current) problem is that I'm one of the few people (but I'm not
> alone I agree) fixing bugs and enhancing this part of Core that
> currently is not really used outside from DBAL. This means that as
> Ernesto suggested, you - core team - should find something acceptable
> for its maintenance. Either give me some rights to maintain it, at least
> until it starts to be used for real in Core, or have some special
> process to allow maintenance to be made more easily, perhaps as
> suggested with some DBAL review. This review of course is often my own
> eyes but you may not be aware of it, I'm often asking Moreno (Oracle)
> and Ries (PostgreSQL) to give me feedback, or I request feedback when I
> update one of their initial patch that was submitted to a bug tracker
> entry. Meaning I can say that DBAL  officially supports both Oracle and
> PostgreSQL.

Yes, we all appreciate that position you put yourself in and I am happy
that we finally have this potential to say that!

For me I wouldn't hesitate to commit changes to sql_parser to the core
in t3lib if you post a RFC to the core list stating that you and another
DBAL member already approved the code. Or better yet, have Moreno or
Ries actually giving a "+1 by reading and testing" in the core list. For
me I would consider that enough criteria to commit as an exception.

Cheers,
Ernesto