[development] node caching
jeff at viapositiva.net
Thu Aug 30 06:45:24 UTC 2007
I don't want to spend much time discussing the node caching issue, as
I've already weighed in. But there have been a number of responses
that suggested I need to produce a list of 'broken modules' or
suggestions that I'm FUDding the addition of caching. I'd like to
explain in a bit of detail what my concerns are; if they're solved,
so be it. If not, well, same deal. I just want to make sure that
these issues are raised.
There are a number of modules that it will definitely complicate
things for (they'll have to learn a new way of managing data to avoid
strange unpredictable 'stale data' bugs, and it ISN'T simply a matter
of moving to view() operations on any sufficiently complex system).
Obviously, developers can simply be told, "change your code, it's
My biggest concerns and frustrations are based on two things:
1) Judging from the issue itself, it went in without considering the
impact on sites where high interactive traffic (voting on nodes, etc)
would frequently reset cached nodes. In these situations, caching
could easily make things WORSE, as nodes will rapidly be loaded,
cached and cleared rather than simply loaded.
The use of a 'nocache' param is certainly one solution, but it's an
after-the-fact fix; it becomes the new, subtle, strange version of
advanced caching's hook_init warning. "If you see something strange,
maybe it's node caching."
2) It breaks existing APIs more than a month after the code freeze,
__in a way that is NOT required to fix a critical bug__. It enhances
performance in many cases, yes. But so would many API-breaking
changes. I would have no problem with simply telling contrib authors
to move their code to another op __if we were not past freeze.__ I've
even argued for the addition of __non-breaking__ functionality post-
freeze. But stopping breaking changes from coming in at the last
minute is PRECISELY what the freeze is supposed to do.
Do I think that the feature is fundamentally flawed? NO. Do I think
that it went in without sufficient consideration of the varied
activity footprints of high-traffic production sites? YES. I've said
my piece, and I don't plan on dwelling any more on the issue. If
others feel it's important (Morbus and Crell are two who've spoken up
with concerns) they can do so. There are other important things to
work on and I don't want to end up spending my cycles going back and
forth on this particular one.
If Dries and Goba decide to keep it and the concerns of others
affected by it are quelled, so be it. I do think, though, that our
very loose definition of code freeze (no breaking API changes unless
required to fix a critical bug) should be revised. It should mean
SOMETHING other than 'we think we're probably done breaking things,
unless we come up with something cool.'
More information about the development