Recompute all instances of a computed field upon field change

I agree. Seems like a fairly simple feature addition that could be useful to many people.

I pulled your php into a module for my own use, here it is if anybody likes it.

Hi Ted,

Just a short thanks & thumbs up for the helpful module. Worked like a charm.

Regards,
Wouter

I tried this as part of the header of a view.

Two problems:
1) every node recomputed is then marked as "updated". Is there a way of forcing a recomputation but not making the node as updated?
2) the view itself doesn't update to reflect the changes till the next time. Is there a way of updating the view query in the header?

Many thanks in advance! This is a great CCK field.

Following the advice in http://muzso.hu/node/4332 I think I've solved the updating bit ... now need to fix the reloading of the view query.

The Following code is in the header of my view (set to PHP input filter):

// The calculated values are only recalculated when the node is
// loaded so force a reload now
$res = db_query("SELECT n.nid FROM {node} n WHERE n.type = 'session'");
print '<p>DEBUG: updated the following</p>';
print '<ol>';
while ($n = db_fetch_object($res)) {
  // get the old timestamps before we save 
  $node_changed = $n->changed;
  $rev_timestamp = $n->revision_timestamp;
  node_save(&$n);
  // undo changes in timestamp and changed flag
  db_query("UPDATE {node} SET `changed` = '%d' WHERE `nid` = '%d'", $node_changed, $n->nid);
  db_query("UPDATE {node_revisions} SET `timestamp` = '%d' WHERE `nid` = '%d' AND `vid` = '%d'", $rev_timestamp, $n->nid, $n->vid);
  print '<li>'.l($n->title, 'node/'.$n->nid).'</li>';
}
print '</ol>';

subscribing.

Is there a possibility of setting it as a action & trigger such that when a specific node gets updated/ created, this functionality of the computed fields being recomputed happens?

http://drupal.org/node/324704

I've changed a little code as in #1 as follow:

<?php
$res = db_query("SELECT n.nid FROM {node} n WHERE n.type = 'some_content'");
while ($n = db_fetch_object($res)){
   $node = node_load($n->nid);
   $n = node_save($node);
}
?>

So now it's working for me fine in Drupal 6.x (before not).

IMHO updating alll nodes is like killing a fly with a tank... It's way too heavy :D
I think we should have a mechanism to avoid some computed field being cached by Drupal cache mechanism, but I'm not really sure if it's currently possible...
See http://drupal.org/node/332200

Thanks for the update. I installed the module from .zip file in #3 and I was also getting

Warning: Call-time pass-by-reference has been deprecated - argument passed by value;
If you would like to pass it by reference, modify the declaration of node_save().
If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file.
However, future versions may not support this any longer.
in /.../httpdocs/sites/all/modules/regenerate/regenerate.module on line 71

I changed the module posted by blookslic in #3 above based on code in #9 above and the messages are gone.

See attached revised .zip (use at your own risk)

the regenerate module from post 11 says
This version is incompatible with the 6.7 version of Drupal core.

This would help me with this issue correct?
http://drupal.org/node/343786#comment-1175338

Views Bulk Operations can do this correct?

I'm running Drupal 6.8 and it worked fine for me. I wonder if it could be a PHP version issue for you. You could try upgrading to 6.8 and see what happens.

Views Bulk Operations did exactly what I needed.

How about time out issues? Is there a way to have this run with cron, like the search indexing? I can imagine a lot of time needed on large sites.

@#10:
I have computed field which can take advantage of other modules. If they are enabled after some content has been created, then that content will not have the correct links and features, and since I update it infrequently, some sites might have an old version, which will be updated in the future, when the development is in a stable state.

Tnx for the module, I will try it out.

@#12 I added

core = "6.x"

into regenerate.info, but still it doesn't work, problem with an extra argument in regenerate_menu(), but after fixing that, still no joy.

There is a define for REGENERATE_UPDATE_NODE_TYPES, which is never used in the file, I tried changing the places where UPDATE_NODE_TYPES was used to see if that was a problem, but no.

I am stumped...

I spent far too much time this night trying to get this to work. I got it to finally show the form, but it seems that on form submit it doesn't call the right handler.

If anyone wants to try fixing the remaining problem with the form submit, this is were you should start on 6.8

I should have just gone with views and custom code.

kenorb (comment #9),

I need help with your code. When I enter the code in the header of my view it does not work, In the header I can see a piece of the code

nid); $n = node_save($node); } ?>

