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

[Xavier Perseguers]

Hi Steffen,

>> 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).
>>
> do you think that is the case? I know at least two persons always 
> answered to DBAL issues ;) Now we have "Mr DBAL" which is good imho!

:-)

>> 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.
>>
> if DBAL relies on core there is something wrong in abstraction, it 
> shouldn't be the case. All real DB related stuff should be handled in 
> t3lib_db.

Well, no I wouldn't say the separation is wrong. Actually the separation 
is quite good. The only flaw I saw was with t3lib_sqlengine which was 
not bad when in Core but lead to non-optimal solution when it got used 
with XCLASS in DBAL. But this case has already been solved.

t3lib_db is responsible for providing wrapper around mysql_* calls 
(sql_*, ...) that get overloaded in DBAL to use ADOdb and for providing 
facility functions to create queries without having to write the full 
SQL (exec_SELECT|UPDATE|...query). They do nothing with t3lib_sqlengine.

Actually the only official use of t3lib_sqlengine in Core is in 
t3lib_install.

Methods that are being called and that should be kept in t3lib_sqlengine:

- method parseFieldDef()
- method compileFieldCfg()
- member parse_error

Actually, I'm quite astonished, it's the first time I really search for 
use in Core and I was sure there were more use of it :-)

All other methods are used by DBAL, mainly in method admin_query from 
ux_t3lib_db which parses the query (DROP TABLE, CREATE, ALTER, ...) 
while the pendant in t3lib_db simply calls mysql_query directly.

>>  > 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.
>>
> ok, if it's so, let's do it.

With my analyze from this morning. I would even suggest to deprecate all 
methods that are not listed above and copy them to ux_t3lib_sqlparser.

>> There is currently 3 patches waiting in Core that are related to DBAL:
>>
> 
> 
>> - RFC #10411: sqlparser is not able to parse more than 1 join
>> - RFC #12231: New caching framework (4.3-dev) does not work with DBAL 
>> (oracle)
>> - RFC #5120 / #8915: SQL parse error in "Who is online" BE list
>>
> 
> Rupi and me are starting again fixing session tomorrow, so you'll get 
> support.

Great.

> Sometimes you have to be more patient. I understand that you have to 
> wait for some patches being applied for continue work on DBAL, but when 
> you look to core list there are a lot of issues to be handled. Send your 
> reminder and/or try to speak on skype about. All will be fine in the end ;)

The thing is not actually being impatient for this very case but trying 
to be more efficient to lower the load on Core dev that have enough to 
tackle with with main "Core" of TYPO3. DBAL is in but the DBAL is able 
to manage it. As Karsten said, we should drop "not widely used" methods 
right away. Let's clean what people not using DBAL see and let DBAL be 
more powerful. We definitely should keep DBAL as sysext and as such it's 
OK to have reference (in phpDoc mainly I mean) to it but I really think 
cleaning Core from DBAL methods and relocate them in DBAL itself should 
be better for all of us.

-- 
Xavier Perseguers
MVC ExtJS Leader

http://forge.typo3.org/projects/show/extension-mvc_extjs