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

[Ernesto Baschny [cron IT]]

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.

And I think if we had a really complete sql parser in core, it could be
used in a lot more places than "just" DBAL. Some people love to write
SQL, but it sometimes doesn't fit the abstraction model chosen (e.g.
extbase). We could still offer "SQL" but in the background transform it
into objects and classes or other fancy stuff, instead of the other way
around of constructing queries with objects and some other invented
language that we at the end transform into SQL. So continue using "SQL"
as the query language (which is known by so many people) and have that
even able to talk to future non-relational backend storages.

So I still prefer to have "sqlparser" in the Core, but the problem seems
to be the maintainability of this. Passing its responsability to DBAL
team would indeed be a great idea. But instead of "moving it out" of
t3lib, I would rather give Xavier and the DBAL team easier commit
"speed" to t3lib_sqlparser fixes, meaning if the change is "DBAL team
approved", some core team member could commit right away. How does that
sound?

Cheers,
Ernesto