SQL error adding computed field with more than one value

The problem is that the computed_field doesn't have any database columns, which makes CCK think it's the main node type table (content_type_<node_type>) and causes it to save the record once, before saving it again in the multiple handling code of content_storage().

The only way to stop it (short of getting a patch in cck) is having a dummy field.

Not sure I understand the issue here completely. :/

The OP is trying do a multi-value computed field which would involve setting values in $node_field[0]['value'], $node_field[1]['value'], $node_field[2]['value']... and having the computed field setup as a multi-value field. Is that what is being done? And with or without DB storage for the values?

It's been a while, but the problem is with multiple fields without storage. CCK does't quite understand fields without any columns, and while it works for non-multiple fields, it breaks for multiple.

If I remember correctly, there's some condition in CCK code that makes it save the field once in the non-multiple handling code, then it believes it handled the main per node type table, and goes on to attempt to save it again in the multiple handling code.

While that might be patchable in CCK, having a dummy field also fixes other errors (like the one the OP had when CCK attempts to fill the table of a newly added field).

Closing this for now as it's an isolated report AFAIKT. Certainly re-open if there is more info.

How can 2 unrelated reports be isolated?

Try creating a content type with a computed field with multiple values.

I'm certainly not trying to offend. I actually use a bunch of multi-value computed field arrays in a D6 site, although they are DB stored -- which unfortunately is the key here. :( That said, I re-read this issue and finally keyed into the fact that these are non-stored fields being discussed. Sorry I glossed that over, it's just not as popular.

You're correct, CCK is not comfortable without a data column for multi-value fields, but actually it's worse then that. While tracing things through, I noticed that CCK actually initially attempts to create the field in the DB *before* the user is presented with field configuration options. At that point we no nothing about the data type, so we're currently not giving CCK any data column to work with as well. Because of that, random SQL errors can pop up after configuration in a multitude of scenarios.

Soooo... I made a couple changes that basically ensure CCK always as some data column, DB stored or not. I *think* that will take care of things. Of course non-stored fields won't actually store data, but CCK has a placeholder and a column to "migrate" if the user makes changes to the field config. It's not ideal, but this is CCK and D6, so I'm not going to loose any sleep. D7 on the other hand, is going to take some further inspection now.

Really, IMO non-stored fields are of rather limited use at this point though. Considering the dummy DB columns we need for CCK, CCK node caching, and no Views support, there is little to be gained outside of not having any data in those columns. Although I suppose there are cases where that is important.

Thanks guys, the change was committed here and will show up in the dev package soon:

http://drupalcode.org/project/computed_field.git/commitdiff/7b8136e

Leaving this one open so people can see it if problems crop up from the change.

Sorry if I sounded grumpy.

Always having a database column probably fixes most of the breakage.

You're right, CCKs field caching is rather limiting the usefulness of non-stored fields. I was using it for displaying reverse nodereferences, but had to clear CCKs cache for specific nodes when saving the referencing node types.

As I see it, there's 2 usecases for non-stored fields: Adding large amounts of data (possibly from an external source) and data that needs to be calculated at load time. Only the first one really need to get around storing data at all, the second case just need to be able to update the data on load, regardless of whether the field data was cached. Not easily done in CCK, hopefully it gets better in D7.

Yep, not wanting to store any of the data is reason enough to keep the option around. But the problem is most people look toward the non-stored field option as a way to have a totally "dynamic" field value that's calculated every time the node is loaded for display. However, with CCK cacheing all the node field values in cache_content, the $op == "load" trigger in hook_field doesn't fire when the node is loaded. It's only triggered when the node is (re)saved. So, short of clearing cache_content, we're just left with $op == "sanitize" (that's triggered) and any display php code that's called. It seems that for most people wanting this "dynamic' field, their custom display code becomes their field calculation as well, and lets them achieve what they are after.

A while back I thought about letting "sanitize" also compute the value for non-stored fields, like it does currently for "previews". That would probably get rid of the most common questions/confusion about non-stored fields. However, I don't really know if that would cause repercussions for some people's computed code. It's hard to say when this whole module is based on people entering *custom* code ;)

FWIW, from I've looked through tonight, D7 and it's Field API still seem to share some of the same shortcomings re: fields without stored values. I'll likely have to put a dummy field in D7 just like D6. :/

confirmed, using more than 1 value does not work. if i chose unlimited, and save to db its not working. Not important for me but a little hint/doku/info would be great, maybe in the README file.

thx

Well, this bug was a SQL warning when saving nodes with multi-values on non-db stored computed fields. Both should be fine now. I just tested a multi-value db-stored computed field in D6 (using the dev release) here and it worked as designed. (db stored values and all were shown) So maybe you can elaborate, with your computed code, in a separate issue. Thanks..

Computed code I used..

$node_field[0]['value'] = "A value...";
$node_field[1]['value'] = "And another...";
$node_field[2]['value'] = "Yet another...";
$node_field[3]['value'] = "And one more...";

If it helps anyone, I was experiencing this issue. I upgraded to the latest 'dev' release and was still seeing the SQL warnings. I tried clearing the cache, but was still seeing the errors.

I was kinda lost, so I copy-pasted the example in #10 above and didn't see the warning anymore. So, I copy-pasted back in my original code and the warning went away for it as well.

My observation / hypothesis:
I noticed that there was a new column in the appropriate DB table now, so I'm assuming that editing the computed value field (after installing the dev version) caused the issue to go away.

I haven't tried to reproduce it though. If anyone else runs into this issue, HTH.

Due to the Drupal core life cycle policy and security support advisery, Drupal 6 is no longer supported. So issues for Drupal 6 cannot be longer maintained. The project maintainer has asked for closing all D6 issues to clean up the issue queue.