is nodeapi hook a requirement or not?

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  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.721&
r2=1.722 


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.electroni
cinsight.com
robelectronicinsight.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  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.
>

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

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/use
r/ 
> 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/