[TYPO3-core] RFC: Bug #13508: Use exec_TRUNCATETABLEquery() instead of DELETE FROM throughout the core

[Christian Kuhn]

Hi!

Dmitry Dulepov wrote:
> -1 because it adds MySQL–specific naming and unnecessary complexity. A 
> different approach is better: keep DELETEquery but check WHERE 
> statement. If it is empty or 1=1, use TRUNCATE. No need for a new 
> method, no need for API change, no confusion for programmers, no need 
> for programmers to make call decisions in their code. API must hide 
> complexity, not add it!

Thanks for your important feedback!

Thinking about it and reading answers in this thread I still think 
separation to different API methods is the better way in this special case:

- Truncate is supported by all major databases.
- As pointed out by others, truncate and delete react pretty differently 
(auto_increments, triggers).
- Truncate should be pretty well known to developers, they are able to 
distinct it from delete.
- The option "hide magic in delete method" with no way to change it's 
behavior from outside might lead to more trouble in the future.
- The option "add magic to delete method but make it configurable with 
an option" practically leads to the same solution as a new public 
TRUNCATE method, except that a new method is more direct and 
transparent, and another option for DELETE just adds more things you 
have to remember / learn if you use the method. In both cases you have 
to think about which db call you actually need.

So, even if I second the idea of keeping API's simple, I would suggest 
to not interweave truncate with delete and to expose truncate as an own 
API method, thus I'm still +1 for #13504 and #13508.

Regards
Christian