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@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