rails_lookup 0.0.1

data/Manifest

@@ -0,0 +1,4 @@
+README
+Rakefile
+lib/active_record/lookup.rb
+Manifest

data/README

@@ -0,0 +1,139 @@
+Lookup tables with ruby-on-rails
+--------------------------------
+
+By: Nimrod Priell
+
+This gem adds an ActiveRecord macro to define memory-cached, dynamically growing, normalized lookup tables for entity 'type'-like objects. Or in plain English - if you want to have a table containing, say, ProductTypes which can grow with new types simply when you refer to them, and not keep the Product table containing a thousand repeating 'type="book"' entries - sit down and try to follow through.
+
+Motivation
+----------
+
+A [normalized DB][1] means that you want to keep types as separate tables, with foreign keys pointing from your main entity to its type. For instance, instead of 
+ID          | car_name        | car_type
+1           | Chevrolet Aveo  | Compact
+2           | Ford Fiesta     | Compact
+3           | BMW Z-5         | Sports
+
+You want to have two tables:
+ID  | car_name        | car_type_id
+1   | Chevrolet Aveo  | 1
+2   | Ford Fiesta     | 1
+3   | BMW Z-5         | 2
+
+And
+
+car_type_id | car_type_name 
+1           | Compact
+2           | Sports
+
+The pros/cons of a normalized DB can be discussed elsewhere. I'd just point out a denormalized solution is most useful in settings like [column oriented DBMSes][2]. For the rest of us folks using standard databases, we usually want to use lookups.
+
+The usual way to do this with ruby on rails is
+* Generate a CarType model using `rails generate model CarType name:string`
+* Link between CarType and Car tables using `belongs_to` and `has_many`
+
+Then to work with this you can transparently read the car type:
+
+    car = Car.all.first
+    car.car_type.name # returns "Compact"
+
+Ruby does an awesome job of caching the results for you, so that you'll probably not hit the DB every time you get the same car type from different car objects.
+
+You can even make this shorter, by defining a delegate to car_type_name from CarType:
+
+*in car_type_name.rb*
+    
+    delegate :name, :to => :car, :prefix => true
+
+And now you can access this as 
+
+    car.car_type_name
+
+However, it's less pleasant to insert with this technique:
+
+    car.car_type.car_type_name = "Sports"
+    car.car_type.save!
+    #Now let's see what happened to the OTHER compact car
+    Car.all.second.car_type_name #Oops, returns "Sports"
+
+Right, what are we doing? We should've used
+
+    car.update_attributes(car_type: CarType.find_or_create_by_name(name: "Sports"))
+
+Okay. Probably want to shove that into its own method rather than have this repeated in the code several times. But you also need a helper method for creating cars that way…
+
+Furthermore, ruby is good about caching, but it caches by the exact query used, and the cache expires after the controller action ends. You can configure more advanced caches, perhaps.
+
+The thing is all this can get tedious if you use a normalized structure where you have 15 entities and each has at least one 'type-like' field. That's a whole lot of dangling Type objects. What you really want is an interface like this:
+
+    car.all.first
+    car.car_type #return "Compact"
+    car.car_type = "Sports" #No effect on car.all.second, just automatically use the second constant
+    car.car_type = "Sedan" #Magically create a new type
+
+Oh, and it'll be nice if all of this is cached and you can define car types as constants (or symbols). You obviously still want to be able to run:
+
+    CarType.where (:id > 3) #Just an example of supposed "arbitrary" SQL involving a real live CarType class
+
+But you wanna minimize generating these numerous type classes. If you're like me, you don't even want to see them lying around in app/model. Who cares about them?
+
+I've looked thoroughly for a nice rails solution to this, but after failing to find one, I created my own rails metaprogramming hook.
+
+Installation
+------------
+
+The result of this hook is that you get the exact syntax described above, with only two lines of code (no extra classes or anything):
+In your ActiveRecord object simply add
+
+    require 'active_record/lookup'
+    class Car < ActiveRecord::Base
+      #...
+      include ActiveRecord::Lookup
+      lookup :car_type
+      #...
+    end
+
+That's it. the generated CarType class (which you won't see as a car_type.rb file, obviously, as it is generated in real-time), contains some nice methods to look into the cache as well: So you can call
+
+    CarType.id_for "Sports" #Returns 2
+    CarType.name_for 1 #Returns "Compact"
+
+and you can still hack at the underlying ID for an object, if you need to:
+
+    car = car.all.first
+    car.car_type = "Sports"
+    car.car_type_id #Returns 2
+    car.car_type_id = 1
+    car.car_type #Returns "Compact"
+
+The only remaining thing is to define your migrations for creating the actual database tables. After all, that's something you only want to do once and not every time this class loads, so this isn't the place for it. However, it's easy enough to create your own scaffolds so that 
+
+     rails generate migration create_car_type_lookup_for_car
+
+will automatically create the migration
+
+    class CreateCarTypeLookupForCar < ActiveRecord::Migration
+      def self.up
+        create_table :car_types do |t|
+          t.string :name
+          t.timestamps #Btw you can remove these, I don't much like them in type tables anyway
+        end
+    
+        remove_column :cars, :car_type #Let's assume you have one of those now…
+        add_column :cars, :car_type_id, :integer #Maybe put not_null constraints here.
+      end
+
+      def self.down
+        drop_table :car_types
+        add_column :cars, :car_type, :string
+        remove_column :cars, :car_type_id
+      end
+    end
+
+I'll let you work out the details for actually migrating the data yourself. 
+
+[1] http://en.wikipedia.org/wiki/Database_normalization
+[2] http://en.wikipedia.org/wiki/Column-oriented_DBMS
+
+I hope this helped you and saved a lot of time and frustration. Follow me on twitter: @nimrodpriell
+

