Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
field system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
1 Sep 2013 at 20:37 UTC
Updated:
29 Jul 2014 at 22:51 UTC
Jump to comment: Most recent file
Comments
Comment #1
berdirComment #2
berdirLooks like @catch already opened https://drupal.org/node/2078507, this is just about the first part then.
Comment #2.0
yched commentededit
Comment #3
yched commentedThis adds some tests. Note that the existing FieldSqlStorageTest::testLongNames() already tests a case for non clashing.
Also note that the moment DatabaseStorageController::_generateFieldTableName() starts truncating stuff, it also puts a hash of the field UUID in the table name, so there *really* can't be a clash - which is why I'm not multiplying test combinations here, there are not really combinations that make more sense to test than others...
Patch does change one thing: truncate the entity type at the same length for the "current data" and the "revision data" tables, because having the two tables at different prefixes is confusing.
Comment #4
berdirStill consider it a bit weird that we do that r/revision thing, I think in most cases, the problem will be long field names, not entity types name, so we'll end up with way shorter field names anyway. Anyway, don't care *that* much :)
A test for a deleted field would be nice, do we already have unit test coverage for that?
This would be a nice case for a PHPUnit test, where we could use a data provider for the different versions and mock the field object. That would however require that we switch to method calls for $field so that we can actually mock it and not too sure about splitting test coverage like that.
Comment #5
yched commentedNot that I care too much either, but If we keep _revision, we still want to truncate the entity_type to the same (shorter - 27 instead of 34) length for the current and revision tables.
But IMO we want to reconsider:
- not always creating the 'revision' tables if the entity type is not revisionable
so on non-revisionable entities, we'd truncate more than needed to account for a revision table that won't exist.
- maybe drop the separate revision tables completely, as several people pointed they are more a pain than a gain
[edit: opened #2083451: Reconsider the separate field revision data tables]
So I'd rather leave it as is here for now, and just add the tests for the current behavior :-)
Added a test for a deleted field.
Comment #6
yched commentedAlso: yes, a PHPUnit test seems out of reach for now.
Comment #7
berdirYeah, reading those expected outputs got me thinking again :)
Agreed, this issue is to add test coverage for the existing behavior, so let's get that in.
Comment #8
catchCommitted/pushed to 8.x, thanks!
Comment #9.0
(not verified) commentedformatting