Problem/Motivation
translation_entity.module keeps track of entity translations in its {translation_entity} table. For each translation it stores the entity ID, which it accesses by EntityInterface::id(), and tries to do so in a field of type 'int'. ContentEntities are fine with that, but ConfigEntities return their machine name, which results in a fatal SQL error, when it tries to save an entity translation along the lines of
Error message
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1366 Incorrect integer value
In order to reproduce this, turn on entity_translation.module and then in a second step turn on contact.module. That tries to save the default contact category and BOOM!
I filed this as major, it might be considered critical, but I didn't want to piss people off, and this should be a rather easy one anyway, so...
Proposed resolution
Change the SQL field to type 'varchar'.
Remaining tasks
Write tests. I don't think we need either an upgrade path or upgrade path tests.
User interface changes
-
API changes
-
Comments
Comment #1
tstoecklerHere we go.
Will now try to cook up some tests.
Comment #3
tstoecklerThat was luck, that it failed on checkout. The patch breaks because I failed to update the schema keys correctly. *slapsforehead*
Better patch coming up.
Comment #4
tstoecklerHere we go.
Also, I just found #1832000: Entity translation metadata should be stored only for translation enabled entities/bundles
Comment #5
tstoecklerWell, obviously the "tests-only" patch *should* be tested... (it's late...)
Comment #7
attiks CreditAttribution: attiks commentedLooks good, I'm uploading the patch from #4 to avoid confusion.
Comment #8
webchickCommitted and pushed to 8.x. Thanks!
Comment #9
tstoecklerThanks for the quick commit, but I don't think this was actually pushed...
Comment #10
tstoecklerSorry, here it is: http://drupalcode.org/project/drupal.git/commit/d65270d499b1c350e93521bf...
It seems the Drupal.org commitlog is cached in some way. Weird, I've never seen that before...