data/Rakefile

@@ -0,0 +1,29 @@
+require 'rubygems'  
+require 'rake'  
+require 'echoe'  
+  
+Echoe.new('rails_lookup', '0.0.1') do |s|  
+  s.description = File.read(File.join(File.dirname(__FILE__), 'README')) 
+  s.summary     = "Lookup table macro for ActiveRecords" 
+  s.url             = "http://github.com/Nimster/RailsLookup/"
+  s.author      = "Nimrod Priell"
+  s.email       = "@nimrodpriell" #Twitter
+  s.ignore_pattern  = ["tmp/*", "script/*"]  
+  s.development_dependencies = []  
+end  
+  
+Dir["#{File.dirname(__FILE__)}/tasks/*.rake"].sort.each { |ext| load ext }  
+=begin
+spec = Gem::Specification.new do |s|
+  s.name        = "rails_lookup"
+  s.requirements = [ 'Rails >= 3.0.7, Ruby >= 1.9.1' ]
+  s.version     = "0.0.1"
+  s.homepage    = ""
+  s.platform    = "Gem::Platform::RUBY"
+  s.required_ruby_version = '>=1.9' 
+  s.files = Dir['**/**'] 
+  s.executables = [] 
+  s.test_files = [] #Dir["test/test*.rb"] 
+  s.has_rdoc = false
+end 
+=end

data/lib/active_record/lookup.rb

