I’m currently developing my graduation thesis (yeah, the end is near \o/).
I’ve decided to use this opportunity to explore a new technology, and the chosen one was Padrino.
Padrino is a Ruby framework built upon Sinatra: Sinatra provides a simple DSL to create web applications and Padrino adds some useful tools to automate the creation of routes, models, anyway, the project’s bootstrap.
One of the steps for creating a Padrino app is to choose an ORM. Padrino supports many ORMs, such ActiveRecord, MongoID, DataMapper, etc.
Well, in my project, I’ve choose ActiveRecord with Postgres. Why? Because I’ve had some familiarity with ActiveRecord from Rails.
Everything was going well, the system taking form but then, I’ve realised that a relational database wouldn’t be the best choice for my problem.
So, I’ve decided to change from an ORM to a ODM (object document mapping), and the chosen one was MongoID + MongoDB.
The challenge now is: how to move from ActiveRecord to MongoID?
After some research, I’ve realised that Padrino doesn’t provide an automated way to disable the old ORM and enable the new one. So, we need to do this manually.
1. Creating a new Padrino project
Before we start our PoC, we need a Padrino project. So, let’s create a new one with the following commands:
Padrino will create the project bootstrap, as expected.
Now, let’s create our Models: User and Post
And then, preparing database to receive our models:
Now, we need to implement our models. So, here they are:
Now, let’s make sure our models are interacting correctly. Let’s create a simple test in User spec that:
- Creates an user;
- Creates 3 posts;
- Associates posts to users;
- Saves the user;
So, here is the test code (spec/models/user.rb):
Now, let’s run rspec and see if everything is working as expected:
Of course, we forgot to add an user_id column on the Post’s table, so the association is invalid.
Let’s fix it:
Running rspec again:
It’s saying that Post tests are missing. That’s OK, because our test is implemented in User spec. So, just delete spec/models/post_spec.rb and run rspec again:
Great! We now have a simple Padrino project, running with two models (User and Post), a simple test with RSpec and using ActiveRecord + Sqlite.
It’s time to move to MongoID…
2. Adding MongoID support
Moving from ActiveRecord to MongoID is a three step work:
- Add support to MongoID;
- Adjust project for using MongoID instead of ActiveRecord;
- Remove ActiveRecord from project;
2.1. Adding support to MongoID
In order to use MongoID on your project, we basically need to:
- Install MongoID gem;
- Create connection to MongoDB database;
So, let’s do it:
The next step is change .components file to use MongoID instead of ActiveRecord. So, modify this file as following:
Now, we need to create config/mongoid.yml file. This file is used to configure MongoDB connections used on our project. It’s like the config/database.rb for ActiveRecord.
So, create the config/mongoid.yml file with the following content:
And, finally, create a new connection with MongoDB. So:
Ok, now we have MongoID enabled in our project.
It’s time to adjust our models to use MongoID instead of ActiveRecord.
2.2. Adjusting Models
We need to remove every reference to ActiveRecord from our models and replace it by the equivalent one for MongoID.
Let’s do it:
And, finally, let’s rerun rspec and see if our modifications didn’t break anything:
We now have our Padrino project running with MongoID + MongoDB \o/
Now, it’s time to clean up the house, removing ActiveRecord.
2.3. Getting rid of ActiveRecord
To remove ActiveRecord, we need to:
Now, rerun bundle install and a last rspec to make sure everything is still working:
You have moved your project from ActiveRecord + Sqlite to MongoID + MongoDB \o/\o/\o/
Padrino is a great framework for those who wants to enjoy the power of Sinatra without needing to configure everything manually. However, even with a large number of generators and many useful tools that save you a lot of development time, there are situations where you will need to roll up your sleeves and dive into Padrino’s internals. In those cases, Padrino and Sinatra’s documentation are your good allies.
And, if nothing else works, well, just leave the gun and take the cannoli.
The project used in this tutorial is available on Github. You can access it here