and nothing happens (meaning it does not recalculate the computed field,

can you help me figure out what I am doing wrong? . The only thing that I changed from your code was the content type.
Thanks,

@finlaycm: Make sure that you have enabled PHP Filter and the input format is in PHP, then it should work.

Subscribing

I think a nice way for keeping the computed column data in synch with the computed value would be:

1) On Node view, the module should retrieve the stored value and the computed value and always display the computed value.
2) If they are different, then update the stored value.
3) Never cache the computed columns with the page view if that is possible.

This to me seems like it would be best for most use cases. If a user goes from a node listing page that has stale stored computed data to the Node Details page, they would always get the up to date info when it really mattered and the corresponding row in the listing view would then get updated. If a computation is to expensive for a node page you could opt out of the showing the computed value on the node page.

What do you think? If people are interested I could put together a patch maybe.
(Also, note in the Display Fields setting if you set it to "Computed Value" for the node then it still shows the database value. At least for me. I thought that would take care of #1 above but it did not.)

Great Idea.
@subscribing

subscribing

http://drupal.org/node/332200

Fixed spelling, so that if someone searches for "recalculate" they'll find this issue.

Hi to all,
I'm working in D6.10 and computed field 6.x-1.0-beta2 and it seem that I found a solution thats it's working for me.

I've
- a date field named "field_due_date"
- computed field named "field_check_date" that check if date < today

and I created the following trigger and actions:

-Rule setting: event = "Content is going to be viewed"
-Condition: Viewed content is *the name of my content type*
-Actions: Populate viewed content's field "field_check_date"
Show a configurable message on the site (only to check that the rule is working)

And thus, any time my content type is going to be viewed, the rule populate the value of the field "field_check_date" with the Computed Code and the Display format of the computed field.

Only, i need to check tomorrow (when the date change) if this is still working.

Regards,
Jorge

You can easily do this with Views Bulk Operations. Install the module and go to the views page, where VBO comes with a default view that mimics the content listing page of Drupal. Instead, you can select all nodes at once (eg of a certain type), and you should choose "Execute arbitrary PHP script". In the body, write node_save($object);. This will resave all the nodes on your website and thus trigger the calculation of the computed fields!

subscribed

Hey why not make the 'regenerate' script into a full blown module?

I think this would make more sense as a part of the Computed Field module, which would expose a filter to recalculate computed field nodes (by re-saving the node). VBO is just a way to select more than 25 nodes...

The idea in #28 has a gotcha--VBO doesn't clear the data residue from a prior node before processing the next node. I have filed #564442: Data residue/namespace not cleared between bulk node operations in the Views Bulk Operations issue queue.

Subscribe

subscribing, thx

Well Jorge,

Did it work? I am now trying to use your trick. And it seems I only get the confurable message when I go in and view a node (not view a view) as I was hoping.

So I have to go to a node of the particular type. Then Drupal displays my message. But the computed field does not get updated...

Any ideas?

Thanks

Morten

subscribing!

#28 Solved it for me. Thanks.

I'd still like to see a module-integrated solution to this. I have computed field values that are based off of other computed field values. With solution #9 and #1 it takes two reloads to get the numbers right. That's very db-intensive.

The same applies to solution #28, which is even worse because it reloads all nodes.

I have 30 content types. If a user changes one field, a calculated value may change. Only calculated fields that are accessing this particular piece of data should be updated. Again, keep in mind that there are calculated fields that access data off of other calculated fields.

Ideas anyone?

I found a solution to this (#38) particular problem. It's not very elegant, but it works.

I use Calculated Fields to calculate the first tier value, i.e. x = 2 + 4, y = 1 + 2
I use Views Custom Field to calculate the second tier value that is based of off two "first tier calculations", i. e. z = x + y, z = 2 + 4 + 1 + 2 = 9.

Again, I would love to use only one of those two solutions, but I don't have a choice.

The clear disadvantage of Views Custom Field is that it doesn't store its values in the db.

I have a problem running any of the given code snippets above because I have a class declared inside the textarea of the computed field PHP code. So I get a fatal error: Cannot redeclare class [MYCLASS] in [...] computed_field.module(161) : eval()'d code on line 921

I tried to take the code outside and save it in a file but then add a problem of re-declaring a function (http://drupal.org/node/623144).

Is there any way I can do it nevertheless?

Thanks!

VBO worked great for me(thanks!) except for the fact that I was declaring a function in my computed field, so I included those functions in a module, see the following for more info: http://drupal.org/node/564442#comment-2501102

Good people,

I had problems getting #18 to work in my Drupal 6.16. It simply didn't submit or start the process.
So I reworked it a bit and got it to work. Thanks to those who created the foundation!

I also added a couple of extras:
- You now also see the literal name of the node type as well as the node count in stead of just the machine name
- The module checks for pathauto and urges you to disable it to avoid timeouts on large updates

Pathauto is a severe weight around the ankles in processes like these. It's always advisable to disable it before such operations.

I have updated thousands of nodes on not-so-swift servers and it worked well, but really large batches - like dozens of thousands or hundred thousands - will probably require lots of muscle, a long timeout or splitting the work into several batches. Ajax has been on my mind, but right now I fixed my own problem, so Ajax will have to wait.

Martin

#42 doesn't work - "0 nodes of mytype updated"

#42 it's work

#42 warning

* warning: mysql_real_escape_string() [function.mysql-real-escape-string]: Access denied for user 'sample'@'localhost' (using password: NO) in /home/sample/public_html/sites/all/modules/regenerate_2/regenerate.module on line 99.
* warning: mysql_real_escape_string() [function.mysql-real-escape-string]: A link to the server could not be established in /home/sample/public_html/sites/all/modules/regenerate_2/regenerate.module on line 99.

I replaced mysql_real_escape_string with Drupal's alternative db_escape_string. Worked with small amount of nodes. If I try to regenerate thousands of nodes I am getting PHP memory error. Increasing php memory on server's php.ini .htaccess or settings.php not worked.

mysql_real_escape_string() replaced with db_escape_string()

Good people,

I have updated my own small module (#42).

It now uses db_escape_string(), but also updates in batches so that very large numbers of nodes can be regenerated.
It works with a simple circular call of the page (no Ajax for now), but seems to run smoothly. I have used it several times on large sites.

It also has a few other improvements over the first versions like offering to disable pathauto and enabling it again when the update is done.

I hope this is useful - it has helped me quite a bit.

Martin

#48 Good job, thanks for your effort Martin.
I tested on Drupal 6.16 and got
1- "mysql_numrows(): supplied argument is not a valid MySQL result resource" at line 143
Adapting code with using db_result() instead of mysql_numrows() solves that error. http://drupal.org/node/114774#db-num-rows
2- Regeneration started and regenerated 9174/1881 nodes and firefox stop redirection at http://www.example.com/admin/settings/continueregenerate/cdr/1900/100/1881

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
* This problem can sometimes be caused by disabling or refusing to accept
cookies.

Subscribing.

This seems well suited as a drush command.

Yura,

I know that using mySQL-specific code is a no-no, and I'll look into using the database abstraction layer in the next incarnation.

Regarding the second error, I can only guess that the somewhat primitive refresh-method I use has entered an eternal loop, which I should be able to solve. Currently the module transfers the cycle state (essentially a limit for the next database query) through URL arguments. I have thought of using a cookie in stead, and adding a cycle counter, which could be set to max out at some point, prohibiting an endless loop and exiting with a sensible error.

On the other hand, the code is so simple that I have a hard time seeing why the endless loop would come in the first place...

I will give it a once over and return with an updated version.

Martin

Yura, folks,

I'm trying to track down why the module might go into a loop.

The URL http://www.example.com/admin/settings/continueregenerate/cdr/1900/100/1881 indicates that the module is trying to read 100 nodes from node 1900 and on, but it seems that there are only 1881 nodes of the type cdr.

Going beyond the last node should give an empty result from the query and trigger the module to stop looping further. And even mysql_numrows() should return a false if the argument is not a proper mySQL result (which I don't really see why would happen...).

I have run the module many times, and never met the problem.

But still: This latest incarnation does use db_result() and has a small "brake" that checks for an endless loop and stops if there is no progress in the number of nodes regenerated. It shouldn't be necessary, but on the other hand it doesn't hurt.

PS: One more change in the module uploaded here: I moved the menu item from the settings menu to the content menu where I found it more logic to place this content-centric function.

Martin

Instead of batch regeneration using node_save I've modified the module to update computed values on saving field settings. It would be appropriate to recompute all instances after a code change.
The relevant database column I figured is [your field name]_value. Only tested it on Views, worked for sort criteria (probably filter, argument and display field as well), but this should work as long as this column is used as the data source. Non-computed fields are not touched, so if you have a lot of nodes it will be a performance gain.

The patch:

[edit: See update below. It did work after all.]
Hm. This patch didn't work for me. I'm not looking at the computed field data through views, but in the node directly.

Just to make sure I'm doing what you're suggesting the patch will do: I applied the patch, then edited the computed field (content>content types>manage fields>configure field) and saved that field's settings. That's where the recomputation is supposed to occur, correct?

Going back to my nodes with computed fields, the field doesn't seem to be computed when I look at it in devel. It's only exposed through token.module (in the page title) but the fact that it's not showing up in devel either makes me think it's not being recalculated.

One caveat: My use case is that of a computed field that was added to a bunch of existing nodes, such that right now all the computed fields are NULL, and only get computed upon first edit of the node. (That's why I want the batch recomputation.) So if for some reason this would only work on fields that have been computed at least once, not entirely NULL fields, that may be the reason it's failing on my end.

(Sorry if this was too much info! Wanted to give you good feedback, though.)

I updated the issue info to match what this seems to have reached, which is a feature request on the module.

Update: Somehow I think the patch didn't actually apply the first time. I tried it again from scratch to be sure, and this time it worked as expected.

So +1 on this patch!

I think feature requests go in the development branches?

Hi vertikal.dk

I've used your module for some days now and it works as expected, but i have some things i've noticed while using it.

1.) Some times it simply dies with a lot of MySQL Errors indicating, that you are injecting to much entries in the {drupal_watchdog} table and the SQL server now rejects requests. I don't know if its related to drupal or your module, but we don't need watchdog here, didn't we?

Warning: MySQL server has gone away query: INSERT INTO drupal_watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:6295:\"MySQL server has gone away\nquery: UPDATE drupal_cache SET data = ... in 'http://blablabla/admin/content/regenerate', '78.5 in /home/www/***/drupal/includes/database.mysqli.inc on line 128

2.) If you manually exit the page which called content/regenerate or it fails during execution, it does not reactivate PathAuto. I agree, that it falls under "expected behavior" on the first case, but it should re-enable it when sth. failed during the "normal" execution.

3.) It seems to update the data no matter what. It should only Insert/Update Data in the database, if the result actually CHANGED since the last "refresh" of the computed field. That would save a TON of pressure on the SQL server.

4.) You should maybe give an "Execute on cron" option with "Run every x minutes" option.

With best regards
Mario

Mario,

I have no idea what happens when your MySQL-server goes away (other than a database error or timeout). The module itself will not inject other messages into the watchdog-table than a status when finished as well as a message about disabling and enabling pathauto. The rest of the watchdog-messages must come from the database system complaining about the errors or other parts of Drupal, which get invoked during the loading and saving of each node.

Regarding updating only when needed, my problem is that I have no idea whether a given field needs an update or not. Many of my computed fields are just calculations done on the basis of everything from counters to date and time. Sometimes it computes to being empty, and I have no way of deciding whether the field needs an update or not.

Updating the field and only the field rather than loading and saving the whole node makes good sense. It's just the lazy programmer's easy way out... I have had no problems with my databases, but sure the routine will draw a lot on the database when running. A cron job could partly solve this, spreading out the load over time, but ideally it should only touch the field(s) in question.

Updating the field data for every node when the field changes or when touched through a view is probably impossible in my case, since we are talking massive numbers of nodes, and this update would take a lot of time, and not be welcome (or even feasible) when working with the content type or a view. I have not implemented #54 in my own current version of the module.

The module should enable pathauto when it exits under controlled circumstances, but when you manually exit it while it's running, I fail to see how it can do so. I could provide a cancel button or link, that made a controlled exit possible.

I may consider trimming the module so that it only touches the computed field(s) and not the whole node. A way of exiting in a controlled manner is also a good idea.

Martin

Hi Martin

You are right about that "update only when the calculation results in an different value" issue. There are some cases where this might be unexpected behavior. Maybe you should give an "Update field only when values differ" checkbox. I think in the majority of the cases the update is only needed when the value actually changed.

I would do something like

if oldvalue == computednewvalue() then DoNothing.

Updating only the computed_fields is also an excellent idea.

I would also appreciate an working cancel button, because the current one only reloads the page, which results in an "hard stopped" refresh, which leads to an disabled PathAuto.

Looking forwards to an new version of your helpful module :)

With best regards
Mario

Here is a revised version of the #55 patch, with the following enhancements:

• Also works when using a $db_prefix
• Cleaned up to validate against Coder 6.x-2.0-beta1
• Unix line endings

Works fine for me. Can it be committed please?

Not sure you want to limit this to one content type since a field can be shared between content types?

Yes, you are right. Though I did only test it when a field was defined only for one node type.

In addition, the patch needs work for the case the computed field has just been added and it is set to be stored in the DB. At that time, the new column does not yet exist.

roball,

I have no ownership over this small module, which lives here and no other places as far as I know. I'm fine with the changes, but have no idea how to formally commit them or the module as a whole. I can implement the changes in my current and newest version, tidy the whole thing up and upload the complete module here for people to fetch and use.

PS: I first saw the recent comments about fields in use for several content types after having posted the first version of this entry. It would make the module slightly more complex to check for such dependencies and warn or handle accordingly. My own use has only been per content type. I can also see the problems stemming from fields not yet added "physically" to the database.

Martin

Seeing some progress for this module would indeed be very useful. However the patch posted by me at #62 needs further work first, to avoid error messages the first time the fields are created. Also I would add a Drupal message after successfully recomputing all the field's values.

I have changed module from #48.
Module woks fine. Thank you.
Now nodes can be updated but changed date is not modified so nodes will not have red "updated' tag.

I think this module should be relesed as a drupal project but name should be changed.
May be "node_update" or something like this.
I can release it later if no one do it.

Duplicates. Sorry

Sorry. I didn't saw a 4th version in #53
Did the same changes as described in last comment for version from comment #53

PS. But not all nodes was updated.
Total: 1827
Updated: 1811
This is not depend on how many nodes updated at one time.

subscribing

ps module is cool! can we get a shcedule/cron setting feature?

in the meantime i'm using code from #9 as a view header, which is working nicely tho bit concerned if huge number of nodes... hence wld be nice to cron at 2am or whatever for a daily regenerate

hmmm... the code from #9 causes the node "touch" issue (ie everything gets updated) so i stole some code from Vlads module (thanks!) to get this (as php code input on views header):

$res = db_query("SELECT n.nid FROM {node} n WHERE n.type = 'YOUR_CONTENT_TYPE_HERE'");
while ($n = db_fetch_object($res)){
   $node = node_load($n->nid);
   $node_changed = $node->changed;
   $n = node_save($node);
   db_query("UPDATE {node} SET changed = '%s' WHERE nid = %d", $node_changed, $node->nid);
   
}

seems to work a treat! thanks guys this was a life saver, i finally can get print module click stats!!! :-)

