Steps to reproduce :
- create a multiple, non required field (number, text, whatever)
- create a node with 'foo', 'bar', 'baz' for this field
- look at the db table for this field :

delta    value
0        foo
1        bar
2        baz

This is OK

- edit the node, empty the second value ('bar'), submit
- the node view looks like it only has the two values 'foo' and then 'baz'
- look at the db table for this field :

delta    value
0        foo
2        baz

There's a 'hole' in the delta suite
I think the 'baz' value should be shifted on delta 1 - and it will on next edit :

- re-edit the node : 'foo' and 'baz' are indeed in the first and second textfields
- submit _without changing anything_
- look at the db table for this field :

delta    value
0        foo
1        baz

'baz' has shifted it's delta position - yet you did not change anything in the node edit form

Comments

dopry’s picture

dopry commented

There is a delay in the renormalization of the deltas, until the next time both columns are emptied... The actual delta isn't so important as the order of the items... This is a sort of lazy gc for unused deltas. Should we consider this a bug and why?

dopry’s picture

dopry commented
Status: Active » Postponed (maintainer needs more info)

There is a delay in the renormalization of the deltas, until the next time both columns are emptied... The actual delta isn't so important as the order of the items... This is a sort of lazy gc for unused deltas. Should we consider this a bug and why?

yched’s picture

yched commented

I agree this is not really a bug from the user's point of view.
Yet I still think this is not really clean. Having the structure of your content changed on node re-submission without the user altering anything (step 3 in my original post) is weird. Having "holes" in deltas seems weird as well (even if no bugs came out of this so far).

This "sort of" gc does not currently seem like an intentional feature, but rather a side effect of the code used in most field modules to fill-in form values. I think this gc should :
1/ be made a "real" feature
2/ on node submission time (step 2 in my original post)
3/ be done in content.module and not depend on contrib field modules (ensure homogenous behaviour for multiple values)

I intend to work on a patch when I have more time in a few days. Open to discussion meanwhile :-)

Egon Bianchet’s picture

Egon Bianchet commented

I'd like to preserve deltas, ie keep holes, because I'd like to have a module to theme a set of multiple fields like a table. To get that to work properly I'd also need the delta to be respected in the actual form too, ie keep empty textfields between non empty fieldset

See also:

http://groups.drupal.org/node/1903
http://drupal.org/project/fieldgroup_table

yched’s picture

yched commented

Egon, I do not think this is specifically related to your fieldgroup_tables feature, but rather to the definition of multiple values we want to have. Fieldgroup_tables will just reflect what is possible or not with the CCK constructs.

So I guess we have :

Solution 1 : keep (and enforce) current "gc on empty deltas"
- Lets the user simply remove one value, and the subsequent values are shifted automatically
- Restricts the definition of multiple field as a list of non-empty values - maybe that's not a bad thing : we already deal with the notion of empty field. Do we want to have to deal with the (slightly different) notion of empty value in a field ? Not sure I do...

Solution 2 : allow empty values in multiple fields
- richer, obviously
- raises the question "how will these empty values be displayed ?". "Not at all" (as currently) is probably not the right answer. But then I guess this means an additional user setting ("empty", "-", "foobar"...)
- not sure all contrib field modules currently can manage this properly
- UI issues : makes removing an image in a multiple imagefield (for instance) quite a pain if you do not want the "hole" ("only" tiresome manual copy/paste shifting for regular text / number fields)

I guess Solution 1 has my preference right now, because I'm in a general "restrict the feature set and keep implementation solid" mood. But I can see use cases for solution 2 as well...

Of course, there's the solution of an additional checkbox on the field settings page allowing you to choose behaviour 1 or 2 for the field. Requires a new db column, adds complexity to UI (only valid for mutiple fields), code maintenance and issue debugging...

dopry’s picture

dopry commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

this will not be fixed in 4.7.x and has been addressed in newer releases of CCK.