Problem/Motivation
As discovered in #2820848-64: Make BlockContent entities publishable, Content Translation metadata fields ('content_translation_source', 'content_translation_outdated', 'content_translation_status') do not use an initial value for entities that exist prior to enabling CT on an entity type.
This poses a problem if anyone needs to rely on that data for example when making an entity type publishable by adding a 'real' status field.
Proposed resolution
Make CT use an initial value (#2346019: Handle initial values when creating a new field storage definition) for those fields and fix existing inaccurate data.
Remaining tasks
Write tests.
Review.
User interface changes
Nope.
API changes
Nope.
Data model changes
Nope.
Comment | File | Size | Author |
---|---|---|---|
#34 | 2854732-34.patch | 10.07 KB | amateescu |
#28 | interdiff.txt | 986 bytes | amateescu |
#28 | 2854732-28.patch | 10.03 KB | amateescu |
#23 | interdiff.txt | 1.79 KB | amateescu |
#23 | 2854732-23.patch | 9.07 KB | amateescu |
Comments
Comment #2
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThis should do the trick.
We also need to write tests for the update function, but for that we need a new test database dump which is also required in a few other issues, so I will post a separate issue for it.
Note that the patch depends on #2346019: Handle initial values when creating a new field storage definition, so I'm just setting it to NR in order to get some initial reactions on it.
Comment #3
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedComment #4
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOk, now that we have the issue which adds new test db dumps, here's a test for this patch!
Now this depends on the following issues, so I'm posting a combined patch as well:
#2856808: Break out the 'entity_test_update' entity type into its own module and add additional test db dumps
#2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field
#2346019: Handle initial values when creating a new field storage definition
No interdiff because the only change is the added test.
Comment #5
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedAlso, there's no need for a test-only patch because we're introducing new functionality that cannot be tested without the other changes in the patch.
Comment #7
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOk, there are a few failures that need to be fixed but let's wait for some of the dependencies to land first.
Comment #8
jibranJust walk by review.
EDUM can be stored in a variable outside of the loop.
Should we use constants here?
Comment #9
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOnly one of the fails from #4 is caused by this patch: since content translation metadata fields always have initial data now,
TaxonomyTermViewTest
needs to remove all the nodes before trying to uninstall the CT module.Another fail is caused by me not using the latest version of the patch from the 'entity_test_update' issue, specifically the interdiff in #2856808-11: Break out the 'entity_test_update' entity type into its own module and add additional test db dumps.
And
ContextualFilterTest
was just a random fail.--
#8.1: Fixed.
#8.2: We don't have any constants to use there.
Comment #10
jibranThank you for addressing the feedback.
#8.2: I think
EntityPublishedInterface
should add those constants instead ofNodeInterface
and should be used here. Toughts?Comment #11
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@jibran, nope, we specifically designed
EntityPublishedInterface
to *not* have constants for published/not published. You can read the issue that introduced it for more details :)Comment #12
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedRerolled for #2860096: Remove api doc groups for updates eg. updates-8.2.x-to-8.3.x and all the dependencies.
Comment #14
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedI forgot to include #2856808: Break out the 'entity_test_update' entity type into its own module and add additional test db dumps in the combined patch. This is not even funny anymore :(
Comment #16
jibran#2856808: Break out the 'entity_test_update' entity type into its own module and add additional test db dumps is fixed.
Comment #17
jibranI think it is only blocked on #2346019: Handle initial values when creating a new field storage definition which is blocked on #2841291: Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field so postpone by 2.
Comment #18
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThis patch depends only on #2346019: Handle initial values when creating a new field storage definition now.
Comment #19
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented#2346019: Handle initial values when creating a new field storage definition is in!
Comment #20
timmillwoodStruggling to find any issues.
Comment #21
Wim LeersYeah, I don't know this code, but I have to say that this patch looks super solid :)
Comment #22
tstoecklerAwesome, thanks! Needs work for 3. only.
Minor, but you could avoid having to fetch the schema repository manually by doing
$entity_definition_update_manager->getFieldStorageDefinition()
. I don't feel strongly about this, though, so feel free to leave as is.Minor, but any reason not to put the initial value directly after the default value?
Let's use
TRUE
for the initial value, as well.Comment #23
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedRe #22:
1.
$entity_definition_update_manager->getFieldStorageDefinition()
clones the definition object and, tbh, I'd rather not have that overhead in a memory sensitive place like an update function..2. and 3. Sure thing, fixed :)
Comment #24
tstoecklerPerfect, thank you!
Comment #25
timmillwoodComment #27
Wim LeersThat seems to not work:
Comment #28
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThat's easy to fix ;)
Comment #29
tstoecklerNice fix. I thought whether the elseif-branch should get the same treatment, and I think it should. But I also found it strange that the conditions are set up differently - i.e. I would have expected the elseif to be
$initial_valu_from_field && isset($initial_value_from_field[$field_column_name])
. But that's a preexisting issue so shouldn't be tackled here, and, thus, maybe we should leave that entire branch alone. Not sure, so leaving at Needs review.Comment #30
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@tstoeckler, the
elseif
branch doesn't need the same treatment because the value in$initial_value_from_field[$field_column_name]
is provided by$table_mapping->getColumnNames()
so it is always a string containing a table column name, not an arbitrary value provided in code like we have for$initial_value[$field_column_name]
.As for why the
if
checks are different, that's becauseisset()
doesn't throw any notices when looking for an non-existent array key, which can happen with$initial_value[$field_column_name]
, but for$initial_value_from_field[$field_column_name]
we always know that the array key exists because the field types are the same so they have the exact same column names in their schema :)Comment #31
timmillwoodIt looks as though we're ready to go back to RTBC.
Comment #32
tstoecklerWow, thank you for #30!!! That makes a lot of sense, totally missed that the two are inherently different beasts. Awesome explanation. RTBC++
Comment #34
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedRerolled for the conversion of
TaxonomyTermViewTest
to a functional test.Comment #35
timmillwoodBack to RTBC then!
Comment #37
catchHad to double check drupal_schema_get_field_value() wasn't deprecated, it isn't. Issue for that is #2124069: Convert schema.inc to the update.update_hook_registry service (UpdateHookRegistry).
Patch looks great, couldn't find anything to complain about. Committed/pushed to 8.4.x, thanks!