Good people,

I will try to gather all the updates and patches to this specific module and incorporate them into one. The patches to the computed_field module will have to be handled by someone else - if at all.

I am also working on a cron-enabled incarnation of the module, but the task is a bit more complex than it appears at first sight since the cron run has to be controlled for potentially several different node types (unless we want to have the module run one node type only until done with that). I also need to change the main form so that you can select a cron run rather than a manual run.
As far as I can see we also need to be able to check a type in as well as out for cron runs, so that the process can be controlled for individual node types.

But I'm on it and may finish the job one of the coming days. Just returned from a small holiday and need to get back in gear...

If some one wants to commit the module after that, feel free. Haven't done that sort of thing before. I will most likely rename it to regenerate_nodes to have a more descriptive name. I think that it's better than update_nodes, but am willing to listen if others have different opinions.

Martin

nice work - agree on your thoughts about cron details required, good luck! keep us posted so we can help with testing, i'm sure this will be handy for loads of ppl when ready

When you make a new version, please add the regenerate_perm() function that was present in the original version (see #3). Without this function only user 1 is able to access the "admin/content/regenerate" path.

Alternatively, the "access arguments" could be changed to "administer nodes" in the regenerate_menu() function.

+1 to get #62, http://drupal.org/node/195013#comment-3162296 in!
Off course looking at the comment of #63.

I noticed this thread has seperate issues, just try to structure things, sorry if thats not ok:
- regenerate module, would be great if this would have it's own project page, so issues can be placed there
- views specific code, to get a view working using cck computed-field
- computed-field patch #62 (this thread is supposed to be for this issue, right?)

EDIT,
1) I patched computed field with #62
2) I saved the contenttype with computed field in it
3) I saved again the nodes of this content type, changed some values so computed field needs to be calculated again
4) I emptied my cache
5) Still no computed-field showing in views..
6) On the nodes of the content type with computed field, the computed field is shown, so there is a value in..

