1.add some instrumentation in path_nodeapi 'load' case (say a call to echo to print some output)
2.navigate to a node edit form (e.g. node/4/edit)
expected behavior:
nodeapi call gets called once
actual behavior:
nodeapi call gets called twice

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

Status: Active » Closed (works as designed)

node_load is cached, so no prob.

Wesley Tanaka’s picture

So any module that implements nodeapi load by grabbing from another table needs to take care of caching that load on its own as well? Seems like it would be better that nodeapi load just get called once in the first place.

chx’s picture

nodeapi load is not called twice (at least it should not).

Wesley Tanaka’s picture

I agree. I shouldn't be happening. And it is. And it seems like it's getting called 3 times on node view pages.

Wesley Tanaka’s picture

Status: Closed (works as designed) » Active

Changing back to active as per comment #3, plus the observed behavior.

moshe weitzman’s picture

i can't reproduce this. i added some debug code to book_nodeapi('view') and is called once for a node view. mayeb disable all contrib stuff. sounds like a loop is happenning somewhere

webchick’s picture

I did what moshe outlined above, except I added case 'load': to book module's hook_nodeapi, not view.

I can't reproduce the problem. When I view node/## I just get one print statement.

Now, if I view just node, I get several, but that's because there will be one load call for each node on the page.

So is it possible that the page you're looking at is comprised of 2 or more nodes somehow?

webchick’s picture

Sorry, noticed you said node edit and path.module. But same thing... only one print statement.

Wesley Tanaka’s picture

'load', not 'view' or 'edit'.

webchick’s picture

Right.

case 'load' on hook_nodeapi

when going to node/##/edit

Still can't reproduce.

Any further hints?

Wesley Tanaka’s picture

Sorry, I missed comment #7 (just switched to the yahoo mail beta and getting used to it). Let me try to repro this on a fresh install.

Wesley Tanaka’s picture

node_load is getting called from several different places, and it seems like the node_load result isn't actually cached, so that nodeapi('load') is getting called each time node_load gets called.

chx’s picture

Status: Active » Needs review
FileSize
865 bytes

Hm, hm.

chx’s picture

FileSize
878 bytes

Hm, hm, hm.

Wesley Tanaka’s picture

better_node_caching.patch fixed the particular case originally reported (nodeapi 'load' in path.module) in both the node/XXX and node/XXX/edit cases.

Wesley Tanaka’s picture

better_node_caching_0.patch also passed that same smoke test.

chx’s picture

yes, but the first patch was broken :) it returned the core info only not the cached stuff.

chx’s picture

FileSize
1.27 KB

Even better.

killes@www.drop.org’s picture

Why is the last patch better than the previous one?

i also think that both of them are flawed a bit by setting the cache parameter to node->nid.

try this:
$node = node_load(array('nid' => 48, 'uid' => 1));
print_r($node->body);

$node = node_load(array('nid' => 48, 'uid' => 2));
print_r($node->body);

if this happens on the same page request (and the first returns a valid node) then the second will return the same node, although there is no node which matches the condition.

This does not happen with the current node module

killes@www.drop.org’s picture

I can't verify wtanaka's issue in the first place. There is no node_load in path.module.

Currently, node_load is only cached if it is called with a numeric argument. As I have shown, this is a good thing, since otherwise problems could occur.

The only place in core where node_load is loaded in a non-cacheble way is in poll.module (once) and a couple of times in node.module (in the revisions code).

chx’s picture

Status: Needs review » Closed (won't fix)

Let's put this issue to the rest. If it can't be cached, well, then it can't.

Wesley Tanaka’s picture

> There is no node_load in path.module.

That's correct. node_load calls nodeapi's 'load', which in turn calls path_nodeapi if the path module is enabled. The reported behavior is that each call to node_load will also create a call to nodeapi's 'load'.

It seems to me that this should be cached. Comment #19 seems to be saying that the cache key needs to be the full "$param" parameter to node_load(), not that caching is impossible.

chx’s picture

Status: Closed (won't fix) » Needs review
FileSize
1.01 KB

Well, we are already iterating the param array, so why not.

killes@www.drop.org’s picture

wtanaka: Only non-cachable node_loads will call nodeapi at all. Is it possible you use some modules which still use the depcrecates node_load(array('nid' => n)) syntax? These would indeed call nodeapi.

flk’s picture

Status: Needs review » Closed (won't fix)

< chx> more than 99% of the time the node is cached
< chx> and when not, then not
< chx> and yes, then nodeapi load is called twice
< chx> so is hook_load
< chx> i feel fine with that
< chx> mark it won't fix

flk’s picture

ps the above comment where from chx, forgot less-than and greater-than are striped

hmdnawaz’s picture

Version: x.y.z » 6.x-dev
Assigned: Unassigned » hmdnawaz
Category: bug » task
Priority: Normal » Major
Status: Closed (won't fix) » Active

I wrote the following code
function test_block($op = 'list', $delta = 0, $edit = array())
{
if($op == 'view')
{
$node = node_load(array('type' => 'forum', 'uid' => 1));
$block_content = $value->title;
$block['content'] = $block_content;
}
return $block;
}

the user with uid=1 have two posts in forum but my code returns only one post.

hmdnawaz’s picture

Assigned: hmdnawaz » Unassigned
Issue summary: View changes

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.