<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>{ height: 1%; } - Ruby on Rails and User Interface Design: On Rails Migrations and PostgreSQL data types</title>
    <link>http://www.height1percent.com/articles/2006/01/30/on-rails-migrations-and-postgresql-data-types</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>CSS, UI Design, Ruby on Rails and cheese ... lots of cheese</description>
    <item>
      <title>On Rails Migrations and PostgreSQL data types</title>
      <description>&lt;p&gt;&lt;a href="http://api.rubyonrails.com/classes/ActiveRecord/Migration.html"&gt;ActiveRecord::Migrations&lt;/a&gt; for &lt;a href="http://www.rubyonrails.org"&gt;Ruby on Rails&lt;/a&gt; is nice and easy way to keep track of sql changes in a &lt;span class="caps"&gt;SQL&lt;/span&gt; server agnostic way. I won&amp;#8217;t get much into the &lt;a href="http://jamis.jamisbuck.org/articles/2005/09/27/getting-started-with-activerecord-migrations"&gt;basics of migrations&lt;/a&gt; since &lt;a href="http://jamis.jamisbuck.org/"&gt;others&lt;/a&gt; have already done a good job of that, but I will say that it has made a mid-project switch from MySQL to PostgreSQL as easy as it really should be.&lt;/p&gt;


	&lt;p&gt;The problem is of course that this database neutrality comes at a price and of course that price is in the form of a lack of precision when defining your schema. Since migrations supports [all sorts] of databases it also ends up only supporting the lowest common denominator of their abilites.&lt;/p&gt;


	&lt;p&gt;Case in point, on a current project I was trying to setup migrations from an existing schema. Unfortunately that schema included &lt;a href="http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-NUMERIC"&gt;bigint(int8)&lt;/a&gt; id columns, and migrations &lt;a href="http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/TableDefinition.html#M000569"&gt;only offers you :integer and :float&lt;/a&gt; in the way of &lt;a href="http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/TableDefinition.html#M000569"&gt;numeric types&lt;/a&gt;. Fortunately getting around these problems is trivial in ruby, if you are willing to give up some of the database portability of migrations.&lt;/p&gt;


All that is required is to override the method in the PostgreSQL adapter that defines the mappings of data types in migrations to database data types and add a mapping for :bigint.
&lt;pre&gt;class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter
 def native_database_types
 {
   &amp;lt;strong&amp;gt;:primary_key =&amp;gt; "bigserial primary key",&amp;lt;/strong&amp;gt;
   :string      =&amp;gt; { :name =&amp;gt; "character varying", :limit =&amp;gt; 255 },
   :text        =&amp;gt; { :name =&amp;gt; "text" },
   :integer     =&amp;gt; { :name =&amp;gt; "integer" },
   :float       =&amp;gt; { :name =&amp;gt; "float" },
   :datetime    =&amp;gt; { :name =&amp;gt; "timestamp" },
   :timestamp   =&amp;gt; { :name =&amp;gt; "timestamp" },
   :time        =&amp;gt; { :name =&amp;gt; "time" },
   :date        =&amp;gt; { :name =&amp;gt; "date" },
   :binary      =&amp;gt; { :name =&amp;gt; "bytea" },
   :boolean     =&amp;gt; { :name =&amp;gt; "boolean" },
   &amp;lt;strong&amp;gt;:bigint      =&amp;gt; { :name =&amp;gt; "int8" }&amp;lt;/strong&amp;gt;
 }
 end
end&lt;/pre&gt;
Those of you that have looked at this method before will notice that I have also changed the :primary_key value from &amp;#8220;serial primary key&amp;#8221; to &amp;#8220;bigserial primary key&amp;#8221;. If you are familiar with PostgreSQL, or have just &lt;a href="http://www.google.com/search?hl=en&amp;#38;lr=&amp;amp;q=postgres+8.1+data+types&amp;amp;btnG=Search"&gt;googled PostgreSQL datatypes&lt;/a&gt; like I did you will find that &lt;a href="http://www.postgresql.org/docs/8.1/static/datatype.html#DATATYPE-SERIAL"&gt;bigserial&lt;/a&gt; is the equivalent of a bigint with auto increment (or identity depending on where you come from).

	&lt;p&gt;Now all there is to do is to include the preceding code in each migration file. I simply created postgre_extensions.rb in the /lib directory of my rails app and added
