Jump to:
| Project: | Computed Field |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
This is a wonderful module and system. I've been using drupal for a few weeks and love it.
I'm developing a financial analysis application and it has a good amount of fields. In one create content node, there are:
37 data input fields (not that many if you were doing a survey)
23 simple calculated fields (add field 1 and field 2, divide by 100, etc.)
12 calculated fields based on calculated fields (add three previously calculated fields together, etc.)
all running smoothly. until i started getting a "division by zero" warning upon saving a node. I can see in the display that a number of calculations are not complete (still zeros). Now, if i just toggle back to edit and save again, the form completes fine w/out errors.
Later, if i change a number, i need to save, toggle edit again, and save again for all the computations to take place.
I've started deleting fields going backwards to see where the limits are but i'm now well smaller than when it was working a few days ago.
please help...thanks,
/TL
Comments
#1
Oh.
Drupal 6.9
Mysql
PHP 5
No multi-value fields
most fields are formatted decimal, a few integer (for select lists of numbers)
fields are mostly grouped, but there are calculated fields that are at the end of the field list and outside of any field group.
#2
i copied each field to a new content type and created a record. I got to the last field and it all worked. So I'm not sure what's going on. The same set of fields are in the old content type and still the node is saved before it's finished computing. anyway, i'm closing this support request.
#3
I too have been experiencing this issue (computed fields aren't being updated until node is re-saved) and have found the cause of the problem: the computed field's 'weight' value.
I started looking into this and discovered that my computed fields were being calculated in the wrong order (i.e. 'Grand Total' then 'Total1', 'Total2' ,etc.). I then spent the new few hours trying to work out how the order of field processing was determined (since it didn't seem to be top > bottom as per the node-edit form). After much to-ing and fro-ing through CCK's API documentation, I found out that the order fields are processed in is based on their 'weight' value, specifically: a field's 'weight' (asc) then 'label' (asc) taken from the 'content_node_field_instance' database table.
Knowing this, I then had a look at the weight of my computed fields (had to turn off javascript) on the 'Manage fields' page of my content type. Sure enough, my 'Total1', Total2', etc. fields had higher weights than my 'Grand Total' field since they were in a group (even though they were located before the 'Grand Total' field).
I therefore manually edited the weights of my computed fields so the first ones had a lower weight (-5, -4, etc.) and the last ones had a higher weight (3, 4, etc.). This did the trick - now my computed fields are all working properly the first time I save, I don't have to re-save the node multiple times.
Here's an example of my field weights before I changed them (when they weren't working):
Field | Weight-------------|-------
Title | -5
Work (Group) | -4
Hours1 | 1
Rate1 | 2
Total1 | 3
Hours2 | 4
Rate2 | 5
Total2 | 6
etc. |
Grand Total | -3
And here's an example of my field weights after I changed them (when they started working properly):
Field | Weight-------------|-------
Title | -5
Work (Group) | -4
Hours1 | -5
Rate1 | -4
Total1 | -3
Hours2 | -2
Rate2 | -1
Total2 | 0
etc. |
Grand Total | 5
Ideally, we shouldn't have to go through each of our computed fields and edit the weight for this to work properly.
I'd therefore like to request that this module implement a solution that allows it to calculate the computed fields in order from top to bottom (of the 'Manage fields' page) regardless of whether they're in groups or not.
Until then, the solution of manually editing field weights should fix this for people experiencing this issue.
#4
Marked #703666: Multiple node saves required for many computed fields in one content type? as a duplicate of this issue.
#5
Marked #1042816: Computed field not updated when adding to Multigroup table. as a duplicate.
#6
Don't think this helps my issue:
I have a node divided into tabs. One tab contains several fields in a multigroup table.
Another tab contains a computed field which has a count of the number of entries in the multigroup table. The computed code looks like this
$node_field[0]['value'] = db_result(db_query("SELECT count(*) from content_field_amend_no where vid = %d and field_amend_no_value is not null",$node->vid));
When I add another entry to the multigroup table and save the node. The computed field is not updated. I realize that the multigroup fields are kept in separate tables, but aren't they part of the same "node"? A new version is created, why isn't the computed field updated?
If I re-edit the node and save, the computed field updates correctly.
The weights of the fields in question are below
Each amendment multigroup contains:
field_amend_no 13 | Amendment #
field_amend_date 14 | Amendment Date
field_amend_comm 15 | Amendment Comment
The computed field is:
field_amend_count 79 | Count of Amendments
I also checked the weight of the groups in content_group.
multigroup group_amend_det 4 - holds the amendments
standard group_character -2 - contains the computed field.
So I changed the weight of group_character to be higher than the group_amend_det - but that didn't work.
#7
subscribing
#8
I'm attempting to use the suggested method of weighting fields in order to force the correct order of calculations, but without success. I'm using "Computed Fields" for a content type "Loan". There are a number of charges associated with a loan that are categorized and summed, which then roll up to a "Total Charges" field. As an example, you have:
Items Payable (5)
Application Fee (3)
Appraisal Fee (4)
Title Charges (8)
Title Insurance (6)
Title Examination (7)
Total Charges (9)
As part of the implementation, "Items Payable"=("Application Fee" + "Appraisal Fee"), "Title Charges"=("Title Insurance" + "Title Examination") and "Total Charges"=("Items Payable" + "Title Charges"). Items Payable, Title Charges and Total Charges are all field type "Computed", while the others are "Float". I've weighted the fields as shown in the parentheses.
When I save the content type and go to add "Loan" content, I input "Application Fee", "Appraisal Fee", "Title Insurance" and "Title Examination". When I save the content, Items Payable and Title Charges are summed correctly, but "Total Charges" remains at "0". In order to get Total Charges computed, I have to go back and re-save the content a second time. After that pass, the numbers are all calculated correctly.
What am I doing wrong? Why is this taking multiple saves to yield the correct results?
#9
Having the same (multiple save required) issue here. I've got 5 computed fields that are pulling data from the Title field, all fields are weighted correctly (title is heavier than the computed fields).
I've tried grouping the computed fields, I've tried moving _computed_field_compute_value() from 'update' to 'presave', I've tried hook_nodeapi()-fu to perform a second node_save() and I'm really at a loss. Why do I need to save twice to get any of my computed fields to actually compute? Help!
Edit: nevermind, you can't use the title field by doing drupal_get_title() because the title isn't saved yet, probably. Solved the problem by adding another (non-title) field and referring to it as $node->field_field_name[0]['value'] and it works well.
#10
As indicated in #3 I disabled JavaScript in EDIT [CONTENT TYPE]=>MANAGE FIELDS so I could see the weights:
Original Weights
Group [20]Item A [22]
Item B [23]
Item C [24]
COMPUTEDFIELD [14] (note, not in group)
Otherfield [5]
Otherfield [6]
Attempted remedy: Set COMPUTEDFIELD to [25] weight
After save though, CompField was now at the bottom of the page, since it is now the heaviest:
Group [20]Item A [22]
Item B [23]
Item C [24]
Otherfield [5] (note, not in group)
Otherfield [6]
COMPUTEDFIELD [25]
In order to get it in the correct place, I had to set ALL of my weights again starting at the top.
Group [15]Item A [16]
Item B [17]
Item C [18]
COMPUTEDFIELD [19]
Otherfield [20] (note, not in group)
Otherfield [21]
Some of the fields of my content type were added later ... and rearranged. After looking at it all ... it is obvious that the Drag-and-Drop rearrangement did not update the weights.
So, is it possible this is partly a flaw with the javascript Drag-and-Drop functionality (with the + Cross to grab) and that it should be setting their weights after reordering them?
And, where is the "Display Order" code that the "grab and move" functionality implements? Is there a good reason that weights are not updated after JavaScript rearrangement?