On 08/06/07, David Strauss <david@fourkitchens.com> wrote:
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.
I'm just refuting claims that there is no difference in performance. Even with core queries, there will be a difference in performance, albeit minor. But a difference nonetheless.
a) Taking away choice.
Taking away frivolous choices is a good thing.
What is frivolous to you is not frivolous to other people. That's why Drupal gives them a choice. Drupal is inherently malleable.
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.
Perhaps I'm taking a leaf out of all the redundancies in your first post? The advantages gained are just not noteworthy enough, or can already be realised by just defaulting to "create new revision".
e) Asking me to sort any resulting issues out with another contrib module.
It's official policy to completely disregard compatibility issues with contrib.
I was talking about your recommendation to use a contrib module to clean up old revisions.
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.
Why? I'm happy as it is now.
... all for the sake of a couple of checkboxes.
And all the other reasons mentioned in my post. Nice strawman.
Please read and reply to Dries' response. -K