[development] Object caching
ber at webschuur.com
Wed Jul 26 07:57:34 UTC 2006
Op dinsdag 25 juli 2006 16:53, schreef Khalid B:
> > Easy, we'd continue to maintain a URL alias table with all the path
> > aliases. In the node/user/taxonomy object we'd just 'cache' the
> > active path alias (duplication).
> > (I'm not claiming this is the best solution.)
> Sounds like a legitimate case for de-normalization for performance.
> The tricky part is making sure that who ever updates one updates
> the other, so we stay consistent. This better be a function that is
> called and does the work behind the scene, and no one touches
> the raw tables.
It is not persé. The problem is far simpler, and IMO we are circling around
the wrong solution all the time:
fact: a lot of db queris (in a huge table) has bad performance.
fact: anything that is created automatically can be de-created automatically.
fact: with a very few exceptions everyone with large alias tables is using
pautauto or another automated method.
example: node/123 -> posts/news/man-falls-in-water
which was generated with a "pattern" posts/[term_name]/[title]
why do you want to store that in the first place? It is just as simple to tear
apart then to mak. It is not even a heavy piece that yuo might want to cache.
IMO we should look beyond the "path table is slow, let us make the table
A few other concepts to look at are:
* routers: menus not only handle incoming links but the outgoing ones too.
* hook_alias (with caching, quit-after-first-hit and other speed
optimisations): pathauto can deliver a on-the-fly-crafted link. path.module
can deliver aliases from the DB
* callbacks: simple version of routers: each path *pattern* gets a callback
function that will handle the (de)composing of that path.
I guess there are a lot moer options, options that have more potential in
performance, flexibility and simplicity of code then just tweaking the path
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060726/86dbab76/attachment.pgp
More information about the development