[development] Object Caching in DRUPAL-7?

[Nabil Alsharif]

This is my first post on this list so pleas enlighten the ignorant.

IMO having a hook_nodeapi_load and hook_nodeapi_post_load could get a
little confusing and is redundant. I agree with Josh in that there
should be a $node->cacheable field.

The question is where does drupal check this field? For example I could
create a cache friendly content type and set the nodes of that type to
cacheable in (say hook_load). Another module could come along and alter
that node (hook_nodeapi_*) in a way that isn't cache friendly and
designate to as non-cacheable, what then?


On Wed, 2009-02-25 at 23:28 -0500, Nathaniel Catchpole wrote:
> In the node_load() caching patch we've added a
> hook_nodeapi_post_load() which is uncached - so poll implements
> hook_nodeapi_load() to get the options in there, and
> hook_nodeapi_post_load() to get user-specific information. 
> 
> There may well be a use case for a field_attach equivalent which does
> the same thing. Field already has a cache though, so if we're caching
> objects persistently there'd actually be no change on this specific
> point.
> 
> Nat
> 
> On Wed, Feb 25, 2009 at 8:58 PM, Josh Koenig <josh at chapterthree.com>
> wrote:
>         > There is the issue of distinguishing cacheable and
>         non-cacheable fields.
>         > Does D7 Fields API flag fields as cacheable to make this
>         simpler?
>         
>         
>         Off the top of my head, it would somewhat defeat the purpose
>         of
>         object-caching to try and handle this on the per-field basis.
>         You'd
>         really need field-level caching then, which is an order of
>         magnitude
>         more in complexity (if not more).
>         
>         That said, I'm not sure what a "non cacheable" field would be
>         like,
>         unless it was some kind of php computed value, which seems
>         like an
>         edge case. Am I mistaking your meaning here? In mose cases,
>         the field
>         values should only change when the object itself is updated,
>         at which
>         point the cache would be invalidated anyway, and the next load
>         would
>         be fresh.
>         
>         This does break down if there's a computed value in a field.
>         The most
>         basic example I can think of is a node with PHP content for
>         the body.
>         Maybe something that displays the current time. As it stands,
>         I
>         believe Drupal's page caching system grabs the output of that
>         PHP and
>         stores it for anonymous users, meaning they'll get out-of-date
>         computations.
>         
>         That's potentially a big deal if you're talking about
>         object-level
>         caching for logged-in users, so perhaps we would treat nodes
>         like this
>         as "uncacheable."
>         
>         Anyway, let me know if I'm way off here.
>         
>         I'll also be checking up on Nedjo's patch, as that definitely
>         seems
>         like the right architectural solution for drupal 7 core.
>         
>         cheers
>         -j
> 
-- 
----------------------------------
Nabil Alsharif
Bright Tree
573-499-1244

This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete
the original. Any other use of the email by you is prohibited. Please
consider the environment before printing this email or its
attachment(s).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.drupal.org/pipermail/development/attachments/20090226/21a16fb7/attachment-0001.pgp