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

[Ernesto Baschny [cron IT]]

Martin Kutschker schrieb:
> Ernesto Baschny [cron IT] schrieb:
>> Xavier Perseguers schrieb:
>>
>>> I hope to get some (positive) feedback here as I did not mention the
>>> word "DBAL" in title (ouch I did it anyway with my first few words :D).
>>>
>>> OK. Once again, even with DBAL "outside" of Core, there is a real
>>> problem to get patch committed to trunk when it comes to issues that
>>> occur "only" when using DBAL.
>>>
>>> Here is some extract from a discussion I had today with Karsten about
>>> what to do with SQL parser included in Core. I'm not speaking about the
>>> parser used to allow modifications of the database structure (CREATE
>>> TABLE, ALTER TABLE, ...) but the SELECT/INSERT/UPDATE parser which is
>>> used when installing DBAL but not when using MySQL only.
>>>
>>>> I would probably remove the code from core. [...] that should mean
>>> less probability for errors
>>>> When Kasper put that code in place back in 2004 we all thought/hoped
>>> that people would go crazy
>>>> writing DB handlers, but that has not happened.
>>>>
>>>> Time to move the code into the right place, I'd say. And that is DBAL.
>> About this, I always wondered: if we have such a nice and complex
>> sql-parser, why isn't it being used in more places?
>>
>> For example the Install Tool "COMPARE" or the Ext.Manager ext_tables.sql
>> file handling. Couldn't we have a single nice "sql parser" that parses
>> the CREATE TABLE statements and use it in everywhere?
>>
>> Compare:
>> - t3lib_sqlparser::parseCREATETABLE
>> - t3lib_install::getFieldDefinitions_fileContent
>>
>> it does more or less "the same" (it parses a CREATE TABLE statement),
>> but is completely different code. The install tool parser is already
>> complex enough to cover lots of cases, but still buggy.

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

The sql-parsing and the "comparasion" should different things / classes.
The core uses *the* sql_parser to parse the ext_tables.sql files but
then uses some "sql_compare" class / service that should be able to make
a diff from the parsed SQL with the current state in MySQL (which should
of course cope with all variants and MySQL specifities we know of).

DBAL should also register for that service so that DBAL installations
can compare with different databases. I am not sure how this works right
now.

> If THE sql parser is to be used by the installer then there is a good reason to retian it in the
> core. But it isn't the parser as such that is the problem. It is the odd sql_parser/sql_engine
> couple that makes trouble (for DBAL).

Yes, but I thought that this is another issue. Moving the sql_engine to
DBAL is no problem for me and that the DBAL-sql_engine doesn't extend
the sql_parser is also something logical and I think being taken care of
already.

The remaining "standalone" SQL parser in t3lib is already very nice, and
I am glad that you agree that we could make good use of it in the core,
Masi.

Cheers,
Ernesto