Read Fullscreen

Using Struct and Serialize to get flexibility in ActiveRecord

Rails/Angular developer, Entrepreneur & YC alum. Previously built and sold Clickpass.com. Now O(only)TO at Brojure.com and part time partner at Entrepreneur First.

I can’t claim any credit for this piece of lovely insight, it all belongs to JAKUB GŁUSZECKI who’s basically written exactly what I’m about to replicate here. However it’s a sweet solution and I wanted to share it. 

The problem

You’ve got a bunch of model attributes that you need to store in the database but don’t really deserve their own column. For instance, there are a number of client-specific strings associated with the Q&A panels on Pingpanel. At the time of writing you can see these at diy-advice.ratedpeople.com.

The descriptions of what the panel is about, the types of questions you can ask there etc. all belong in the database but don’t really merit messing up the schema by occupying a complete column.

What I want to do is to store all of these model attributes (which will never need searching or indexing) in lump which I can pull or update when I need to.

The solution part 1: Serialize

Rails offers a nice serialize method which will roll up a structured object (e.g. a hash), put it into a database column and then unroll it back into the original object when you need it. 

class Org
    serialize :descriptions
end

This now allows me to dump an arbitrary array of attributes into descriptions which can be added to or altered at future dates.

Solution part 2: OpenStruct

That’s all well and good but I’d prefer to use object notation for accessing the attributes so instead of it being:

@org.descriptions[‘strapline’]

I would prefer:

@org.descriptions.strapline

Happily, serialize allows us to enforce that only a particular class can be passed and OpenStruct is a class that basically does exactly what I need. It wraps a hash up into object notation: 

class Org
    …
    serialize :descriptions, OpenStruct
end

which lets us do

@org.descriptions.strapline

Solution part 3: Struct

Now although I don’t want to mess the database up with arbitrary columns I still want some accountability. I’m going to have a problematic time debugging if I can read and write whatever I chose.

Let’s say I pump

@org.descriptions.strapline

into the view but save

@org.descriptions.tagline

back into the database. I’ve got a setup which looks sensible in both places but is evidently going to lead to problems very quickly. OpenStruct will do this without blinking which is a little dangerous.

The solution is Struct which is the same thing as OpenStruct but with a limited set of defined attributes. 

We can create a new class derived from Struct with the attributes we want and then pass it to serialize as the enforced object:

class Org
    …
    class Descriptions < Struct.new(:strapline, :panel_intro) 
    end
    serialize :descriptions, Descriptions
end

The new Descriptions object will allow @descriptions.strapline to be set and read but will throw an error if you try to write @descriptions.tagline.

Edit: Migrations. Beware.

On further thinking, while this approach has its strengths, it also has one serious weakness which is migrations and specifically what happens if you change the name of the attributes on the Struct. 

The struct is stored as a string in the database:

”#<struct Org::Guidance strapline=nil, panel_intro=nil>”

When you change the name of ‘strapline’ to ‘tagline’ none of the existing, serialized strings in the database get changed (i.e. the data’s still there) but we’ll find that when we load our object the new @org.strapline attribute is now set to nil.

As soon as we save @org the previous string will be overwritten and our old data is lost. 

What to do about this? TBH I don’t know. You could always write some sort of migration script but with that decoupled from the migration itself (i.e. just changing the model) we’re in dangerous territory. Perhaps it’s just best to stick with to good tools ActiveRecord has given us. Thoughts appreciated.