With #1696640: Implement API to unify entity properties and fields being committed every "property" on an entity is called a "field" now. Once everything is converted to use that, most code should rely just upon the Entity Field API. However, still some code will have to work specifically with field.module fields, i.e. fields that can be configured via the UI (and so extend the entity).

Some suggestions for this were:
- configurable field
- dynamic field

Fields defined by the entity type are right now called "base fields", other suggestions were
- pre-defined
- static
- intrinsic

Also, the 'fieldable' key in hook_entity_info() could be need renaming. E.g. to 'extendable' or 'configurable'.


fago’s picture

Title: Agree upon terminology for entity fields » Agree upon terminology for configurable fields
fago’s picture

My current favourites would be:
"configurable field", "configurable" entity types (instead of fieldable) and "base field".

andypost’s picture

Suppose configurable is not suitable here because of configurables (ConfigEntity) which would lead to misunderstanding
Extendable makes more sense

fago’s picture

True, I've not thought of that. Given the high potential for confusion, I agree this is a dealbreaker for configurable.

fago’s picture

New suggestion:
"configurable field", "extendable" entity types (instead of fieldable) and "base field".

So if an entity type is extendable, you can configure additional fields for it.

tim.plunkett’s picture

The term "configurable" is not used at all by ConfigEntity, that's "configuration entity".
We just still use it in issue tags for legacy reasons, but we can update those.

YesCT’s picture

When this gets resolved, there will be something todo related it #1498674-82: Refactor node properties to multilingual.

Pancho’s picture

Another problem with "configurable fields" is that the other ones - formerly known as 'properties' - to some extent are to be configurable as well. As effulgentia put it in #1188394-50: Make title behave as a configurable, translatable field (again):

the goal for D8 is for properties to have all the capabilities that fields currently have, and for the only thing that is special about fields is that they can be created/removed by administrators.

It is debatable whether storage might be an additional distinction. At least currently, 'properties' by default also live in the {entity_field_data} table (label) resp. for nodes in the {node_field_data} table (title; uid; status; created; changed; comment; promote; sticky). But even that distinction might be blurred at a later point, see fagos comment #1346214-1: [meta] Unified Entity Field API.

So IMHO we need to make clear what exactly we're talking about:
Properties like 'status', 'created' or sticky clearly are properties. Technically speaking, they will be translatable but not very much configurable. 'Title' is less obvious - it will be both translatable and to a large extent configurable.
The ultimate distinction remains IMHO, that 'properties' are fields that are "hardcoded" by the entity and that might live in the main {entity_field_data} table or not. Even if they might be more or less configurable, their configurability is limited by the entity definition and at least they might not be completely removed by configuration resp. the admin.
Whereas 'fields' are configuration resp. admin defined fields that always live in normalized tables as managed by the Entity Field API, and which are always fully configurable and removable.

So the distinction is rather small and blurred, so we need to figure out where it is needed at all.
UI-wise it should be enough to state that on a specific property some aspects of configuration are "locked by the entity definition".
Code-wise, I'm not sure, two separate terms would cut it, because if we look at title vs. created, we need to be even more specific regarding what can be configured on a specific 'property' and what can't. While 'title' can be reordered with the other fields, 'status' or 'created' aren't even listed or displayed.

We could possibly reflect this variation by sticking with 'property' for the latter 'real properties', call fields like 'title' an "entity defined" field with limited configurability and our regular fields "configuration defined", fully configurable fields. So there were three categories with a terminology that unfortunately isn't very concise, but - if I get everything right - at least very precise. :)

yched’s picture

Technically, changing the weight or visibility of a "base field" is not configuring the field itself, since display / form settings live in EntityDisplay and EntityFormDisplay objects.
So the "base field" themselves are fully non-configurable. The things that get configured are stuff that "talk about" the fields, not the fields themselves.

I agree that the distinction "what is part of the field definition itself, vs. what is part of EntityDisplay and EntityFormDisplay config entities" is mostly abstracted away when you look at the UI.
But the "Base field" / "Configurable Field" terminology lives primarily in code, and would probably not surface in the UI anyway.
So the terminology agreed so far still makes sense IMO.

Pancho’s picture

That's true, at least code-wise, form and display settings aren't relevant. So what is remaining to be non-configurable for all 'base fields' are the field type and aspects like number of values and maximum length which obviously need to stay locked for 'base fields'.
Translatability however has to be configurable at least for some 'base fields' (title), so it can be no distinction between 'base fields' and 'configurable fields'.

effulgentsia’s picture

Properties like 'status', 'created' or sticky clearly are properties.

I'm actually not so sure there's a meaningful difference between node.created and node.title in terms of how property-like vs. field-like they are. Per #1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title, node.created is formatted and displayed, just like title. However, I agree that we might want to consider a meaningful distinction between the stuff currently stored in {node} (e.g., nid, vid, type, landcode, uuid) and the other stuff currently stored in {node_field_data} (e.g., title, uid, created, sticky, etc.). And among the latter group, maybe there's some important difference between some of them (e.g., 'status') and the others. But if so, what is that important difference? Very related to that: #2010930-2: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title). Please provide feedback there to help on that issue, and maybe in the process, we can gain clarity into this issue.

fago’s picture

We discussed terminology quite a bit during the entity storage discussion in Prague, see the notes here. However, we did not move away from the "base field" and "configurable field" terminology, but clarified that base field vs configurable field is not necessarily the distinction to make.

Instead, the idea is to clarify the providing module + who is responsible for storing the field in the field definition. Relevant part of the notes:

module’ - This key is used to tell which module provides the field defintions, base fields have a NULL value; Configurable fields will have ‘field’ - so this can be used by the Field module to identify its fields. Then, this key allows us to identify base fields (=fields provided with the entity types) as they have a NULL values. Lastly, it’s something important to have in order to be able to track dependencies, e.g. when a module is configured to rely on a field to be there (a rule configuration needs it to run, a module uses a token of that field, ..).

This indicates whether the storage controller should take care of storing the field values.
The core SQL storage controller has a getBaseStorageFields() method that returns a list of fields to be stored in the base table (optimized) storage. Any oyher field, except custom storage fields, gets CCK tables.
By default the getBaseStorageFields() returns the names of the base fields, so this are the fields will get stored in an optimized way.
This optimization is something internal to the storage controller, so the method is not on an interface.
A MongoDB storage controller would just store everything marked with

fago’s picture

lpalgarvio’s picture

hum, what about "Custom fields" and "Base fields"


so it would be:

"Custom field", "Extendable/Configurable entity type", and "Base field".
as per https://drupal.org/comment/6627784#comment-6627784

yched’s picture

I think we're done here ?

yched’s picture

Issue summary: View changes
Status: Active » Fixed

No answer, temptatively closing :-)

plach’s picture

"Custom fields" vs "Base fields" sounds good here.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.