i've bumped into a limitation in node.module that i makes me squirm. our bulk node operations on admin/content/node are very efficient because they perform single UPDATE statements like (make these nodes promoted): db_query('UPDATE {node} SET status = 1, promote = 1 WHERE nid IN(%s)', implode(',', $nodes)); the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change. oddly, the delete operation does do one by one deletion which is good because we aren't leaving behind cruft in ancillary node tables. since this page only allows for changing 50 modes at a time, i think it wouldn't be too slow to call node_save() on each selected node. i think thats the best way to assure integrity for all those modules which expect to hear about node changes. this form doesn't have to be lightening fast. folks might also be interested in a Views powered version of this page which i've specced out at http://drupal.org/node/125810. conversation about this Views plugin should stay within that issue.
the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change. I think we definitely need to call the API instead of direct DB updates. This is what I kept in mind when adding some user mass operations http://cvs.drupal.org/viewcvs/drupal/drupal/modules/user/user.module?r1=1.72...
And you're right that this form doesn't need to be fast. I think we need this even if it is on 50 nodes. We'll just have to make sure to not cache those nodes like the recent node access issue. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Moshe Weitzman wrote:
i've bumped into a limitation in node.module that i makes me squirm. our bulk node operations on admin/content/node are very efficient because they perform single UPDATE statements like (make these nodes promoted):
db_query('UPDATE {node} SET status = 1, promote = 1 WHERE nid IN(%s)', implode(',', $nodes));
the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change. oddly, the delete operation does do one by one deletion which is good because we aren't leaving behind cruft in ancillary node tables.
since this page only allows for changing 50 modes at a time, i think it wouldn't be too slow to call node_save() on each selected node. i think thats the best way to assure integrity for all those modules which expect to hear about node changes. this form doesn't have to be lightening fast.
folks might also be interested in a Views powered version of this page which i've specced out at http://drupal.org/node/125810. conversation about this Views plugin should stay within that issue.
On 08 Mar 2007, at 06:12, Rob Barreca wrote:
the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change.
I think we definitely need to call the API instead of direct DB updates. This is what I kept in mind when adding some user mass operations http://cvs.drupal.org/viewcvs/drupal/drupal/modules/user/ user.module?r1=1.721&r2=1.722
Yes, not calling the nodeapi is a bug that might result in data loss and/or data integrity issues. -- Dries Buytaert :: http://www.buytaert.net/
Moshe Weitzman wrote:
i've bumped into a limitation in node.module that i makes me squirm. our bulk node operations on admin/content/node are very efficient because they perform single UPDATE statements like (make these nodes promoted):
db_query('UPDATE {node} SET status = 1, promote = 1 WHERE nid IN(%s)', implode(',', $nodes));
the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change. oddly, the delete operation does do one by one deletion which is good because we aren't leaving behind cruft in ancillary node tables.
Is it feasible to extend the existing hooks, so that other modules are passed a list of nids? OK, when I think about it, this will create an area of nodeapi that SQL-deficient developers would have trouble adapting to, many would ignore it, and we'd be in the same spot. Still, I'm interested. .s
participants (4)
-
Dries Buytaert -
Moshe Weitzman -
Rob Barreca -
sime