mirror of https://github.com/zulip/zulip.git
f4d98b03d5
This has the impact of making rebuilding the database in a Zulip development environment, or initializing a new production database, dramatically faster. This was generated by merging the output of `manage.py makemigrations` with an empty migration. Tested using `tools/rebuild-test-database` before and after this change, and comparing the output of `pg_dump -d zulip_test` using Git's diff comparison algorithm. Differences in that SQL dump include: - The actual generated table contents, due to timestamps and the like; this is expected and unrelated to schema. - Orders of fields within tables, which is not significant in SQL. - IDs assigned to tables in the ContentType table, which is expected and not a problem with how that Django table is designed. - Names of generated indexes and constraints; modern Django seems to abbreviate long names differently for these, and it's not obviously possible to configure those used by the `db_index` property. If necessarily, likely this can be converged via a migration filled with `IF EXISTS` rename operations like the one done in zerver/migrations/0246_message_date_sent_finalize_part2.py. - Names of the ~3 sequences related to renamed tables: usertopic/mutedtopic, botconfigdata/botuserconfigdata, realmdomain/realmalias. Probably there's no action required here, but we could do rename operations if desired. |
||
|---|---|---|
| .. | ||
| actions | ||
| data_import | ||
| integration_fixtures/nagios | ||
| lib | ||
| management | ||
| migrations | ||
| models | ||
| openapi | ||
| tests | ||
| tornado | ||
| transaction_tests | ||
| views | ||
| webhooks | ||
| worker | ||
| __init__.py | ||
| apps.py | ||
| context_processors.py | ||
| decorator.py | ||
| filters.py | ||
| forms.py | ||
| logging_handlers.py | ||
| middleware.py | ||
| signals.py | ||