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.|
|FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch profile2_exportable_update.patch.|
|FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch entity_exportables.patch.|