Open jfly opened 7 years ago
Hey Jonatan, do you mind taking some time to look into this? You don't have to actually write any code yet, the first step would be to just figure out what happened in each of these discrepancies and how we should go about fixing them.
An awesome goal would be for db:structure:dump
to have no discrepancies whatsoever. If we do ever get to that point, maybe we could add any discrepancies to server-status, to make sure we don't cause future problems.
_tmp_index_Results_on_countryId
just to test the performance of the query, and once it did well I added a Rails migration. This way my original name stayed within structure.sql
, whereas running the migration on production created an index with a normal Rails-generated name.
Suggested fix: add a migration renaming the index if its name is _tmp_index_Results_on_countryId
.ar_internal_metadata
, it is created once db:migrate
is run for the first time using Rails 5. I see that it was added to structure.sql as a part of a really unrelated PR #1505. So my guess is that the table was created in production automatically at some point, and after some time you added the table with changed collations (accidentally?) to the repo. The only thing I am confused by is why it took so long for the table to end up in our git structure.sql
.
Suggested fix: not sure what would be the best, we could drop the production version of the table and let it be recreated on the next migration (hopefully with the collation we have defined in structure.sql
). Maybe someone have a better idea for a clean fix?structure.sql
and the tables manually, as they are only used on production anyway.NOT NULL
.I was not involved in the execution of populating the championships list. @Baiqiang ?
@jonatanklosko, what do you mean by "implicit migration"? Perhaps you mean "explicit migration"? If so, then yes, I like that. I say let's go with production, which means changing the gender
column in InboxPersons
and Persons
to be a char
instead of a varchar
. I guess we don't even need a migration for this, just a PR to update structure.sql
.
I like @jonatanklosko's suggestion.
... The only thing I am confused by is why it took so long for the table to end up in our git
structure.sql
.
I think I can answer this: all us developers have gotten in the habit of running git add -p
and ignoring most changes to structure.sql
except for the ones we know we added. #1505 was so massive that I didn't bother trying to do a git add -p
, I just added the brand new structure.sql, which brought in the new ar_internal_metadata
table.
Suggested fix: not sure what would be the best, we could drop the production version of the table and let it be recreated on the next migration (hopefully with the collation we have defined in structure.sql). Maybe someone have a better idea for a clean fix?
I tried this out on staging and on my local development environment, and I ended up with the same two different ar_internal_metadata
tables. Perhaps this has to do with differences in the two mysql servers.
I like @jonatanklosko's suggestion.
Ping @Baiqiang!
I like @jonatanklosko's suggestion.
After #1817 and #1836, I decided to try out
db:structure:dump
on production to see how out of sync our production and development databases are. The results were not thrilling =(There's a lot of stuff above, here's a list of the important differences I see:
varchar(1)
is showing up aschar(1)
on production. For example, the gender column of the Persons table._tmp_index_Results_on_countryId
index is namedindex_Results_on_countryId
on productionar_internal_metadata
table is differentarchive_*
tables are InnoDB on production instead of MyISAMchampionship_list
on production that does not exist anywhere in our codebase. Maybe @Baiqiang or @SAuroux created this when populating thechampionships
table?