Current `db/schema.rb` broken?

[orenyk]

In the current development branch, the db/schema.rb file seems to be broken. Steps to reproduce:

1. git checkout development
2. git checkout db/schema.rb
3. rake db:reset (I've tested this and it's happening during the db:schema:load stage of db:reset; first it drops the database (see here))

The error I'm getting is

Mysql2::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(255), `max_renewal_times` int(11), `max_renewal_length` int(11), `renewal_days_' at line 1

rake db:migrate:reset works fine but gives a modified db/schema.rb file; it seems like we have some tab differences but also a :limit => 255 in some tables for deleted_at. Not sure where that's coming from, but that seems to be the culprit.

[mnquintana]

My guess is that someone forgot to commit their modified schema.rb when running migrations, which means that our migrations and schema are out of sync. All we should have to do is run migrations on a clean DB and commit the schema.

[orenyk]

That makes sense, not sure why it's giving an SQL error though. As long as we pull in a new schema with #587 we should be fine.

[mnquintana]

Huh that is kinda strange.

[dgoerger]

@shippy and I suspected some of the database changes were coming from sqlite3 vs mysql2 database backend incompatibilities. I believe we're all using MySQL/MariaDB as of last night.

@orenyk @mnquintana @shippy @squidgetx please make sure you're using MySQL or MariaDB v5.x, and not sqlite3 or postgres or mongo or whathaveyou. That should help keep the db consistent.

[mnquintana]

@dgoerger how would that even be possible?

[dgoerger]

in so far as.. what? different database backends do not support the same feature extensions (mysql -> postgres is an involved process; I don't know if going the other way is well supported..). sqlite3 has a limit of 255 for strings (see the Constants section of the Rails documentation), so that's where those have been coming from, and if we had a merge conflict go bad it wouldn't surprise me if we borked the whole file.

[orenyk]

Huh that's interesting, although I'm confused as to why the limit was only showing up in certain fields (e.g. deleted_at)... maybe it has to do with our soft deletion gem? We should be able to use Git to figure out when the schema was last updated and maybe that will explain it (not that it matters much as long as we get it back to a functional and up-to-date state).

[mnquintana]

No I mean, how would it be possible for any of us to be running a non-MySQL DB? We would have to go out of our way to modify the Gemfile with those specific Rails engines.

[dgoerger]

sqlite3 is already in the Gemfile, and I was using it while MySQL wasn't working on my machine (which was until I figured out the necessary patch in #630 on Saturday). I believe Simon may have also been using it some for testing purposes.

[orenyk]

is there a reason why sqlite3 is in our Gemfile if we nominally shouldn't be using it?

[dgoerger]

I don't think we were aware of it being a compatibility issue until last night. @shippy added it in 07e04f98 for testing purposes; we should remove it if none of the other gems depend on it.