Voting starts in March for the Drupal Association Board election.
Currently, entity API exportables defined in code are incorporated by the controller by getting the defaults from code whenever entities are loaded. However, there are some drawbacks with that workflow:
* The difference between db-centric insert()/update()/delete()/load() hooks for entities in code might be confusing, e.g. when an entity in code is updated, thus overridden hook_insert() is invoked - as it is inserted in the database.
introduces hook_entity_enabled/disabled to enable modules to detect new exportables, however with all entities in the db that won't be necessary at all.
* Applying conditions to entities in code has to be emulated in PHP, what doubles the functionality databases provide.
* As of now there is no EntityFieldQuery support for entities in code, thus an EntityFieldQuery would only return overridden/custom entities.
Disadvantages of storing all entities in code in the db:
* One could not just use t('label') for translated labels any more.
* Updates to entities in code won't be applied automatically any more. Maybe, just re-saving defaults on cache-clear like features suffices?
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entity_exportables_0.patch. View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch profile2_exportable_update.patch. View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entity_exportables.patch. View