Working on #2590993: Create stub entities with proper default values, I'm using FieldItemInterface::generateSampleValue() to generate values for a user entity stub. This fails for user entities - generateSampleValue() returns a string too long for the 60 characters (USERNAME_MAX_LENGTH) that are stored. That's based on the max_length from the base field definition for 'name', which is not set and thus defaults to 255. There is a comment "No Length constraint here because the UserName constraint also covers that.", but the constraint is not applied in generateSampleValue().
Set a max length of USERNAME_MAX_LENGTH in User::baseFieldDefinitions().
Write a test.
None
None
None
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | user_name_max_length-2602066-10.patch | 3.18 KB | mikeryan |
Comments
Comment #2
mikeryanComment #3
mikeryanWith a test... But, a little hitch here, adding the length creates redundant violations. Removing the length check from the UserName constraint causes other errors, which I haven't time to figure out, but I guess that means there was a good reason to make that check in the explicit constraint. Not quite sure how to resolve this...
Comment #6
mikeryanSo, in addition to the error I expected based on my local testing (redundant reports of the length violation):
there's a whole bunch like
So, I guess there needs to be an update function for the entity schema, although looking at user.entity_schema_data in key_value I don't see why that would have changed?
Comment #7
mikeryanOh, I see it now, user.field_schema_data.name is the place...
Comment #8
mikeryanCapturing my attempts to update the field schema, added an update function that does:
Stepping through updateFieldStorageDefinition, I see that $original->itemDefinition->definition['settings']['max_length'] is 255, and $storage_definition->itemDefinition->definition['settings']['max_length'] is 60 - perfect! But, $original->schema['columns']['value']['length'] is 255, even though the actual SQL schema in use is 60 (forced in UserStorageSchema::getSharedTableFieldSchema()). So, the update fails with a complaint that you can't change the schema for a field that is already populated, even though there is no actual schema change. I can see in key_value that the entity.definitions.installed collection user.field_storage_definitions has the wrong column length, so it seems that there is an underlying bug in saving the field_storage_definitions that it doesn't necessarily reflect the true SQL schema. Right now, for the purposes of performing this update, I don't see how to fix that - anyone with a deeper understanding of the field internals have a thought?
Comment #9
mikeryanOops, ignore that patch.
Comment #10
mikeryanComment #12
mikeryan#10 didn't get tested...
Comment #13
mikeryanThinking through a bit about what I discovered, I believe that this discrepancy in the stored username schema length doesn't just get in the way of my migration-related change, but that any future attempt to change user field definitions will get blocked - raising to Major.
Comment #15
berdirI was fighting with the same problem in #2227381: Apply formatters and widgets to User base fields 'name' and 'email'.
Comment #16
xjmComment #24
boobaaPlease keep in mind that the length of the usernames are not only stored in actually TWO constants (
USERNAME_MAX_LENGTHin the module file andUserInterface::USERNAME_MAX_LENGTH), but also in about 8+ other files, too. Here's a list of files I came across containing the magic number of 60 (or 61 for tests; this list might be incomplete):