1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-11 16:16:14 +01:00
Commit graph

4 commits

Author SHA1 Message Date
epriestley
fb8da6f4af Support key schemata and column nullability
Summary:
Ref T1191. The major issue motivation here is that InnoDB keys have a maximum length of 767 bytes. When we move `utf8` colums to `utf8mb4` columns, they'll jump from 3 bytes per character to 4 bytes per character, which may make some indexes too long. Add key schema to help spot this.

Also add nullability since it doesn't hurt.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T1191

Differential Revision: https://secure.phabricator.com/D10499
2014-09-18 08:32:21 -07:00
epriestley
aa481dba57 Begin generating meaningful expected schemata
Summary:
Ref T1191. This lays some groundwork for generating the expected schemata, so we can compare them to the actual schemata and produce a meaningful diff.

  - In general, each application will subclass `PhabricatorConfigSchemaSpec` and provide a definition of the tables it expects.
  - This class has helper methods to mostly-automatically build table definitions for Lisk and (in the future) edges.
  - When building expected schema, we specify a "data type", like "epoch". This is the type of data the application stores in the column, from the application's point of view. The SchemaSpec converts this into the best avilable storage type: for example, "text" will translate to `utf8mb4` if it's availalbe, or `binary` if not. This gives us a layer of indirection to insulate us from craziness.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T1191

Differential Revision: https://secure.phabricator.com/D10497
2014-09-18 08:25:34 -07:00
epriestley
b24e36706d Generate expected and comparison schemata
Summary:
Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences.

(I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.)

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T1191

Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 08:22:54 -07:00
epriestley
12b53e003b Add a UI for reviewing database schemata
Summary:
Ref T1191. Plan here is:

  - Build a tool showing the current schemata status (this diff).
  - Have it compare the current status to the desired status (partly here, mostly in future diffs).
  - Then add a migration tool, and eventually a setup issue to tell people to run it.

Test Plan:
Reviewed current schemata.

{F204492}

{F204493}

{F204494}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T1191

Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 08:22:18 -07:00