#1802750: [Meta] Convert configurable data to ConfigEntity system is tracking converting all configuration that has multiplicity into the ConfigEntity system. I.e., image styles, text formats, views, account email templates, etc. are all examples of things that different sites can have different sets of, which requires the "C" and "D" part of CRUD, and in general, fits the concept of entities (in the broad sense of the word, not the more limited D7 sense).

However, we also have configuration objects like system.site.yml, for which every site only ever has 1 of. So far, consensus has been that these should not be ConfigEntities. One of the consequences of that choice is that configuration translation requires a completely separate concept/implementation/API/UI than entity translation.

In #1648930-129: Introduce configuration schema and use for translation, fago says:

I could see the simple settings being each own config entity as well.

Let's discuss that in this issue.

Comments

effulgentsia’s picture

By the way, I'm currently leaning to "no" on this, because using the entity system for singular-only objects feels architecturally wrong and cumbersome. But I'm open to being persuaded otherwise.

sun’s picture

Category: feature » task
Issue tags: +Configuration system, +Configurables
  1. TBH, when I worked on the initial design of Configurables, I stayed rather silent about this, but actually played with the idea and thought through it.
  2. Translation is one possible benefit, Forms are another.
  3. Unlike what I guess is being proposed here, my thoughts have always been based on the idea of a single Settings config entity, which would be used for all config objects representing settings.
  4. A range of implications and consequences that Configurables have do not match up with settings though. There's no ID, there's no UUID, there's no label, they can only exist once, and only once, and only once with their name (not ID), and they must not vanish. In short, they are a completely different can of worms.
  5. They can be considered as entities, but definitely not as "config entities" a.k.a. Configurables, because they have zero things in common.
tim.plunkett’s picture

The 4th and 5th point in #2 are why I think this should be won't fix.

heyrocker’s picture

#4 is one of the keys to why this is bad, because settings files absolutely can not be deleted unless their module is uninstalled. The results of this happening are pretty catastrophic. I agree there aren't really any commonalities and this is won't fix.

sun’s picture

#2 only compares the two architectural concepts.

It does not imply that there couldn't be Settings next to Configurables.

tim.plunkett’s picture

@sun, we've continued to use "Configurables" as an issue tag, but it does not actually refer to anything in core, and I'm confused.

Settings next to Configurables

What are you suggesting? Another class, similar to ConfigEntityBase, also extending from Entity? Or reusing ConfigStorageController somehow?

sun’s picture

The differences outlined in #2 would clearly require a dedicated entity base class and a dedicated storage controller. Nothing inherited from the current Config\Entity* classes.

Settings would still be entities though, and they could re-use all the entity/property system facilities. They would present a sorta new term of "universally unique entities."

sun’s picture

To clarify further: The comparison in #2 left out what Settings and Configurables actually have in common:

  1. They have a langcode, because at minimum, default configuration ships in English.
  2. They have an owning module, because all settings are owned by some extension.
  3. They very potentially even have an api version, because available settings and their possible values can (and do) change over time.
  4. They are translatable.
  5. They can be managed through the UI via forms.

If you'd task me to do this today, then I'd probably investigate the following first:

  1. Introduce a new entity class Config\Entity\Settings extends EntityNG with accompanying storage controller (see #2).
  2. Introduce a new Config\Entity\SettingsFormController that handles a settings form.
  3. Seek a way to describe the properties being contained in the config object; super-potentially using the exact same way for describing properties of all other entities being used elsewhere. (consistency)
  4. Aim for making the Settings entity empty by design first. Pollute its properties via entity properties only. Push as much as possible "upstream."
  5. Only if that fails, consider introducing individual, inherited/derived, custom Settings entities à la UserAccountSettings extends Config\Settings and go the hard way.
effulgentsia’s picture

Title: Should singular config objects be ConfigEntities? » Should singular config objects be instances of a class that extends Entity?

Retitling accordingly.

fago’s picture

Also related: #1818574: Support config entities in typed data EntityAdapter:

A range of implications and consequences that Configurables have do not match up with settings though. There's no ID, there's no UUID, there's no label, they can only exist once, and only once, and only once with their name (not ID), and they must not vanish. In short, they are a completely different can of worms.

Exactly. In particulary that they exist only once and must not vanish is what does not make them very entity like.

ad #8: Sounds reasonable, but how to approach the mentioned problem?

I was thinking about something like that:
- Making "settings a single entity type with the settings name "module.settings.bla" being the entity id.
- If you load the entity it gets the default settings file, or a settings files containing the change if existing.
- When saving the entity, it writes a new non-default settings file.
- When deleting the entity, it deletes the changes file only - so load continues to work with the defaults. (revert)

That's my brainstorming on that, not sure that would play with CMI and whether we it's something we really should pursue... It would have some nice advantages for us though.

Jose Reyero’s picture

Hi, I was wondering whether there is any progress with this one, I mean one way or another a decission needs to be made, and maybe in the last month people have made up their minds about this. Or if not, should we toss a coin? ;-)

Also I am concerned about the implications this has for ConfigEntityBase and translatable properties in general:

  /**
   * Overrides Entity::get().
   *
   * EntityInterface::get() implements support for fieldable entities, but
   * configuration entities are not fieldable.
   */
  public function get($property_name, $langcode = NULL) {
    // @todo: Add support for translatable properties being not fields.
    return isset($this->{$property_name}) ? $this->{$property_name} : NULL;
  }

And btw, wondering whether we've got an issue created for that @todo.

This is also a major concern now the 'config/metadata/translation' approach for the locale system has somehow 'derailed'. So I'm wondering whether you guys have an alternate plan about this...

effulgentsia’s picture

I think sun's suggestion in #8 is cool in theory, but I chatted about it with chx, who brought up the point that a good number of our singular config objects have values that are accessed in performance-critical parts of the code. Wrapping those up in any further abstraction could be too costly. If someone wants to submit a patch for #8 that demonstrates how it's not a performance problem, then ok, but given the lack of work on this to date, my current guess is that this is unlikely to happen for D8.

This is also a major concern now the 'config/metadata/translation' approach for the locale system has somehow 'derailed'. So I'm wondering whether you guys have an alternate plan about this...

Well, chx is working on an idea in #1861640: Provide config metadata solely for translation, but I still haven't given up on #1648930: Introduce configuration schema and use for translation: contrary to #312 of that issue, I still really like the TypedData aspect of that issue, and am still exploring how that could be retained. If others here have other thoughts, please share them as well.

sun’s picture

a good number of our singular config objects have values that are accessed in performance-critical parts of the code. Wrapping those up in any further abstraction could be too costly.

My immediate and very simple answer to that would be to not use config entities when they are not strictly required.

In other words: Config entities are a high-level instrument to manage and operate on a particular config entity/object.

However, that does not inherently imply that anyone has to bootstrap a config entity to read a config object.

The contextual override logic upon read is handled in a different (low-level) layer of the config system anyway and is not tied to config entities anyway.

In short, read != write.

Perhaps a path to investigate.

heyrocker’s picture

Status: Active » Closed (won't fix)

It seems at this point that we aren't going to do this, which I agree with, so closing. Feel free to reopen if someone wants to get back into this topic at some point.