The more I think about this, the more I believe that fields are an extra abstraction that is not necessary, now that we are developing entities seriously.

The problem is that what fields do overlap in many ways with what entities do. At least both systems make it easier to store chunks of data and wrap some functionality on how to deal with that data (crud). In my mind the only functionality that Fields bring to the table beyond what entities will do is the fact that fields are chunks of data that get connected to other data. But just because we have created this conceptual difference between entities and fields, any infrastructure created for the one will be useless for the other.

If we unify fields and entities where they overlap, I believe it would make them both better.

So how can we accomplish this? Each field could be their own entity type, and the connections between all these entity types can be managed with something relations-like. (I am talking about the relation contrib module)

I know that there are a lot more things that need to be thought about, but I just want to get some initial reactions to the idea.


joachim’s picture

> Multi-value fields, and complex fields should be their own entity, and the connections between all these entities are managed through relations.

My thought about this is that it would be effectively bringing database normalization into the structure of entities. But surely one of the useful things about entities is that they are an abstraction above the gory details of the database.

It seems it would be an awful lot of overhead just for something as simple as a multi-valued text field.

yched’s picture

Status: Active » Postponed (maintainer needs more info)

"unify Fields and Entities"
Er - sorry, wut ??

"The problem is that what fields overlap in many ways with what entities are"
Care to elaborate ? Fields are "parts of an entity", I don't see where we have an overlap, and the conceptual difference is very real.

Maybe what you're talking about is unifying fields and "non-field properties inside an entity", in which case this is what #1346214: [meta] Unified Entity Field API is about.
BTW - Field API will definitely *not* treat mono valued and multivalued fields differently. A unique, consistent data structure is critical, we don't want to litter the code with "if mono do this elseif multiple do that" all over the place. And you don't want your custom code to break when you change a field from single to multiple.
What you want is syntactic sugar to ease access to field values, and this is discussed in one of the issues linked in the issue above, but the underlying data structure will stay more or less the same.

Regarding the "unify Fields and Entities" part, please explain more precisely what you mean, cos right now I have no clue what this is about.

fmizzell’s picture


It seems it would be an awful lot of overhead just for something as simple as a multi-valued text field

What is the overhead of entities? An entity is a db table, an info array, a crud controller, and in the future a class that wraps the data from the db with some functionality. The Field System supports all of this, and MORE.


BTW - Field API will definitely *not* treat mono valued and multivalued fields differently

That is fine, that does not affect the overall idea. I believe the way I described is how CCK used to work, but I imagine that there was a lot of discussion on why single and multi value fields should be treated the same way, so I will leave this alone for now

Maybe If I give an example it would make clearer what I am thinking.

Lets imagine that there are no fields in Drupal. All we have to work with are entities with functionality similar to what is offered by core and the entity api module.

Ok, with just this functionality lets imagine that we want to create an address book, where we have Contacts, and each Contact can have multiple addresses.

With Fields we can create a Contact entity type, and then add a multivalue Address Field to one of Contact’s bundles. This would give us exactly what we need.

So how can we accomplish this with just entities? First we create 2 Entity types: Contact and Address. Each entity type defines the way they get display through some theme function or template, and how to create new entities through an input form. As we can see, so far we have been able to accomplish some of the functionality provided by Fields, without the Field module.

Now we need to connect the two entity types together. So we add a contact_id property to our Address entity type. As things stand right now, we can go to the Address admin page create a new entity, and connect it to a Contact through the contact_id property. Just from this, we can write a little code to add the Addresses to the Contact’s view and display them together.

That is great, but that is not how fields work. What we want to do is to be able to create, or reference Addresses at the Contact create, or edit form. So we write a little code with the help of modules like multiform or subform, and that’s it. Now we have very similar functionality to what Field does, without using the Field module.

I know that I am oversimplifying things, but my point is that we can let the Entity System take care of certain things, so Fields can become more focused and flexible.

If things were to work as I imagine, with a little configuration, any entity could be treated as a Field of another entity type.

So in conclusion, what I am advocating for is for Fields not to worry so much about storage, input, and display (Entity System), or even settings (CMI can take that out of the field dbs) and concentrate more on the relation part of the whole Field infrastructure.

Sorry for the long post, I hope it makes things clearer.

fmizzell’s picture

Issue summary: View changes

Got the single vs multi value field stuff off the summary after getting some feedback from yched. This is not important to the overall idea

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.