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

Ries van Twisk typo3 at rvt.dds.nl
Thu Feb 11 14:09:34 CET 2010


On Feb 11, 2010, at 5:21 AM, Dmitry Dulepov wrote:

> On 2010-02-11 10:04:55 +0200, Xavier Perseguers said:
>> Well, it's not standard SQL I agree but it is implemented by all  
>> officially supported databases:
>> - MySQL (of course)
>> - MSSQL [1]
>> - Oracle [2]
>> - PostgreSQL [3]
>
> Still it is not a reason to add another method (see below).
>
>> Well, please post this to FYI #13504 and I'll possibly make a  
>> follow-up with change to make those methods protected instead (for  
>> instance). Kind of a "post-review". Sorry, I really took it as a  
>> bug fix more than a new feature, but it makes sense.
>
> My post is not related to #13504 :) I am against adding a new method  
> when it is possible to optimize existing method. By optimizing we  
> hide complexity and we do not force developers to do more choices.
>
> As a developer, I'd like to simply use exec_DELETEquery. Why should  
> I care if TRUNCATE is faster? I need to focus on my task, not on  
> such minor issues :)
>
> May be today TRUNCATE is faster and tomorrow it is not. This  
> handling should be hidden inside the API, not inside every  
> extension. Developers must not care what they use: DELETE or  
> TRUNCATE. They must have exactly *one* way to do their task, not  
> many ways. The system should decide on the implementation of DELETE,  
> not the developer.
>
> You know the phrase: "be simple and people will like it". This is  
> what I try to do with my -1 to this RFC: be simple to developers :)  
> Don't make them think when it is not necessary.


TRUNCATE is well know enough among all developers to understand it and  
when to use it.
Your change is flawed because it doesn't catch all conditions where  
the command
needs to delete all records in a database, TRUNCATE <tablename> and  
DELETE FROM <tablename>
do totally different things in terms of record locking and often they  
reset a serial counter back to 1.
MySQL does that, PostgreSQL doesn't reset the serial/autonumber).

You method changes the behavior of the underlaying actions.

Also I am sometimes used to doing DELET FROM <TABLENAME> where True,  
and your function doesn't catch that.

Also, what if I want to delete records in a table and need the serial  
counter kept where it stayed,
I really want to use DELETE, not TRUNCATE.

I understand that a API needs to be kept simple, I am all for it...  
but you cannot change behavior
based on some condition.

If you would ask me, a API for TRUNCATE needs to be created....

Ries




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20100211/494ff1e8/attachment.htm>


More information about the TYPO3-team-core mailing list