[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.
..chrisxj
More information about the development
mailing list