greetings, Martijn

@#75: I suggest looking at the nodes' rows in question via phpMyAdmin. If the rows' values have changed, then the recomputing worked.

Increasing the priority since this is really essential. An update mechanism that can be triggered via cron (or in general on the shell) would be needed as well. Otherwise this module's functionality is incomplete, unfortunately.

#69 does not regenerate very first nid.
For example, i have nodes with ids: 1,2,3,4,5 — module processes only 2,3,4,5; when first node deleted (1) — only 3,4,5.

Subscribing

+1

Regenerate module produces an error when PostgreSQL database is used. This is because "LIMIT a,b" syntax which is not supported by PostgreSQL. "LIMIT b OFFSET a" syntax is supported by both PostgreSQL and MySQL, and when patched like that, the module works.

The reason regenerate.zip does not regenerate the first node (see post #78) is because db_result() is called before starting to process nodes. This is probably a misunderstanding from the authors part on what db_result() does: it fetches (and removes) one row from the result set ( http://api.drupal.org/api/function/db_result/6 ); this seems completely unnecessary.

Attaching my version with this fix and also the PostgreSQL fix of post #81.

Wow, this thread goes back 3 years, covers a variety of uses, has code developed as a separate module, and more!

Can some sum up what this "regenerate" module does/offers that Views Bulk Operations doesn't?

VBO allows for simple bulk node save (to trigger computed field value computations) and works with the Batch API and Job queue for large sets. It can also use Rules to create custom actions and call bulk operation views programmatically now apparently.

Also remember that "display" code in a computed field is *always* run before display. This can be used in magical ways for some needs and can be disastrous if mis-used :)

