0

Using Ruby on Rails 3 and ActiveRecord 3.2.18. I have a binary column in my database. It holds binary stuff, and actually I have a bunch of records in production with that column filled. So in my db/schema.rb file I had...

...
t.binary   "tin"
...

Now, after running a migration that touches this table but doesn't change that column, my schema says...

...
t.string "tin"
...

Well... I know that a string might be binary, and binary might be a string, depending on how it's stored in the database, and maybe these equate to the same column type in the end, but why is this happening and what can I do to fix it? Is it safe to deploy this change to production or will it hose my binary columns?

max
  • 199
  • 1
  • 2
  • 7
  • Can you post the migration you are running? – Shalev Shalit Jun 25 '14 at 21:45
  • There are far too many migrations in this project to post them all. Suffice it to say that the migration that actually creates that column calls it a binary column, and there are no other migrations that touch that column other than the migration that created it. – max Jun 27 '14 at 16:12

1 Answers1

1

When you run a rake command such as rake db:migrate, Rails will recreate the schema.rb file from the schema in your own personal database. So it sounds like your database has the tin field setup as a varchar field. If your migrations set up your database this way and your production server has the same database then I wouldn't count on the production server to do the right thing. So you may need to look into how to really set a binary field.

On the other hand, if your database is setup properly and it's just the schema file that's not then it may be because... schema can't interpret every database-specific column type. In these cases, you can switch your schema to dump to schema_dump.sql instead of to schema.rb. So check this Stack Overflow post for more on that.

Community
  • 1
  • 1
pdobb
  • 17,688
  • 5
  • 59
  • 74
  • Hrm. Ok that's definitely what's going on. I looked at our production database and this field is totally a VARCHAR(255) when it has absolutely no business being one. Now the real question becomes, how did it become a VARCHAR(255)? I just looked through all my migrations and every single one of them that touches that column uses the `binary` type. – max Jun 27 '14 at 16:09
  • Okay. After much more inspection, this column's always been a string column, so I think the contractor who built this project messed it up royally (which I already knew) and it picked up the VARCHAR type from her database, which went unnoticed until now. That sucks, but it's at least a plausible answer and we'll recover. I didn't realize the schema.rb file got its schema out of the local database but I suppose that makes sense. Thanks! – max Jun 27 '14 at 16:27
  • Yeah, if you move or change a column in your database and run a db:migrate you'll see the change reflected in schema.rb. Cheers! – pdobb Jun 27 '14 at 16:29