Camping list - Aug 2006 - + migrations in camping

Camping apps are supposed to be little independent apps, often contained in a
single file, which create the database tables and manage them without hassle.
These days it''s common to see in a Camping app:

  module Tepee::Models
    def self.schema(&block)
      @@schema = block if block_given?
      @@schema
    end
  end

  Tepee::Models.schema do
    create_table :tepee_pages, :force => true do |t|
      t.column :title, :string, :limit => 255
      t.column :body, :text
    end
    Tepee::Models::Page.create_versioned_table
  end

The `schema` block describes how to create the tables that Tepee needs.

Yeah, this is in the Tepee sample wiki that comes with Camping.  ActiveRecord is
used to create the tables, it runs once and it''s done.  But what
happens if the
next version of Tepee adds a field?  Well, you write some code to sniff out that
field in the database, right?

== V and Its Float =
Here''s how I could rewrite Tepee to use the V class:

  module Tepee::Models
    class CreatePages < V 1.0
      def self.up
        create_table :tepee_pages, :force => true do |t|
          t.column :title, :string, :limit => 255
          t.column :body, :text
        end
        Tepee::Models::Page.create_versioned_table
      end
      def self.down
        drop_table :tepee_pages
        Tepee::Models::Page.drop_versioned_table
      end
    end
  end

This is only a very light bit of syntax on top of what ActiveRecord already
does.  If you''re not familiar with the up/down methods and how
migrations work,
I''d look into the AR docs[1].

Basically, this class is identifying itself as version 1.0 of the schema.  The
app starts out at 0.0, so the first time you run your app, it''ll
`up`grade to
1.0.  A `schema_info` table is created for each app, containing a single row
with the latest version number in it.

Oh, one other thing:

  def Tepee.create
    Tepee::Models.create_schema
  end

Now the `create_schema` method will update the database when the app is loaded. 
So
stick it in your app''s `create` method[2].  As you''re
developing, you can add
new migration classes, save the file, refresh the page in your browser, and when
The Camping Server reloads your app, it''ll update the database.

_why

[1] http://railsmanual.com/class/ActiveRecord%3A%3AMigration
[2] http://code.whytheluckystiff.net/camping/wiki/GiveUsTheCreateMethod

On Aug 12, 2006, at 11:21 PM, why the lucky stiff wrote:
> Here''s how I could rewrite Tepee to use the V class:
This would be great, please do.  I''ve been playing with Dr.
Nic''s
Magic Models in Camping and so far the only messy part is

unless Blog::Models::Post.table_exists?
   ActiveRecord::Schema.define(&Blog::Models.schema)
end

The Magic Models code creates models on ze fly based on the schema.   
In the Camping blog example, the schema is created if a model''s table  
doesn''t exist.  Catch-22.  Migrations would solve this problem way  
more elegantly than I did.

I''d also propose that adding migrations to Camping brings it one step  
closer to enterprise adoption.

--
Chris Wanstrath
http://errtheblog.com

On 8/13/06, Chris Wanstrath <chris at ozmm.org>
wrote:
> I''d also propose that adding migrations to Camping brings it one
step
> closer to enterprise adoption.
Perish. The. Thought.

On Sun, Aug 13, 2006 at 01:53:57PM -0700, Chris Wanstrath
wrote:
> The Magic Models code creates models on ze fly based on the schema.   
> In the Camping blog example, the schema is created if a model''s
table
> doesn''t exist.  Catch-22.  Migrations would solve this problem way
> more elegantly than I did.
<doot dee doo>  There, the migrations stuff is checked into SVN trunk.
> I''d also propose that adding migrations to Camping brings it one
step
> closer to enterprise adoption.
LOL!!

_why