&amp;#8220;require &amp;#8216;postgre_extensions&amp;#8217;&amp;#8221; to the top of my migration files.&lt;/p&gt;</description>
      <pubDate>Mon, 30 Jan 2006 02:06:00 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:98ad1d918cc948764abcc39577ff1e43</guid>
      <author>Richard White</author>
      <link>http://www.height1percent.com/articles/2006/01/30/on-rails-migrations-and-postgresql-data-types</link>
      <category>rails</category>
      <category>postgresql</category>
      <trackback:ping>http://www.height1percent.com/articles/trackback/1</trackback:ping>
    </item>
    <item>
      <title>"On Rails Migrations and PostgreSQL data types" by Richard White</title>
      <description>&lt;p&gt;I don&amp;#8217;t think I&amp;#8217;ve ever set up DB replication on either MySQL or Postgres so I can&amp;#8217;t help you much there.&lt;/p&gt;</description>
      <pubDate>Wed, 12 Apr 2006 21:14:53 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:</guid>
      <link>http://www.height1percent.com/articles/2006/01/30/on-rails-migrations-and-postgresql-data-types#comment-401</link>
    </item>
    <item>
      <title>"On Rails Migrations and PostgreSQL data types" by Postgres Replication.</title>
      <description>&lt;p&gt;One of the things that makes me hesitate to move to posgtgres is the easy replication I get with mysql including schema changes. I can rake migrate and have my schema changes updated to all the replicas.&lt;/p&gt;


	&lt;p&gt;what do you do about that?&lt;/p&gt;</description>
      <pubDate>Wed, 12 Apr 2006 21:02:24 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:</guid>
      <link>http://www.height1percent.com/articles/2006/01/30/on-rails-migrations-and-postgresql-data-types#comment-400</link>
    </item>
    <item>
      <title>"On Rails Migrations and PostgreSQL data types" by Richard White</title>
      <description>&lt;p&gt;I would map it to an integer in a database and then just convert it in Ruby when you need it. Check out &lt;a href="http://wiki.rubyonrails.com/rails/pages/HowToUseIntegerFieldsAsMoney  "&gt;this page&lt;/a&gt; and a &lt;a href="http://dist.leetsoft.com/api/money/"&gt;Money class&lt;/a&gt; Tobias Luetke created.&lt;/p&gt;</description>
      <pubDate>Wed, 05 Apr 2006 22:51:18 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:</guid>
      <link>http://www.height1percent.com/articles/2006/01/30/on-rails-migrations-and-postgresql-data-types#comment-374</link>
    </item>
    <item>
      <title>"On Rails Migrations and PostgreSQL data types" by Rails4Commerce</title>
      <description>&lt;p&gt;Using float is a horribly frustrating and risky exercise when dealing with money.&lt;/p&gt;


	&lt;p&gt;What is the best way to deal with currency when using ActiveRecord or Rails?&lt;/p&gt;


	&lt;p&gt;Does anyone know how we can map fixed-precision data types in postgresql to a fixed-precision ruby class?&lt;/p&gt;


	&lt;p&gt;Mapping a fixed-precision like numeric or decimal types to ruby&amp;#8217;s float class is absolutely insane. &lt;/p&gt;


	&lt;pre&gt;&lt;code&gt;If you've tried implementing complex systems involving money using float, you know exactly what I mean.&lt;/code&gt;&lt;/pre&gt;


	&lt;p&gt;What do you recommend?&lt;/p&gt;</description>
      <pubDate>Wed, 05 Apr 2006 21:44:41 +0000</pubDate>
      <guid isPermaLink="false">urn:uuid:</guid>
      <link>http://www.height1percent.com/articles/2006/01/30/on-rails-migrations-and-postgresql-data-types#comment-372</link>
    </item>
  </channel>
</rss>