Marking this to "normal" as I think VBO covers what most people are trying to achieve. Or am I wrong?

Subscribe. Hoping that someone eventually builds this functionality (dynamic updating of the calculated field while still allowing it to be stored in the database and thus usable by Views) into this module.

Again submitting a new version of regenerate module. This includes what I posted in #82
, and also has the following fixes:
* My PostgreSQL fix in #81 broke the same query on MySQL. Fixed that now.
* Added hook_perm() implementation, so that 'administer regeneration' permission now shows up in Drupal "User permissions" page

I agree with Moonshine that such a module is not needed since it can be done with VBO.

subscribing

subscribing

Sorry to throw a spanner in the works, but will bulk executing node save trigger modules such as Subscriptions to send out update notifications to users subscribed to the node?

subscribing

Just thought I would chime in here since I had to revisit this issue again recently. I have taken several approaches to this problem, a drush script, plain ole php script and vbo. For me, I have six computed fields, all of which are posting to Zoho reports, which appears to take some time. I am not sure if the complexity of those fields is what is killing me, but VBO is not efficient enough for this. At this point I have to throttle my saves at about 200 per run, otherwise I run into all sorts of server & browser issues. With several thousand nodes, this is a pain. Not an inconvenience, but a pain. It took me 5 hrs last week to do for 3800 nodes.

