[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