[development] Object caching

[Khalid B]

On 7/22/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
>
> On 22 Jul 2006, at 21:35, Matt Westgate wrote:
> > Other CMS's have been improving their URL alias feature by storing
> > each alias with the data it represents. We could store node aliases
> > in the node table, user aliases in the user table and menu aliases
> > in the menu table.  This reduces the amount of queries we need to
> > generate and would avoid an alias-specific caching solution.
> >
> > Of course there are other rogue aliases that couldn't be accounted
> > for with this approach, but I bet we'd reduce the number of alias
> > queries by 80%.
>
> That's easy to count.  Just add some counter logic to
> drupal_lookup_path() and we'd be able to estimate the gain.  :)
>
> Anyway, this brings us back to the de-normalization discussion we've
> had lately.  We could potentially cache a lot of node related
> properties in the node table (eg. the comment count, last comment
> timestamp, username, etc).
>
> We're running around in circles, me thinks.  Time to implement some
> approaches and to compare their implementation and performance?

Matt has a point here ...

I don't think it is bad denormalization in this case.

What we have now is a one to many relationship of node  -> alias, and
we allow multiple aliases for the same node.

If we go to a 1:1 relationship, then the logical place for the alias is in
the object that it represents (term, user, node), and this would speed
up things for certain operations (e.g. emitting an alias instead of
the native path), but potentially slow others (looking up an incoming
alias and converting to the native path?)

What we lose here is the ability for multiple aliases.

Or we can keep the other (older/additional/...etc) aliases where they are
now, and have the current alias in the object's table.

To clarify:

I have node/123 which starts life as this_is_an_alias, based on what pathauto
does. This is indexed, linked to, ...etc.
Then later, the title changes, and it becomes this_is_a_new_alias.

this_is_a_new_alias is stored in the node table, and this_is_an_alias
is in the url_alias table.

The same goes for a user who calls himself kbahey then decides to
change his Drupal name to KhalidB.

This is not bad denormalization if it can be called that. The current alias
represents something and the  older one represent something else.

If there is an index on the current alias field, it will take care of
the slowness
part to some extent.