| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the standard in every extension. DB schema changes are not
maintenance scripts, and therefore there's no apparent reason to have
the two things together, besides historical reasons.
Also, put each DB type in a separate directory, which wasn't the case
for MySQL before. For SQLite and Postgres schema changes, we now
follow the convention (used everywhere else, including the
generateSchemaChangeSql script) of having the DB type as the last part
of the path. This lets us generate schema changes for all DB types at
once, and without specifying the full file path.
Most files are just being renamed, the exceptions being to update
references to the old location (sometimes still referencing tables.sql).
Note that the old path is still referenced in the autogenerated comment
of schema changes SQL files. These will be regenerated in another
commit. Instead, the schema files are done now, because they're covered
by DatabaseIntegrationTest that would otherwise fail.
Bug: T382030
Change-Id: I3b4a614366d0bc629523ac40ce97d001f3b6bcf8
|
|
|
Why:
* Part of a temporary user name is generated from an index that
increments, which is stored in the database.
* As specified in T345855, the index will be restarted each year.
* Also specified in T345855, the year will be included in
generated temporary user names.
What:
* Since the year must be included in the name in order to avoid
naming conflicts if the index is restarted each year, both are
implemented together and controlled by a single config.
* Add a new config option that, when true, restarts the name
generation index at the start of each year and add the year into
the user name: $wgAutoCreateTempUser['serialProvider']['useYear']
* Add a uas_year column to the user_autocreate_serial table, which
is unique in combination with uas_shard, so the index can be
stored for each shard/year combination.
* The year is added into the username just after the prefix, as
specified in T345855. This is based on research that having the
year near the start of the name aids understanding that the
names are not IP addresses. The position of the year within the
name is therefore not configurable (though whether to include
it is). See T345855 for the research.
Bug: T349494
Bug: T349501
Depends-On: I6b3c640a4e74f52fd4a4f46de5a2cbe80fe3b665
Change-Id: If51acb3f4efa361ce36d919c862a52501a5a7d24
|
