[TYPO3-50-general] Stable API for Persistence package

Jochen Rau jochen.rau at typoplanet.de
Sun Jul 19 19:18:19 CEST 2009


Hi Martin.

Martin Kutschker wrote:
> Jochen Rau schrieb:
>> Hi Martin.
>>
>>>>> Or $query->execute($queryString)?
>>>>>
>>>>> To be honest, I'd try to keep it from existing...
>>>> I have to withstand a temptation. But without it, we will have
>>>> exec_SELECTquery in Extbase. Brrr!
>>> Why?
>> Why what? (please mark)
>> - "withstand"
>> - "exec_SELECTquery"
>> - "Brrr!"
>
> Why will Extbase have to have (or to use?) exec_SELECTquery?

In the end Extbase and the extensions based on Extbase *) should not use 
exec_* methods. But we are inside TYPO3 4.x and they are available for 
every extension developer. So, if we are not able to provide a flexible 
solution in the Query object, we will definitely end up having
exec_* in the Repositories. That will mix up the layers of the 
persistence in Extbase. That's why I said "Brrr!".

*) We should find a proper acronym for that (like TAFKAP=The Artist 
Formerly Known As Prince ;-) )

> I do understand that having a general SQL query function that has to
> assume its input is in the Mysql SQL dialect and has to do extensive
> parsing and rewriting is evil. It's one of DBAL's biggest problems.

Without having verified this by profiling, I assume that parsing the 
Query object in the Storage Backend isn't a bottle neck.

> But I don't understand why Extbase would need such a feature.

We plan to have different implementations of the Storage Backend (maybe 
after 4.3 was released). Each of them having a optimized parser for the 
Query object.

Regards
Jochen

-- 
Every nit picked is a bug fixed



More information about the TYPO3-project-5_0-general mailing list