[development] optimize table in cron

Chris Johnson chris at tinpixel.com
Mon Dec 5 17:16:20 UTC 2005

> On Mon, Dec 05, 2005 at 10:30:15AM +0100, B?r Kessels wrote:
>>A big -1 on having backup and optimisation stuff in core. A big +1 on putting 
>>that in contributed maintainance or database modules.

Piotr Krukowiecki wrote:
> I think backup stuff is essential element of any advanced system and
> should be in core.
> Also, VACUMM in PostgreSQL not only optimizes but also marks deleted
> rows for reuse. If the database is not vacuumed it will grow infinitely.

I am opposed to adding this kind of thing to core.

When I first read the suggestion, I thought, "yeah, why not use Drupal's cron 
to improve Drupal's performance by making sure the database tables are 
optimized?"  Then I read the responses and thought about the problems.

What is Drupal core?  If it's a CMS or application framework, it's not the 
right place to put system and database administration tasks.  It will conflict 
with current best practices for managing those tasks.  Worst of all, it 
dilutes the strengths of Drupal by trying to make it a one-tool-fits-all 
solution, while bloating the code with features many people will never use.

Should you optimize, vacuum and integrity check your database tables?  Yes. 
But do it from the database administration level.  Do it via system cron or 
other such method.

The same is true of backups.  They don't belong in Drupal core and are best 
done from the operating system level.

Should these features be available in a non-core module?  Sure.  If it helps 
some people or some sites, it's worth doing.

Is there a problem with doing backups or database maintenance that would 
benefit from being able to signal Drupal in some way to, say, display a "site 
temporarily unavailable" or "site temporarily read only" message, and then 
behave appropriately?  Maybe.  If so, providing an API or hooks that outside 
processes could call might be appropriate in core.


More information about the development mailing list