Tag Archives: Ruby

Quick Tip: Rails for legacy oracle tables

Using Rails can be fun, however sometimes you have a legacy Oracle table that is bringing you down. This table was possibly created long ago, and does not have a sequence setup to handle the primary key. Since Oracle has no auto number type this can be a problem. Rails usually would have a hard time with this since it likes to stick to it’s “sensible defaults”. However, if we set a few things manually we can whip Rails and Oracle into shape.

First thing we need to do is set the table_name and primary_key attributes for our legacy table. Then we need to set the before_save property to increment our column id by selecting the highest legacy id and adding one to it. Pretty simple.

This is for sure not a best practice, but if you cannot create a sequence and need rails to work with legacy oracle, this will do the trick.

Sharing Rails sessions with PHP, ColdFusion, and more!

Sometimes it does not make sense to store session within a cookie. It might be a size issue, or it could be sensitive information you do not want to go across the wire with each request. Whatever the reason, another option is to database the session information. Luckily rails makes it really easy to do this via active record store.

Active record store

To start databasing our sessions, we need to setup rails to use the active record store. To enable active record store we need to edit the config/initializers/session_store.rb file. We need to comment out the cookie store option and add the active record store option.

Creating the database

Next step is to create the session database table. To do that we will run the following commands…

Session data

When you create the session each created session will be entered as a record in the database. There will be id, session_id, data, created_at, and updated_at columns. The session_id will stored in a cookie and be used to retrieve the data column which contains the databased session information. The data column will store the information as a base64 encoded string. Like so.

Which can be marshaled to a ruby object upon request.

Making rails share

This works pretty well for storing sessions in rails. However, there is a problem. Ruby is using it’s internal marshaler when storing the session information. This means that any other language, such as php, coldfusion, etc cannot decode the data unless you write the marshaler 🙁

There may however, be a way around this. What if we could override rails and tell it to save the data as base64 encoded JSON instead of marshaling it? Every other language could then decode base64 strings and serialize them from JSON to native objects.

If we again edit our session_store.rb file, we can override some internal rails methods when handling sessions. Below we are overriding base the SessionStore class.

If you notice we are only overriding the marshal and unmarshal methods to preform a JSON.encode and JSON.decode instead of the traditional Marshal.load and Marshal.dump.

We can then easily read this information out in another language.

Rails Engines, Gems, and Cells, Oh My!

At work we are starting to switch our legacy systems from an old server side language (that shall not be named) to Ruby on Rails. Rails offers a ton of convenient features. However, the one thing that had me stumped was how to make reusable widgets. I’m talking about making gems full of reusable components that will be used in multiple projects. This may sound trivial, but what if you want to make reusable header, menu, sidebar, and footer widgets that are in a gem? Fortunately as of Rails 3.1 we have some help.

Start your engines!

Rails has feature called engines that allows you to wrap a Rails application up and share it with other rails applications. Packaging an engine up into a gem gives a nifty way to redistribute reusable rails components across applications. Confused? Here is a diagram.

Everything in blue is a reusable widget that is from a gem. The brown portion is the current application. You may be asking why is this useful? Let me give you an example. In our organization we have lot’s of applications. Calendaring, time tracking, invoicing, etc. Each application needs the same header, footer, menu, etc. To copy this code to each application wouldn’t be very DRY. Not to mention the maintenance involved when one of these components requires a change.

Creating a mountable gem

To get started we need to create a gem that can be mounted into another rails application. We can create this gem using the command below. The –mountable switch will make this gem using a mountable engine. The –dummy-path=spec/dummy switch is optional, however it will create a special dummy folder (with a dummy rails app) for running rspec tests to test our mountable engine gem.

Now that our gem is setup the next step is to open the gemspec file and edit all the TODO: information.

Cell that gem!

In order to separate our components into little pieces, we need to organize them within our mountable engine. To do this we will use a rails project called “cells”.

For more info

Cells Plugin

Adding cells

To add cells we need to add the following to our gemfile.

Then we need to run “bundle update” to retrieve the cells gem.

Next, we want to create a cell. Let’s create the header. We can run the following.

Rails will create a header cell (in app/cells) with a show action. In the app/cells/header folder it will create a show.html.erb file. This will be our partial layout for the show action. Let’s throw our header markup in there.

Publish our gem locally

Next we want to install our gem locally so that we can bring it into another project. If do not want your gem to be local and instead want it on a server you will need to to set that up. However, setting up a private gem server is out of the scope of this article.

To install our gem locally run the following

Consuming our gem from another app

Finally, we will want to pull in our mountable gem into a different project. To do this we will need to create a new project

Then we need to edit the gemfile to add our new mountable gem and the cells plugin. Like so…

Again, we will need to run “bundle update” to pull in our cells, and core gems.

Lastly, we can use our cells in our layout files using the render_cell method. Rails is smart enough to search the mounted gem which contains our header, sidebar, and footer gems.

A sample application.html.erb file

Conclusion

Building reusable components for Rails doesn’t need to be complicated and difficult. Using mountable engines, cells, and gems we can build components that are reusable for others across multiple applications.