@@ -0,0 +1,134 @@
+# Author: Nimrod Priell (Twitter: @nimrodpriell)
+# 
+# See README file or blog post for more.
+# This is intended to be included into ActiveRecord entities: Simply
+# include ActiveRecord::Lookup
+# in your class that extends ActiveRecord::Base
+module ActiveRecord
+module Lookup
+  #These will be defined as class methods.
+  module ClassMethods
+    #We define only this "macro". In your ActiveRecord entity (say, Car), use
+    # lookup :car_type
+    # which will create Car#car_type, Car#car_type=, Car#car_type_id,
+    # Car#car_type_id= and CarType, an ActiveRecord with a name (String)
+    # attribute, that has_many :cars. 
+    # 
+    # You can also use
+    # lookup :car_type, :as => :type
+    # which will do the same thing but create Car#type, Car#type=, Car#type_id
+    # and Car#type_id= instead.
+    def lookup(lookup_name, opts = {})
+      as_name = opts[:as] || lookup_name
+      mycls = self #Class I'm defined in
+
+      #Create the new ActiveRecord for the lookup
+      cls = Class.new(ActiveRecord::Base) do 
+        #It has_many of the containing class
+        has_many mycls.to_s.split(/[A-Z]/).map(&:downcase).join('_').to_sym
+
+        validates_uniqueness_of :name
+        validates :name, :presence => true
+
+        #Query the cache for the DB ID of a certain value
+        def self.id_for(name, id = nil)
+          class_variable_get(:@@rcaches)[name] ||= id
+        end
+
+        #This helper method is the "find_or_create" of the class that also
+        #updates the DB. I didn't want to overwrite the original
+        #find_or_create_by_name since it is linked with a lot of the rails
+        #behaviour and I want to avoid altering that.
+        def self.gen_id_for(val)
+          id = id_for val
+          if id.nil?
+            #Define this new possible value
+            new_db_obj = find_or_create_by_name val #You could just override this...
+            id_for val, new_db_obj.id
+            name_for new_db_obj.id, val
+            id = new_db_obj.id
+          end
+          id
+        end
+
+        #Query the cache for the value that goes with a certain DB ID
+        def self.name_for(id, name = nil)
+          class_variable_get(:@@caches)[id] ||= name
+        end
+      end
+
+      #Bind the created class to a name
+      lookup_cls_name = lookup_name.to_s.split("_").map(&:capitalize).join("")
+      Object.const_set lookup_cls_name, cls #Define it as a global class
+
+      #Define the setter by string value
+      define_method("#{as_name.to_s}=") do |val|
+        id = cls.gen_id_for val
+        write_attribute "#{as_name.to_s}_id".to_sym, id
+      end
+
+      #Define the getter
+      define_method("#{as_name.to_s}") do 
+        id = read_attribute "@#{as_name.to_s}_id".to_sym
+        if not id.nil?
+          value = cls.name_for id
+          if value.nil?
+            lookup_obj = cls.find_by_id id
+            if not lookup_obj.nil?
+              cls.name_for id, lookup_obj.name
+              cls.id_for lookup_obj.name, id
+            end
+          end
+        end
+        value
+      end
+
+      #This sucks but it's the only way I could figure out to create the exact
+      #method_missing method signature and still pass it the values I need to
+      #use it. Maybe these should be class variables, but the best thing is if
+      #they could only be defined in this scope and carried along with the
+      #closure to the actual method.
+      @as_name = as_name
+      @cls = cls 
+      #We need to wrap around rails' default finders so that
+      #find_by_car_type and similar methods will behave correctly. We translate
+      #them on the fly to find_by_car_type_id and give the id instead of the
+      #requested name.
+      def method_missing(method_id, *arguments, &block)
+        if match = ActiveRecord::DynamicFinderMatch.match(method_id)
+          #reroute car_type to _car_type_id
+          idx = match.attribute_names.find_index { |n| n == @as_name.to_s }
+          if not idx.nil?
+            self.new.send "#{@as_name}=", arguments[idx] #Make sure there's a cached value
+            arguments[idx] = @cls.id_for arguments[idx] #Change the argument
+            method_id = method_id.to_s.sub /(by|and)_#{@as_name}$/, "\\1_#{@as_name}_id"
+            method_id = method_id.to_s.sub /(by|and)_#{@as_name}_and/, "\\1_#{@as_name}_id_and"
+            method_id = method_id.to_sym
+          end 
+        end 
+        super
+      end
+
+      #Define the link between the host class and the newly created ActiveRecord
+      belongs_to lookup_name.to_s.to_sym, :foreign_key => "#{as_name}_id".to_sym
+      validates "#{as_name.to_s}_id".to_sym, :presence => true
+
+      #Prefill the hashes from the DB
+      all_vals = cls.all
+      cls.class_variable_set(:@@rcaches, all_vals.inject({}) do |r, obj|
+        r[obj.name] = obj.id
+        r
+      end)
+      cls.class_variable_set(:@@caches, all_vals.inject([]) do |r, obj|
+        r[obj.id] = obj.name
+        r
+      end)
+    end
+  end
+
+  # extend host class with class methods when we're included 
+  def self.included(host_class)
+    host_class.extend(ClassMethods) 
+  end
+end
+end

