[development] Object caching

[Khalid B]

On 7/23/06, Larry Garfield <larry at garfieldtech.com> wrote:
> On Saturday 22 July 2006 16:19, Khalid B wrote:
>
> > 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.
>
>
> I don't see how we do.  It just declares one alias "primary".
>
> That is, if node 5 has an alias of my/fifth/node in the node table, that is
> the alias that is used for any output.  Vis, system-generated links to node/5
> are always rewritten to my/fifth/node.
>
> The separate alias table then is for *incoming* paths.  You can have as many
> aliases for a page as you want for incoming requests, but only one for Drupal
> output.  (And really, why would you want to have multiple aliases that get
> printed by Drupal?  That only confuses people.)
>
> As an example, suppose you have a weekly newsletter, with each newsletter
> being a node.  The alias for each newsletter would be its date, say
> newsletter/2006-07-22.  That's the primary alias, and that's in the node
> table.  Then there's also an alias newsletter/latest that points to whichever
> is most recent (updated however), which you can put into mailings and such.
> Once the user's there, however, there's no reason to not send them to the
> dated alias.
>
> So we're not losing multi-alias support at all, at least not really.

You are right. I  sort of negated that in  my previous message when I said:
"Or we can keep the other (older/additional/...etc) aliases where they are
now, and have the current alias in the object's table.", and  the example
says that.

So, I am in support  of  the main/current/primary alias being in the  node
table and the others where they are today for incoming requests.

That should improve page generation for taxonomy, node  and users, since
there will be zero extra queries.