[development] Object caching

[Bèr Kessels]

Hello,

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 
faster". 

A few other concepts to look at are:
 * routers: menus not only handle incoming links but the outgoing ones too. 
 (detail:http://lists.drupal.org/archives/development/2006-05/msg00864.html ) 
 * 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 
tables.

Bèr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060726/86dbab76/attachment.pgp