data/rails_lookup.gemspec

@@ -0,0 +1,168 @@
+# -*- encoding: utf-8 -*-
+
+Gem::Specification.new do |s|
+  s.name = %q{rails_lookup}
+  s.version = "0.0.1"
+
+  s.required_rubygems_version = Gem::Requirement.new(">= 1.2") if s.respond_to? :required_rubygems_version=
+  s.authors = [%q{Nimrod Priell}]
+  s.date = %q{2011-08-06}
+  s.description = %q{Lookup tables with ruby-on-rails
+--------------------------------
+
+By: Nimrod Priell
+
+This gem adds an ActiveRecord macro to define memory-cached, dynamically growing, normalized lookup tables for entity 'type'-like objects. Or in plain English - if you want to have a table containing, say, ProductTypes which can grow with new types simply when you refer to them, and not keep the Product table containing a thousand repeating 'type="book"' entries - sit down and try to follow through.
+
+Motivation
+----------
+
+A [normalized DB][1] means that you want to keep types as separate tables, with foreign keys pointing from your main entity to its type. For instance, instead of 
+ID          | car_name        | car_type
+1           | Chevrolet Aveo  | Compact
+2           | Ford Fiesta     | Compact
+3           | BMW Z-5         | Sports
+
+You want to have two tables:
+ID  | car_name        | car_type_id
+1   | Chevrolet Aveo  | 1
+2   | Ford Fiesta     | 1
+3   | BMW Z-5         | 2
+
+And
+
+car_type_id | car_type_name 
+1           | Compact
+2           | Sports
+
+The pros/cons of a normalized DB can be discussed elsewhere. I'd just point out a denormalized solution is most useful in settings like [column oriented DBMSes][2]. For the rest of us folks using standard databases, we usually want to use lookups.
+
+The usual way to do this with ruby on rails is
+* Generate a CarType model using `rails generate model CarType name:string`
+* Link between CarType and Car tables using `belongs_to` and `has_many`
+
+Then to work with this you can transparently read the car type:
+
+    car = Car.all.first
+    car.car_type.name # returns "Compact"
+
+Ruby does an awesome job of caching the results for you, so that you'll probably not hit the DB every time you get the same car type from different car objects.
+
+You can even make this shorter, by defining a delegate to car_type_name from CarType:
+
+*in car_type_name.rb*
+    
+    delegate :name, :to => :car, :prefix => true
+
+And now you can access this as 
+
+    car.car_type_name
+
+However, it's less pleasant to insert with this technique:
+
+    car.car_type.car_type_name = "Sports"
+    car.car_type.save!
+    #Now let's see what happened to the OTHER compact car
+    Car.all.second.car_type_name #Oops, returns "Sports"
+
+Right, what are we doing? We should've used
+
+    car.update_attributes(car_type: CarType.find_or_create_by_name(name: "Sports"))
+
+Okay. Probably want to shove that into its own method rather than have this repeated in the code several times. But you also need a helper method for creating cars that way…
+
+Furthermore, ruby is good about caching, but it caches by the exact query used, and the cache expires after the controller action ends. You can configure more advanced caches, perhaps.
+
+The thing is all this can get tedious if you use a normalized structure where you have 15 entities and each has at least one 'type-like' field. That's a whole lot of dangling Type objects. What you really want is an interface like this:
+
+    car.all.first
+    car.car_type #return "Compact"
+    car.car_type = "Sports" #No effect on car.all.second, just automatically use the second constant
+    car.car_type = "Sedan" #Magically create a new type
+
+Oh, and it'll be nice if all of this is cached and you can define car types as constants (or symbols). You obviously still want to be able to run:
+
+    CarType.where (:id > 3) #Just an example of supposed "arbitrary" SQL involving a real live CarType class
+
+But you wanna minimize generating these numerous type classes. If you're like me, you don't even want to see them lying around in app/model. Who cares about them?
+
+I've looked thoroughly for a nice rails solution to this, but after failing to find one, I created my own rails metaprogramming hook.
+
+Installation
+------------
+
+The result of this hook is that you get the exact syntax described above, with only two lines of code (no extra classes or anything):
+In your ActiveRecord object simply add
+
+    require 'active_record/lookup'
+    class Car < ActiveRecord::Base
+      #...
+      include ActiveRecord::Lookup
+      lookup :car_type
+      #...
+    end
+
+That's it. the generated CarType class (which you won't see as a car_type.rb file, obviously, as it is generated in real-time), contains some nice methods to look into the cache as well: So you can call
+
+    CarType.id_for "Sports" #Returns 2
+    CarType.name_for 1 #Returns "Compact"
+
+and you can still hack at the underlying ID for an object, if you need to:
+
+    car = car.all.first
+    car.car_type = "Sports"
+    car.car_type_id #Returns 2
+    car.car_type_id = 1
+    car.car_type #Returns "Compact"
+
+The only remaining thing is to define your migrations for creating the actual database tables. After all, that's something you only want to do once and not every time this class loads, so this isn't the place for it. However, it's easy enough to create your own scaffolds so that 
+
+     rails generate migration create_car_type_lookup_for_car
+
+will automatically create the migration
+
+    class CreateCarTypeLookupForCar < ActiveRecord::Migration
+      def self.up
+        create_table :car_types do |t|
+          t.string :name
+          t.timestamps #Btw you can remove these, I don't much like them in type tables anyway
+        end
+    
+        remove_column :cars, :car_type #Let's assume you have one of those now…
+        add_column :cars, :car_type_id, :integer #Maybe put not_null constraints here.
+      end
+
+      def self.down
+        drop_table :car_types
+        add_column :cars, :car_type, :string
+        remove_column :cars, :car_type_id
+      end
+    end
+
+I'll let you work out the details for actually migrating the data yourself. 
+
+[1] http://en.wikipedia.org/wiki/Database_normalization
+[2] http://en.wikipedia.org/wiki/Column-oriented_DBMS
+
+I hope this helped you and saved a lot of time and frustration. Follow me on twitter: @nimrodpriell
+
+}
+  s.email = %q{@nimrodpriell}
+  s.extra_rdoc_files = [%q{README}, %q{lib/active_record/lookup.rb}]
+  s.files = [%q{README}, %q{Rakefile}, %q{lib/active_record/lookup.rb}, %q{Manifest}, %q{rails_lookup.gemspec}]
+  s.homepage = %q{http://github.com/Nimster/RailsLookup/}
+  s.rdoc_options = [%q{--line-numbers}, %q{--inline-source}, %q{--title}, %q{Rails_lookup}, %q{--main}, %q{README}]
+  s.require_paths = [%q{lib}]
+  s.rubyforge_project = %q{rails_lookup}
+  s.rubygems_version = %q{1.8.7}
+  s.summary = %q{Lookup table macro for ActiveRecords}
+
+  if s.respond_to? :specification_version then
+    s.specification_version = 3
+
+    if Gem::Version.new(Gem::VERSION) >= Gem::Version.new('1.2.0') then
+    else
+    end
+  else
+  end
+end

metadata

@@ -0,0 +1,112 @@
+--- !ruby/object:Gem::Specification 
+name: rails_lookup
+version: !ruby/object:Gem::Version 
+  prerelease: 
+  version: 0.0.1
+platform: ruby
+authors: 
+- Nimrod Priell
+autorequire: 
+bindir: bin
+cert_chain: []
+
+date: 2011-08-06 00:00:00 Z
+dependencies: []
+
+description: "Lookup tables with ruby-on-rails\n\
+  --------------------------------\n\n\
+  By: Nimrod Priell\n\n\
+  This gem adds an ActiveRecord macro to define memory-cached, dynamically growing, normalized lookup tables for entity 'type'-like objects. Or in plain English - if you want to have a table containing, say, ProductTypes which can grow with new types simply when you refer to them, and not keep the Product table containing a thousand repeating 'type=\"book\"' entries - sit down and try to follow through.\n\n\
+  Motivation\n\
+  ----------\n\n\
+  A [normalized DB][1] means that you want to keep types as separate tables, with foreign keys pointing from your main entity to its type. For instance, instead of \n\
+  ID          | car_name        | car_type\n\
+  1           | Chevrolet Aveo  | Compact\n\
+  2           | Ford Fiesta     | Compact\n\
+  3           | BMW Z-5         | Sports\n\n\
+  You want to have two tables:\n\
+  ID  | car_name        | car_type_id\n\
+  1   | Chevrolet Aveo  | 1\n\
+  2   | Ford Fiesta     | 1\n\
+  3   | BMW Z-5         | 2\n\n\
+  And\n\n\
+  car_type_id | car_type_name \n\
+  1           | Compact\n\
+  2           | Sports\n\n\
+  The pros/cons of a normalized DB can be discussed elsewhere. I'd just point out a denormalized solution is most useful in settings like [column oriented DBMSes][2]. For the rest of us folks using standard databases, we usually want to use lookups.\n\n\
+  The usual way to do this with ruby on rails is\n\
+  * Generate a CarType model using `rails generate model CarType name:string`\n\
+  * Link between CarType and Car tables using `belongs_to` and `has_many`\n\n\
+  Then to work with this you can transparently read the car type:\n\n    car = Car.all.first\n    car.car_type.name # returns \"Compact\"\n\n\
+  Ruby does an awesome job of caching the results for you, so that you'll probably not hit the DB every time you get the same car type from different car objects.\n\n\
+  You can even make this shorter, by defining a delegate to car_type_name from CarType:\n\n\
+  *in car_type_name.rb*\n    \n    delegate :name, :to => :car, :prefix => true\n\n\
+  And now you can access this as \n\n    car.car_type_name\n\n\
+  However, it's less pleasant to insert with this technique:\n\n    car.car_type.car_type_name = \"Sports\"\n    car.car_type.save!\n    #Now let's see what happened to the OTHER compact car\n    Car.all.second.car_type_name #Oops, returns \"Sports\"\n\n\
+  Right, what are we doing? We should've used\n\n    car.update_attributes(car_type: CarType.find_or_create_by_name(name: \"Sports\"))\n\n\
+  Okay. Probably want to shove that into its own method rather than have this repeated in the code several times. But you also need a helper method for creating cars that way\xE2\x80\xA6\n\n\
+  Furthermore, ruby is good about caching, but it caches by the exact query used, and the cache expires after the controller action ends. You can configure more advanced caches, perhaps.\n\n\
+  The thing is all this can get tedious if you use a normalized structure where you have 15 entities and each has at least one 'type-like' field. That's a whole lot of dangling Type objects. What you really want is an interface like this:\n\n    car.all.first\n    car.car_type #return \"Compact\"\n    car.car_type = \"Sports\" #No effect on car.all.second, just automatically use the second constant\n    car.car_type = \"Sedan\" #Magically create a new type\n\n\
+  Oh, and it'll be nice if all of this is cached and you can define car types as constants (or symbols). You obviously still want to be able to run:\n\n    CarType.where (:id > 3) #Just an example of supposed \"arbitrary\" SQL involving a real live CarType class\n\n\
+  But you wanna minimize generating these numerous type classes. If you're like me, you don't even want to see them lying around in app/model. Who cares about them?\n\n\
+  I've looked thoroughly for a nice rails solution to this, but after failing to find one, I created my own rails metaprogramming hook.\n\n\
+  Installation\n\
+  ------------\n\n\
+  The result of this hook is that you get the exact syntax described above, with only two lines of code (no extra classes or anything):\n\
+  In your ActiveRecord object simply add\n\n    require 'active_record/lookup'\n    class Car < ActiveRecord::Base\n      #...\n      include ActiveRecord::Lookup\n      lookup :car_type\n      #...\n    end\n\n\
+  That's it. the generated CarType class (which you won't see as a car_type.rb file, obviously, as it is generated in real-time), contains some nice methods to look into the cache as well: So you can call\n\n    CarType.id_for \"Sports\" #Returns 2\n    CarType.name_for 1 #Returns \"Compact\"\n\n\
+  and you can still hack at the underlying ID for an object, if you need to:\n\n    car = car.all.first\n    car.car_type = \"Sports\"\n    car.car_type_id #Returns 2\n    car.car_type_id = 1\n    car.car_type #Returns \"Compact\"\n\n\
+  The only remaining thing is to define your migrations for creating the actual database tables. After all, that's something you only want to do once and not every time this class loads, so this isn't the place for it. However, it's easy enough to create your own scaffolds so that \n\n     rails generate migration create_car_type_lookup_for_car\n\n\
+  will automatically create the migration\n\n    class CreateCarTypeLookupForCar < ActiveRecord::Migration\n      def self.up\n        create_table :car_types do |t|\n          t.string :name\n          t.timestamps #Btw you can remove these, I don't much like them in type tables anyway\n        end\n    \n        remove_column :cars, :car_type #Let's assume you have one of those now\xE2\x80\xA6\n        add_column :cars, :car_type_id, :integer #Maybe put not_null constraints here.\n      end\n\n      def self.down\n        drop_table :car_types\n        add_column :cars, :car_type, :string\n        remove_column :cars, :car_type_id\n      end\n    end\n\n\
+  I'll let you work out the details for actually migrating the data yourself. \n\n\
+  [1] http://en.wikipedia.org/wiki/Database_normalization\n\
+  [2] http://en.wikipedia.org/wiki/Column-oriented_DBMS\n\n\
+  I hope this helped you and saved a lot of time and frustration. Follow me on twitter: @nimrodpriell\n\n"
+email: "@nimrodpriell"
+executables: []
+
+extensions: []
+
+extra_rdoc_files: 
+- README
+- lib/active_record/lookup.rb
+files: 
+- README
+- Rakefile
+- lib/active_record/lookup.rb
+- Manifest
+- rails_lookup.gemspec
+homepage: http://github.com/Nimster/RailsLookup/
+licenses: []
+
+post_install_message: 
+rdoc_options: 
+- --line-numbers
+- --inline-source
+- --title
+- Rails_lookup
+- --main
+- README
+require_paths: 
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement 
+  none: false
+  requirements: 
+  - - ">="
+    - !ruby/object:Gem::Version 
+      version: "0"
+required_rubygems_version: !ruby/object:Gem::Requirement 
+  none: false
+  requirements: 
+  - - ">="
+    - !ruby/object:Gem::Version 
+      version: "1.2"
+requirements: []
+
+rubyforge_project: rails_lookup
+rubygems_version: 1.8.7
+signing_key: 
+specification_version: 3
+summary: Lookup table macro for ActiveRecords
+test_files: []
+