Based on #1498634: [meta] Define revision/translation SQL schema for core entities (no patch) there should be a new schema. The name should be users_translation it's connected to users directly.
Comment | File | Size | Author |
---|---|---|---|
#53 | 8.x-et-user-ml_schema-1498664-andypost-53.patch | 49.41 KB | andypost |
Comments
Comment #1
dawehnerAdd tags
Comment #2
Soul88Hi, everyone,
While thinking about the possible schema for users translatable tables I ran into a question: what are the possible use-cases when some user fields should be translated?
It seems to me to be a very specific demand when users need to have different username or password according to the language.
So the question is: do we really need to have 2 more translatable tables for users?
Comment #3
andypostAnother trouble with user schema that there's a 2 langcode fields -
langcode
andpreferred_langcode
Suppose only signature could be translatable and require "mirror-table"
Comment #4
Gábor HojtsyRetitle based on #1658712: Refactor test_entity schema to be multilingual. Marking postponed on #1691952: Make EntityFieldQuery work with multilingual properties.
Comment #5
Gábor HojtsyAdding mroe D8MI tags. This is still postponed now on #1818570: Convert users to the new Entity Field API.
Comment #6
Gábor HojtsyI think all dependencies have landed.
Comment #7
plachI thought we weren't allowed to address these issues after feature freeze unless we switched-in a new storage controller.
Anyway, related issue #2068329: Convert user SQL queries to the Entity Query API.
Comment #8
Gábor HojtsyYeah so long as there are no direct SQL queries, then changing the schema is not an API change.
Comment #9
plachThis is a first attempt, it won't probably apply as I rolled this from the #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions branch but it should be a good starting point.
Comment #10
plachComment #11
plachWe should refactor these to use an entity query + a SQL query for the session data. It's unfortunate, but we cannot assume user enetities will live in a SQL database.
Comment #12
catchI think we should look at taking that out of the session reading completely. Some of the session refactoring issues are also dealing with this.
Most of the time you only care about:
1. User is anonymous or authenticated
2. If authenticated, what the user ID is.
Beyond that, can always get the full user by loading.
Comment #13
plachMakes sense
Comment #14
plachAnd tagging for sprint to get more eyes on this.
Comment #15
plachRerolled
Comment #17
plachFixed session writing.
Comment #18
plachAnd this should fix views integration.
Comment #20
plachLast fix for tonight
Comment #23
andypostis wrong, should join on user field table instead
Comment #24
plach@andypost:
Actually it seems the join is no longer needed as a user load is performed just afterwards (I see the room for some optimization here ;)
Any chance you could bring this a bit forward? I will be pretty busy with #1498720: [meta] Make the entity storage system handle changes in the entity and field schema definitions these days.
Comment #25
andypostFix some views tables and reverted #20, because
uid & name
usedformatMessage()
latter@plach Yes, this could be improved but that's out of scope
Comment #27
andypostmore fixes
Comment #28
andypostmore views
Comment #31
andypostComment #33
andypostComment #35
andypost@plach I've no idea how to fix the left 2 tests, please take a look
1)
PathLanguageTest
- fails randomly2)
HandlerFieldUserNameTest
- somehow makes wrong relationComment #36
plachOk, I will have a look as soon as I can. Thanks!
Comment #37
andypostOnly
PathLanguageTest
leftComment #39
penyaskitoRerolled because of #2315237: Rename FieldDefinition to BaseFieldDefinition.
Comment #40
penyaskitoRun
PathLanguageTest
several times locally, and always got green.Comment #42
Gábor HojtsyProbably also needs to take account #2074255: Add changed time tracking to users now?
Comment #43
plachAAMOF in the latest patch
PathLanguage
is not failing :)Comment #44
andypostre-roll after #2074255: Add changed time tracking to users
Comment #45
jhodgdonThis all looks good. It's also blocking several other issues. And the tests are finally passing. So... let's get it in!
Comment #46
jhodgdonThis will conflict with #2319671: ViewsDataController: Step1: Move entity views data into controllers... not sure which should go first?
Comment #47
plachComment #48
plachComment #49
alexpottHow come and this does not look quite right. Since
$backtrace[0]['line']
was being set to the wrapper exception's line. Now it is not. Perhaps we should just check that we have a previous exception in the if above.The {users} and {users_field_data} table do not use a serial field anymore therefore I think we can remove this. As it stands this change is incorrect because it this did occur then we'd have a mismatch between the two tables.
{users}.pass field
incore/scripts/password-hash.sh
since that field is part of the users_field_data table.I've checked the indexes created on the {users} and {users_field_data} tables are they are comparable with HEAD. Nice.
Comment #50
andypost1) reverted
2) removed the function and usage because #204411: Anonymous user id breaks on MySQL export/import (xID of Zero get's auto-incremented on external xSQL events) was for d6 and does not reproduce since
3) fixed
Comment #51
plachBack to RTBC
Comment #52
alexpottWe need a change record for this - like the other multilingual conversions.
Comment #53
andypostFiled draft https://www.drupal.org/node/2321051
Re-roll after #2261477: Remove broken Drupal\system\Tests\ScriptTest
PS: also updated https://www.drupal.org/node/1722906 with block, term and user issues
Comment #55
alexpott#54 was a testbot issue.
Comment #56
alexpottCommitted b3695e8 and pushed to 8.0.x. Thanks!
Comment #58
plachWhoo-hoo! @andypost+++++++
Comment #59
Gábor HojtsyThanks folks! Great job!