[development] Re: Object Caching
Ken Rickard
agentrickard at gmail.com
Sun Jul 23 17:25:07 UTC 2006
Just a note regarding all the cache discussions.
I will be in Portland next week for O'Reilly's Open Source.
If anyone is attending, we can do some collaboaration and testing.
I will be in town Tuesday through Saturday.
- Ken
agentrickard at gmail.com
On 7/23/06, development-request at drupal.org <development-request at drupal.org>
wrote:
>
> Send development mailing list submissions to
> development at drupal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.drupal.org/listinfo/development
> or, via email, send a message with subject or body 'help' to
> development-request at drupal.org
>
> You can reach the person managing the list at
> development-owner at drupal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of development digest..."
>
>
> Today's Topics:
>
> 1. GNOME's CMS evaluation for Drupal (Andy Smith)
> 2. Re: Object caching (Larry Garfield)
> 3. Re: Caching, caching, caching... (Gordon Heydon)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 23 Jul 2006 03:31:29 +0200
> From: "Andy Smith" <andyster at gmail.com>
> Subject: [development] GNOME's CMS evaluation for Drupal
> To: development at drupal.org, documentation at drupal.org
> Message-ID:
> <541901410607221831i320e2153x8aed0777fe7b84a7 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey folks, GNOME is looking to change to a CMS and since I like GNOME I'd
> obviously like it to choose a very nice CMS like Drupal, however when I
> looked at the page plenty of data appeared to be incomplete, things like
> i18n and such that people have less knowledge about, but maybe some of you
> can fill it in
>
> http://live.gnome.org/GnomeWeb/CmsRequirements/DrupalEval
>
> If you are interested in the GNOME project using Drupal, head to that link
> and give some factual info.
>
> --andy
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.drupal.org/pipermail/development/attachments/20060723/324a380b/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Sat, 22 Jul 2006 23:30:02 -0500
> From: Larry Garfield <larry at garfieldtech.com>
> Subject: Re: [development] Object caching
> To: development at drupal.org
> Message-ID: <200607222330.02425.larry at garfieldtech.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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.
>
> --
> Larry Garfield AIM: LOLG42
> larry at garfieldtech.com ICQ: 6817012
>
> "If nature has made any one thing less susceptible than all others of
> exclusive property, it is the action of the thinking power called an idea,
> which an individual may exclusively possess as long as he keeps it to
> himself; but the moment it is divulged, it forces itself into the
> possession
> of every one, and the receiver cannot dispossess himself of it." --
> Thomas
> Jefferson
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 23 Jul 2006 19:48:37 +1000
> From: Gordon Heydon <gordon at heydon.com.au>
> Subject: Re: [development] Caching, caching, caching...
> To: development at drupal.org
> Message-ID: <44C345F5.5080804 at heydon.com.au>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> Remember also modules like organic groups which has no relation to roles.
>
> Maybe a caching flag on theme('page'), so the modules can determine tell
> the system to cache this page for this user, or groups of users.
>
> I know that we just return something, so we would need to make the
> return method to allow the returning of an array which is past to
> theme('page');
>
> Gordon.
>
> John Handelaar wrote:
> > Dries Buytaert wrote:
> >>
> >> Cache by role doesn't work because there are many per-user settings
> >> (eg. language preference, the username in the navigation-block, etc).
> >
> >
> > To be fair, I did *explicitly* mention that would be some
> > elements which could not be cached by role.
> >
> > There are, however, a whole bunch which can - I'm confident
> > in my original assertion of 'vast majority', in fact.
> >
> > That there are some places it can't work doesn't sound like
> > a good reason to not consider the places where it can -
> > unless we're going to keep thinking of caches as a full-page-
> > only thing.
> >
> > i18n/l10n, as you say, would probably have to be another "vary"
> > switch. This implies that we should maybe be thinking about
> > a new core hook, which modules can use to introduce/manage switching
> > cases.
> >
> > How about stepping back and thinking about what variables can
> > affect caching on any given theme() function, and in which order
> > they do so?
> >
> > eg
> >
> > 1. (core) Role, and if not role then
> > 2. (core) User, and if not user then
> > 3. (i18n module) $some_i18n_variable, else
> > 4. ...what else?
> >
> >
> > Actually, that list might be upside down in practice, but
> > hopefully I've managed to get my point across.
> >
> >
> > Cached values would be returned for any function which
> > returns theme output... like...
> >
> > [pseudo-code]
> >
> > function node_page_default() {
> > global $user;
> > if (node_page_default_cache($user->uid)) {
> > return node_page_default_cache($user-uid);
> > }
> > else {
> >
> > // original function here
> >
> > }
> > }
> >
> > ...where node_page_default_cache() would be an implementation
> > of hook_cache(), which in turn contains that order-of-preference
> > logic mentioned above. $user->uid gives us the ability to
> > check roles, uids, and anything else we might need.
> >
> > This would involve changing *lots* of functions, I realise,
> > but consider how many DB queries we'd be culling.
> >
> > On the other hand, a well-written hook allows modules to
> > start using it incrementally - modules which haven't implemented
> > it yet don't fail.
> >
> >
> >
> >
> >
> >
>
>
> ------------------------------
>
> --
> [ Drupal development list | http://lists.drupal.org/ ]
>
> End of development Digest, Vol 43, Issue 87
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060723/98a7989b/attachment-0001.htm
More information about the development
mailing list