I have been away for a while, not only from the blog, but my projects in general. There are reasons for this, none of them good, so I won’t bother you with the particulars. Suffice it to say my projects have not gotten any real attention in a while, save for those few bits I worked on for the NFL project (because what I need are more projects right dear reader?)

Any who…tonight (November 29, 2016), I sat down to try and focus, use some pomodoros and work on one of my existing projects; the long suffering, gestating and neglected NBA project. The first thing I did was check if I was up to date with the parent repository and then ran the rspec tests to make sure they all passed.

Uh Oh

My tests did not pass nor fail. My tests did not run. For some reason I could not connect to my database to run my tests. A little research soon revealed why.

Now, if you work in Rails on a Mac, your applications usually are developed and tested in the lightweight SQLite. It’s the default database unless you tell Rails to use another. As this NBA application was going to be robust and (at least I felt it would) have complex queries to run, I decided that from the beginning I would use the RDBMS that would most likely serve as the platform when the application went live. That database is PostgreSQL.

If you have ever worked with the command line, you know that there are a variety of applications, widgets, and even geegaws that you will install over time that will be updated, modified, improved what have you, and that you should have a way to track that. The system I use to track all these things, and commonly used by many Mac users (but not all, I’ve read some dissenting opinions regarding it but I am not fluent enough (yet) in command line to deal with it in other fashions) is called Homebrew. I don’t claim to fully get the ins and outs of it but I know that I can use brew install followed by the desired application name to install many things. That is, for instance, how I initially installed PostgreSQL on my computer. The most common homebrew commands you run are brew update and brew upgrade. The update command scans for all updated applications available whereas upgrade will bring any applications you have currently installed up to their most recently released version. Like I said, these commands are commonly run (brew update you’d probably run once a day, and brew upgrade I run whenever I see the little check that indicates a new version for what I have installed) and I run them out of habit, which is where I ran into my problem.

It seems that in the past few months, PostgreSQL upgraded from a 9.5 version to a newer 9.6 version. Homebrew made this update automatically, as it is supposed to. For some reason though the databases created using the 9.5 version of the database were not compatible with the 9.6 version.

As an aside, I think the fact that an upgrade from 9.5 to 9.6 means your old databases are incompatible is unacceptable from a support point of view. If such major changes are being made that old data isn’t compatible, then perhaps you need more than a small increment from 9.5 to 9.6

So, my test failed, and any application (I have more) using the same database system would fail, and this was not totally acceptable, so to the interwebs I went. My old stand by Stack Overflow was not as helpful as I would have hoped, but I did happen upon this gist on GitHub that walked me through the changes I would have to make (my version was 9.5.2). So, now I was ready to use Postgres 9.6.1, or was I?

Unfortunately, the steps to bring back my old data listed in the gist didn’t work out great for me, but that’s fully ok, since I only had database scaffolding that I was working on, not actual vital data, and Rails can rebuild that database scaffolding (tables) pretty easily from scratch, because that’s one of numerous awesome things with rails. After a few fits and starts where I had to set up the proper role and permission and the databases themselves, and I was finally able to rebuild my databases using rake db:migrate to recreate my tables from scratch.

At this point, I ran my tests, and all 88 passed as they should, so we were ready to start working on the project again. Though, I will have to do this for a few other projects as well before I start working on them, and probably will now detour into doing that for the other applications after I publish this.

So, research before you upgrade. It’s possible that what seems like a minor thing can cause breakage and frustration. Additionally, thanks again to Rails for forcing me to build my database tables through your code so that I could easily rebuild them once I had switched over.