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

[Xavier Perseguers]

Hi,

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, ...

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

-- 
Xavier Perseguers
http://xavier.perseguers.ch/en

One contribution a day keeps the fork away