Originally (like a year ago), "field settings" were those things which affected schema and could not be changed except by a mythical "field conversion" system and "instance settings" were the lightweight things that could be changed at any time.

Later, we realized that some things should be field settings so they are inherited by all field instances even though they do not actually affect the schema. "Allowed values" for a list field is the standard example.

While discussing taxonomy as a field at the DCDC code sprint, we realized that even though changing some field settings would not affect the schema, they would still constitute an expensive operation. For example, suppose a list field changes its "allowed values" by removing some of the allowed keys. The site may already have data items for that field in the database that use the removed keys and are thus no longer valid (they would not pass field validation). In the taxonomy case, if a taxonomy field indicates which vocabs are allowed, and that changes, existing data items may then contain terms from a vocab that is no longer valid for that field.

This leads to a situation in which we need:

1. Field settings that cannot be changed except by a field conversion process. These include schema settings and anything that affects what constitutes valid data for the field.

2. Field settings that can be changed. Given the "valid data" constraint, are there remaining known use cases for this?

3. Instance settings that can be changed, like "required" and "weight."

If the Field API is going to support 1 and 2, then it also needs to provide some way to differentiate between them so the UI knows what to display on a field edit form.


bjaspan’s picture

I am bothered by this whole setup. I do not like this semi-inheritance of settings. It seems complicated to have fixed field settings, changeable field settings, and changeable instance settings.

Proposal: If we really do need to support field settings that can be changed, then do we need instance settings AT ALL? Can an instance can be nothing more than binding a field to a bundle, with no other options? This would mean that required, weight, and all the other instance settings would become field settings, so the same for everywhere a field is used, though they can be changed easily. I'm sure someone will scream, but are there real uses cases for a field that must be shared between content types and must have different required/weight/label/description/etc per content type?

Frankly, is there a legitimate use case for shared fields at all?

yched’s picture

"are there real uses cases for a field that must be shared between content types and must have different required/weight/label/description/etc per content type? Frankly, is there a legitimate use case for shared fields at all?"

Sadly, I think the answer is 'yes' on both accounts...

Different settings per instance :
weight, for instance, *has* to be different per instance, since the weight only makes sense amongst the other weights of other fields in the bundle. weight '3' means nothing at all.
'required' : well, there was more than one practical occasion where I wish CCK allowed that (after battling that, no, it rightfully didn't)
widget type and formatter type also are precious on a per-instance basis. And then you have the widgets and formatter settings...

Use case for shared fields at all? :
Er, what becomes of 'body as field' ? 'upload as filefield' ? :-)
Even without the above, which are only 'hopefully forthcoming great D7 additions', yes, life is *much* more difficult without shared fields. Views is less much powerful without shared fields.
And that was one of the main key points of CCK vs flexinode, btw.

KarenS’s picture

The usual use case for shared fields is something like a phone number field where you want to have a single phone number table that stores all phone number in one place for ease of use in Views searches and elsewhere, but may want to attach the field to very different content types, like an individual type and a corporate type that may have totally different fields. Or sharing a telephone field between a node contact record and a user (now that we can put fields on users).

I guess you could still make a point that it's not *necessary* but that is one situation.

bjaspan’s picture

Unfortunately, yched's answers in #2 are compelling.

Michelle’s picture

I have a lot of node types and most of the fields are shared. For example, my directory has types for business, restaurant, church, lodging, store, medical, website, general, and non profit. All of those have fields for description, URL, email, various phone types, and more. As was mentioned previously, having a different field on each of those node types would be a nightmare in views.


KarenS’s picture

I missed the conversation about not changing allowed values because removing values might affect existing data. I agree that removing or changing values that exist in the data would create a problem, but adding new values or removing values that are not in use is not, so *some* changes are safe there. It seems heavy-handed to disallow even changes that won't break anything.

Also cardinality still, I think, fits the qualification of being a field value that can be changed without breaking anything. And I'm sure that more complex fields will have others, we can't pull our only use cases out of the few simple fields we have in core.

yched’s picture

Well, taxonomy currently doesn't clean up the taxonomy_term_node table when a vocab gets unapplied to a node type. Stale data remain in the table, it's just not displayed any more. Do we need to do better than that ?

bjaspan’s picture

Well, we're trying to do better about not orphaning data on delete (though it isn't implemented yet and each time I think about how to do it I end up hitting a wall). We want to actually enforce field validation during field_attach_insert/update(), whereas node.module only checks anything during form validation. So, I'd *like* to be able to say that field validation is always ensured for field data items. But maybe I'm just being pedantic and it is completely unnecessary.

sun’s picture

Version:7.x-dev» 8.x-dev