- Each call to
config() instantiates a new DrupalConfig object, and entirely new storage controllers, even though the storage controllers do not change and the behavioral logic of DrupalConfig does not change either; only the configuration object/data is different, but the object/data is not cleanly separated.
- The current DrupalConfig object is a mixture of functional "storage arbitrator/manager" logic and an attempt to represent the configuration object/data itself at the same time.
- The StorageInterface and DatabaseStorage are currently implementing methods, which enforce concurrent write operations to the database and file system. This logic does not belong into a storage controller; each controller should only care for its own storage.
- The current, parallel writes to the file system fundamentally break the intention of being able to import/export/synchronize configuration between the active store and file system.
- The code contains further synchronization methods, which are not used anywhere, and which won't be used by the actual synchronization implementation either.
- Cleanly separate the actual configuration object/data from the DrupalConfig storage manager as well as storage controllers.
- Create a ConfigObject class, which maps 1:1 to a configuration object. Return that from
config() and load each of those only once per request.
- Instantiate DrupalConfig and storage controllers only once per request.
- Clean up the StorageInterface to only contain actual storage controller methods.
- Remove the automated concurrent/parallel writes to multiple storages, since they would have to be re-implemented differently, but they ultimately conflict with the actually envisioned import/export/sync operation in the first place.
- Remove the premature synchronization methods.
- Implement a StorageManager class which arbitrates which storage controllers should act on each operation.
Original summary by @beejeebus:
currently, we create a new DrupalConfig object for each call to config().
this is slow and memory eating. we should:
- only load DrupalConfig once per request, and make DrupalConfig a site-scope object
- create a ConfigObject class, which maps one-to-one per config file, and only load each of those once per request
Follow up issues