[development] Requiring node revisions

David Strauss david at fourkitchens.com
Fri Jun 8 03:36:29 UTC 2007

Karthik wrote:
> On 08/06/07, Derek Wright <drupal at dwwright.net> wrote:
>> 1) {node_revisions} *ALWAYS* has at least 1 record for any given
>> node.  that's where title, body, etc are stored.  please read the
>> schema if you have further questions.  therefore, the only site with
>> an empty {node_revisions} table is the site with no nodes at all.
>> 2) {node_revisions} has an index on nid, and we always JOIN on nid.
>> by and large, the cost of this JOIN is constant, regardless of the #
>> of rows in the table, since the JOINs basically always use the index.
> Eh? So what is by and large? Does that mean some queries will be less
> efficient?
> For example, how about if my module in contrib perform an ORDER BY on
> node_revisions fields such as timestamp and uid? This would require a
> filesort on the entire table ... Will these be unaffected?

That's a ridiculous, contrived scenario. If your site's small enough,
the performance won't change much. If your site's large, you should add
a new index on {node_revisions}. You're not going to convince anyone
here that the DB should be structured to maximize performance of your
hypothetical, ill-conceived queries.

> This is essentially:
> a) Taking away choice.

Taking away frivolous choices is a good thing.

> b) Increasing table size.
> c) Introducing inefficiency.
> d) Loading the table with potentially unnecessary junk whether I like it
> or not.

All three of those are overstatements of the same thing: the DB gets a
little better. The increase in size is pretty minor.

> e) Asking me to sort any resulting issues out with another contrib module.

It's official policy to completely disregard compatibility issues with

> f) Telling me what's good for my site.

If you're so desperate to not have revisions, you can write a contrib
module that deletes all old revisions every time you save a node.

> ... all for the sake of a couple of checkboxes.

And all the other reasons mentioned in my post. Nice strawman.

> No thanks. -1.
> -K

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20070607/2b88e5f5/attachment.pgp 

More information about the development mailing list