The regenerate code is a step in the right direction. I wouldn't say this(thread in general) is necessarily a computed field issue, but I definitely need to have a more efficient process than VBO. Ideally, I would like to update only select computed fields in my content type, for example, I do not need to recompute a value for 2009 dataset. I have that number, it isn't changing. So that is one thing I am going to look into doing. Also, what if there was an option to 'compute this field on cron run' and then a cron hook that did just that? This way, I can just create a field and let things just happen.

Just my two cents and experience with this issue. If I do get around to putting together something, I will update here.

Have a great day everyone.

Folks,

This has been stale for a while, and I haven't had the time or been in the mood to follow up.
Luckily this is Drupal, and the train doesn't stop because of that.

An interesting contrib module is finding its shape here:
http://drupal.org/sandbox/frakke/1079758
Computed Field Tools seems to have what we need plus other tools to use with computed field.

So I rest my case and follow the development of this module--oddly enough done by a Danish developer located no more than 15 minutes away from where I am right now. Small world.

Martin

I also need to do this and will check out computed_field_tools, as it looks like a simple solution to the issue, and I don't have any special needs other than updating all the nodes.

Thanks everyone for all the contributions to this issue. Makes our lives easier.

I just added http://drupal.org/project/computed_field_tools which can handle the re-computing of selected computed fields for selected content types.

The Computed Field Tools Module solves this problem, doesn't it?

both #28 or http://drupal.org/project/computed_field_tools can be used to solve this issue.

See #1262820: Merge Computed Field Tools into Computed Field for the issue to move that additional module into this one. As a maintainer of Computed Field, I think it should be included in the main module.

As a workaround you can use Views Bulk Operations. Select nodes, set action to "Change value", select the computed field, click "Next". That's all.