Add this file: /Library/LaunchDaemons/org.postgres.launchd.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
        "http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
    
    <key>Label</key>
      <string>org.postgres.launchd</string>
    <key>Disabled</key>
      <false/>
    <key>UserName</key>
      <string>_pgsql</string>
    <key>GroupName</key>
      <string>_pgsql</string>
    <key>Program</key>
      <string>/usr/local/pgsql/bin/postmaster</string>
      <key>EnvironmentVariables</key>
      <dict>
              <key>PGDATA</key>
              <string>/usr/local/pgsql/data/</string>
      </dict>
    <key>RunAtLoad</key>
      <true/>
</dict>
</plist>

You can then load it and unload it by issuing:

$ sudo launchctl load /Library/LaunchDaemons/org.postgres.launchd.plist
$ sudo launchctl unload /Library/LaunchDaemons/org.postgres.launchd.plist

Now get to making some great Rails stuff!

psql databasename
\d table_name

Imagine a “Widget” model that is composited of serveral other fields. You might think to yourself.

“An Widget has a SKU ( housed in table ‘skus’ based on model SKU ), a widget has a color, etc.”

You then might model your code such that

    Widget < ActiveRecord::Base
      has_one :sku
      has_one :color
    end

And accordingly

    SKU < ActiveRecord::Base
      belongs_to :widget
    end

This is wrong.

You must think in terms of the most “atomic” element. What’s the relationship of a SKU? A SKU “has one” product to which it is applicable. You see, what you’ve done above is absolutely reverse of the way it should be.

Think this way:

    SKU < ActiveRecord::Base
      has_one :widget
    end

And then just add the mirror entry, for completeness

    Widget < ActiveRecord::Base
      belongs_to :sku
    end

You can see this explained in the Rails API:

class Employee < ActiveRecord::Base
    has_one  ffice
end

class Office < ActiveRecord::Base
   belongs_to :employee    # foreign key - employee_id
end

If you find yourself using the primary key of the composite entity to find something in the the constituent table or getting into weird sorts of problems with .create() or find yourself thinking that you may need to implement something like (although it is pretty cool):

    $ irb
    irb(main):001:0> class K
    irb(main):002:1> end
    => nil
    irb(main):003:0> k1 = K.new
    => #
    irb(main):004:0> k2 = eval('K').new
    => #
    irb(main):005:0> k3 = Object.const_get('K').new
    => #

[Reference]

The real difficulty here is with how English speakers construe the transitivity of the phrase “has one”. Does this mean:

• X is a superior containing entity i.e. “contains” (“The happy meal has one hamburger and one toy”)
• X is uniquely assigned in a relationship (“The parolee has one parole officer”)

The word “relationship” in the second bullet is the use of “has_one” that Rails uses the phrase “has_one” to signify.

If, when getting your object model to work in Rails seems really hard and sorta backwards, you should say “this seems needlessly hard, maybe I’m doing it the wrong way” and bail out of that design. The LOLCatz rules apply here: “Using Rails to make your life easy - ur doin’ it wrong”

The reality is that most people use Rails for web frameworks … the console manipulation stuff we explored in the previous post doesn’t really help us much. We need a web interface. While using the script/generate gave us some scaffolds that we can play with ( http://localhost:3000/candies or ../flavors ), it’s not really “integrated” and it doesn’t quite demonstrate the “has many”-ness.

First we’ll fire up the web server (script/server) and see what the ‘new’ view looks like:

Hm, that’s certainly not giving us any place to enter some flavorful information. Let’s fix that in the view.

    <p>
        <b>Flavors ( comma-delimited )</b><br/>
      <%= f.text_field :flavorstring %>
    </p>

Try reloading the view…

And we get…an error:

    Undefined method `flavorstring' for #<Candy id: nil, name: nil, created_at: nil, updated_at: nil>

What I’m effectively doing here is making us need to call a “virtual attribute”. You see, what goes in here is the CGI code to generate a text field such that we can put in a comma-delimited list of flavors. On the flip side, in other views, we’ll want to have ‘flavorstring’ give us a comma-delimited listing of the associated flavors.

So, let’s add the virtual attribute into the app/models/candy.rb file:

  def flavorstring
     if (self.flavors.length > 0)
       x=String.new()
       self.flavors.uniq.each do |f|
         x += f.name
         x += ", "
       end
       return x.sub(/,\s+$/,'')
     else
       return ""
     end
     
   end
   
   def flavorstring=(input)
       if input.empty?
         self.flavors.destroy_all
       end
       
       self.flavors.destroy_all
       input.gsub(/\s+/, '').split(',').uniq.each do |flav|
         if Flavor.find_by_name(flav).nil?
           self.flavors << Flavor.create(:name=> flav)
         else
           self.flavors << Flavor.find_by_name(flav)
         end
       end
   end

It’s also handy to define the to_s method to return the “name” attribute of this model ( this should also be added to the Flavor model). It means that if anyone executes something like puts aCandy or puts aFlavor they get the name of that item, versus something like <Flavor:124124>.

Reload the view and create some candies with your own tags…

If you want to edit the flavors, you can do so by taking advantage of the scaffolds we created earlier:

http://localhost:3000/flavors

Because I’m sorta anal, i’m going to alphabetically sort my scaffolds. I go to the ‘candies_controller’ or ‘flavors_controller’ and edit the ‘index’ method to make my find command look like:

@candies = Candy.find(:all,  rder=>'name asc')

Hey, looking at that index, it’s notably not showing our flavor data. Let’s fix that.

Now, I know I can get a given Candy’s flavors by issuing aCandy.flavors which will come back as an array. So what I would like to do is find a way to pass an array to a loop, have it assemble some sensible HTML, and then return it to me. This will keep my view neat.

But I also know that, especially in a HABTM relationship, if I want something to work for one side, I’ll probably want it to work for the other side. That is, if I want to get a comma-delimited list of flavors associated with a candy which are links to that flavor ( which should also show the candies associated with it) — I’ll also probably want the reverse, from the perspective of the flavors.

{Yeah, you may want to re-read that a few times }

So I’m going to write a “helper”. I’m not going to put this in the candies_helper or in the flavors_helper.rb. Because of the reflexivity ( Flavor <-> Candy ), I want to put this method into the application_helper.rb and make it sufficiently abstract so that it could be called either by a view associated with a Candy or with a Flavor.

  def link_to_comma_sep_elements(hash)
    html = ''
    hash[:ray].each do |x|
      puts x.class
      html << link_to(x,:controller=>hash[:controller],:action=>hash[:action], :id=>x.class.find(x.id))
      html << ", "
    end
    return html.sub(/,\s+$/, '')
  end

This means it can be called like so:

    <%= link_to_comma_sep_elements(:ray=>candy.flavors, :controller=>"flavors", :action=>"show") %>

I pass an array to the function, a controller(“flavors”) that the comma-ized elements will want to point to and the action they should point to (“show”).

But if i click on one of those flavors, I’m taken to a view of the flavor but without associated candy information. Simple. Add to app/view/flavors/show.html.erb:

    <p>
        <b>Associated Candies: </b>
      <%= link_to_comma_sep_elements(:ray=>@flavor.candies, :controller=>"candies", :action=>"show") %>
    </p>

See! Our helper is already saving is work! Cool eh?

Now say we approach from the /flavors scaffold, what if we want to have a comma-delimited list of associated candies? You guessed it, our helper to the rescue ( again! )

    <table>
      <tr>
        <th>Name</th>
            <th>Candies</th>
      </tr>

    <% for flavor in @flavors %>
      <tr>
        <td><%=h flavor.name %></td>
            <td>
              <%= link_to_comma_sep_elements(:ray=>flavor.candies, :controller=>"candies", :action=>"show") %>
            </td> 
        <td><%= link_to 'Show', flavor %></td>
        <td><%= link_to 'Edit', edit_flavor_path(flavor) %></td>
        <td><%= link_to 'Destroy', flavor, :confirm => 'Are you sure?', :method => :delete %></td>
      </tr>
    <% end %>
    </table>  

Now at this point you have a pretty functional setup. To make playing with and exploring your HABTM relationship a bit easier, I added links at the bottom of each model’s index view so that you could flip between the two.

Flavor’s index: <%= link_to 'See Candies', "candies", :action=>'index' %>

Candy’s index: <%= link_to 'See Flavors', "flavors", :action=>'index' %>

Try it out, experiment, and have fun. And write tutorials! Writing is the best way to learn! Us Rails-ers have to stick together!

Many things in this life have a one to one relationship: a man has a wife ( Utah excepted ), a car has an owner, a dog it’s day. Many other things in life have a one to many relationship: a policy covers many people, a manager has direct reports, etc. But some things have a many to many relationship. People have surnames (“John Smith” is a Smith and so is “Jane Smith”;conversely, among the Smith clan there might be multiple Johns, 42 Janes, and 22 Larry’s ).

It is of this many to many relationship I will write and whose code I seek to share.

In this world there are many candies ( “Now and Laters”, “Sweet Tarts”, and “Kasugai’s Gummies” ) and candies have a flavor (chocolate, strawberry, cherry, and for my readers of an Oriental persuasion, lychee).

There are many candies which have a flavor, and a particular flavor has many candies which apply to it. This is a perfect, and simple example wherewith to demonstrate Rails’ ActiveRecord’s Associations.

Build the Rails install directory

So, let’s start a rails project:

rails -d postgresql candy

And you will get a great deal of noise back:

create  
create  app/controllers
create  app/helpers
create  app/models
create  app/views/layouts
create  config/environments
create  config/initializers
create  db
create  doc
create  lib
create  lib/tasks
create  log
create  public/images
create  public/javascripts
create  public/stylesheets
create  script/performance
create  script/process
create  test/fixtures
create  test/functional
create  test/integration
create  test/mocks/development
create  test/mocks/test
create  test/unit
create  vendor
create  vendor/plugins
create  tmp/sessions
create  tmp/sockets
create  tmp/cache
create  tmp/pids
create  Rakefile
create  README
create  app/controllers/application.rb
create  app/helpers/application_helper.rb
create  test/test_helper.rb
create  config/database.yml
create  config/routes.rb
create  public/.htaccess
create  config/initializers/inflections.rb
create  config/initializers/mime_types.rb
create  config/boot.rb
create  config/environment.rb
create  config/environments/production.rb
create  config/environments/development.rb
create  config/environments/test.rb
create  script/about
create  script/console
create  script/destroy
create  script/generate
create  script/performance/benchmarker
create  script/performance/profiler
create  script/performance/request
create  script/process/reaper
create  script/process/spawner
create  script/process/inspector
create  script/runner
create  script/server
create  script/plugin
create  public/dispatch.rb
create  public/dispatch.cgi
create  public/dispatch.fcgi
create  public/404.html
create  public/422.html
create  public/500.html
create  public/index.html
create  public/favicon.ico
create  public/robots.txt
create  public/images/rails.png
create  public/javascripts/prototype.js
create  public/javascripts/effects.js
create  public/javascripts/dragdrop.js
create  public/javascripts/controls.js
create  public/javascripts/application.js
create  doc/README_FOR_APP
create  log/server.log
create  log/production.log
create  log/development.log
create  log/test.log

Now, let’s imagine a “Candy”, it has a “name”. Similarly a “Flavor” has a “name”. These two will be our models. We’ll use Rails’ new scaffolding to create these models.

Build the Candy and Flavor models

bash-3.2$ cd candy/
bash-3.2$ script/generate scaffold Candy name:string; \
  script/generate scaffold Flavor name:string

Output not displayed

Create the database

bash-3.2$ psql -l |grep -i candy
bash-3.2$ rake db:create
(in /Users/sgharms/railsdev/candy)
bash-3.2$ psql -l |grep -i candy
 candy_development           | sgharms  | UTF8

OK, so there’s our database. Since I don’t want to have to create a user record, I’m going to edit my config/database.yml to make connections to the database anonyomous. I’m going to remove the user and password fields.

>development:
>adapter: postgresql
>encoding: unicode
>database: candy_development
>#  username: candy
>#  password:

Use db:migrate to bring the generated models into the db

bash-3.2$ rake db:migrate
(in /Users/sgharms/railsdev/candy)
== 1 CreateCandies: migrating =========================================
-- create_table(:candies)
NOTICE:  CREATE TABLE will create implicit sequence "candies_id_seq" 
for serial column "candies.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
"candies_pkey" for table "candies"     -> 0.0097s
== 1 CreateCandies: migrated (0.0099s) ================================

== 2 CreateFlavors: migrating =========================================
-- create_table(:flavors)
NOTICE:  CREATE TABLE will create implicit sequence "flavors_id_seq" 
for serial column "flavors.id"
    NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
    "flavors_pkey" for table "flavors"
== 2 CreateFlavors: migrated (0.0071s) ================================

So far so good! Let’s check out the tables.

Examine the tables with Psql, the Postgres CLI tool

Logically enough, a table for holding “Candy”-model based objects and “Flavor”-based objects were created. A simple SQL query shows the contents to match our expectation.

    bash-3.2$ psql candy_development
    Welcome to psql 8.2.5, the PostgreSQL interactive terminal.

    Type:  \copyright for distribution terms
           \h for help with SQL commands
           \? for help with psql commands
           \g or terminate with semicolon to execute query
           \q to quit

    candy_development=# \dt
               List of relations
     Schema |    Name     | Type  |  Owner  
    --------+-------------+-------+---------
     public | candies     | table | sgharms
     public | flavors     | table | sgharms
     public | schema_info | table | sgharms
    (3 rows)

    candy_development=# select * from CANDIES, flavors;
     id | name | created_at | updated_at | id | name 
    ----+------+------------+------------+----+------
    (0 rows)

Well that’s pretty nifty, no entries.

Create the HABTM relationship

Now, we need to make a change to the model. We need to make both of these models recognize the other as a HABTM partner. Simple enough, add these line to “candy.rb” and “flavor.rb” in app/models/, respectively:

has_and_belongs_to_many :flavors
has_and_belongs_to_many :candies

You may be wondering if the plural of “candy” was “candys” or “candies” in Rails’ eyes. Let’s check that out.

bash-3.2$ script/console 
Loading development environment (Rails 2.0.2)
>> "candy".pluralize
=> "candies"

Since we scaffolded these views when we created the model, let’s try adding a Candy.

Start the server:

    >> bash-3.2$ script/server
    => Booting Mongrel (use 'script/server webrick' to force WEBrick)
    => Rails application starting on http://0.0.0.0:3000
    => Call with -d to detach
    => Ctrl-C to shutdown server
    ** Starting Mongrel listening at 0.0.0.0:3000
    ** Starting Rails with development environment...
    ** Rails loaded.
    ** Loading any Rails specific GemPlugins
    ** Signals ready.  TERM => stop.  USR2 => restart.  
    INT => stop (no restart).
    ** Rails signals registered.  HUP => reload (without restart). 
     It might not work well.
    ** Mongrel 1.1.2 available at 0.0.0.0:3000
    ** Use CTRL-C to stop.

And visit http//localhost:3000/candies

You should have a basic scaffold view that you can create candies with.

I added two candies and back in the console I could see…

    >> puts Candy.find(:all).to_yaml
    --- 
    - !ruby/object:Candy 
      attributes: 
        name: PowerThirst Bar
        updated_at: 2008-01-10 18:26:22.882081
        id: "1"
        created_at: 2008-01-10 18:26:22.882081
      attributes_cache: {}

    - !ruby/object:Candy 
      attributes: 
        name: Sweet Tart
        updated_at: 2008-01-10 18:26:38.846037
        id: "2"
        created_at: 2008-01-10 18:26:38.846037
      attributes_cache: {}

The Web UI shows:

Similarly one can create flavors using the scaffold as well, but in this case I’ll use the console:

    >> Flavor
    => Flavor(id: integer, name: string, created_at: datetime, updated_at: datetime)
    >> Flavor.create :name=>"Shockolate"
    => #<Flavor id: 1, name: "Shockolate", created_at: "2008-01-10 18:30:13", updated_at: "2008-01-10 18:30:13">
    >> Flavor.create :name=>"Rawberry"
    => #<Flavor id: 2, name: "Rawberry", created_at: "2008-01-10 18:30:17", updated_at: "2008-01-10 18:30:17">
    >> Flavor.create :name=>"Lychee"
    => #<Flavor id: 3, name: "Lychee", created_at: "2008-01-10 18:30:34", updated_at: "2008-01-10 18:30:34">
    >> Flavor.create :name=>"Strawberry"
    => #<Flavor id: 4, name: "Strawberry", created_at: "2008-01-10 18:30:38", updated_at: "2008-01-10 18:30:38">
    >> Flavor.find_all  
    NoMethodError: undefined method `find_all' for #<Class:0x1b60c3c>
        from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.2-/lib/active_record/base.rb:1532:in `method_missing'
        from (irb):7
    >> Flavor.find(:all)
    => [#<Flavor id: 1, name: "Shockolate", created_at: "2008-01-10 18:30:13", updated_at: "2008-01-10 18:30:13">, #<Flavor id: 2, name: "Rawberry", created_at: "2008-01-10 18:30:17", updated_at: "2008-01-10 18:30:17">, #<Flavor id: 3, name: "Lychee", created_at: "2008-01-10 18:30:34", updated_at: "2008-01-10 18:30:34">, #<Flavor id: 4, name: "Strawberry", created_at: "2008-01-10 18:30:38", updated_at: "2008-01-10 18:30:38">]

You can take a look at your database schema in db/schema.rb:

ActiveRecord::Schema.define(:version => 2) do

  create_table "candies", :force => true do |t|
    t.string   "name"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  create_table "flavors", :force => true do |t|
    t.string   "name"
    t.datetime "created_at"
    t.datetime "updated_at"
  end
end

Create a join table

Now, a HABTM requires a join table, so that the two can look back and forth at one anotherthat’s fancy-talk for a two-way index between these two tables.

The convention that we use is to create a table, that has no primary key, that has the consituentModelNameOne_id as one column and consituentModelNameTwo_id as the other column. When I say ‘constituentModelName’ that should be in the singular. Also, the name of the table should list the plural of the two models, separated by an underscore "_" with the plurals in alphabetical order. In our case this would be “candies_flavors”

This sounds hairy, but I’ll show you. It’s really easy.

<

pre> bash-3.2$ script/generate migration createCandyFlavorJoinTable exists db/migrate create db/migrate/003_create_candy_flavor_join_table.rb bash-3.2$

<

pre>

Excellent! So now let’s create that table. If you forget the syntax, you can look at your 001 or 002 migration in db/migrate to learn how to create a table.

    class CreateCandyFlavorJoinTable < ActiveRecord::Migration
      def self.up
        create_table (:candies_flavors, :id=>false) do |t|
          t.integer :candy_id
          t.integer :flavor_id

          t.timestamps
        end
      end

      def self.down
        drop_table :candies_flavors
      end
    end

Great! All we need to do is use another visit to rake.

bash-3.2$ rake db:migrate
(in /Users/sgharms/railsdev/candy)
== 3 CreateCandyFlavorJoinTable: migrating ====================================
-- create_table(:candies_flavors, {:id=>false})
   -> 0.0049s
== 3 CreateCandyFlavorJoinTable: migrated (0.0051s) ===========================

We can check it out in the Postgres viewer:

candy_development=# select * from candies_flavors ;
 candy_id | flavor_id | created_at | updated_at 
----------+-----------+------------+------------
(0 rows)

So now let’s associate a candy with a flavor.

See what we have

>> Candy.find(:all)
=> [#<Candy id: 1, name: "PowerThirst Bar", created_at: "2008-01-10 18:26:22", updated_at: "2008-01-10 18:26:22">, #<Candy id: 2, name: "Sweet Tart", created_at: "2008-01-10 18:26:38", updated_at: "2008-01-10 18:26:38">]
>> Flavor.find(:all)
=> [#<Flavor id: 1, name: "Shockolate", created_at: "2008-01-10 18:30:13", updated_at: "2008-01-10 18:30:13">, #<Flavor id: 2, name: "Rawberry", created_at: "2008-01-10 18:30:17", updated_at: "2008-01-10 18:30:17">, #<Flavor id: 3, name: "Lychee", created_at: "2008-01-10 18:30:34", updated_at: "2008-01-10 18:30:34">, #<Flavor id: 4, name: "Strawberry", created_at: "2008-01-10 18:30:38", updated_at: "2008-01-10 18:30:38">]

Note that you can now ask a Candy what it’s ‘flavors’ are - with tab-autocomplete:

>> Candy.find(1).fla(TAB)(TAB)vor(TAB)(TAB)
1).flavor_ids    1).flavor_path   1).flavors       1).flavors_path
1).flavor_ids=   1).flavor_url    1).flavors=      1).flavors_url
>> Candy.find(1).flavors
=> []

Similarly, a flavor can be asked its candies:

>> Flavor.find_by_name('Shockolate').candies
=> []

Let’s associate ‘Shockolate’ and ‘Rawberry’ with a PowerThirst Bar

>> example.flavors
=> []
>> example.flavors << Flavor.find_by_name('Shockolate')
=> [#<Flavor id: 1, name: "Shockolate", created_at: "2008-01-10 18:30:13", updated_at: "2008-01-10 18:30:13">]
    >> example.flavors << Flavor.find_by_name('Rawberry')
    => [#<Flavor id: 1, name: "Shockolate", created_at: "2008-01-10 18:30:13", updated_at: "2008-01-10 18:30:13">, #<Flavor id: 2, name: "Rawberry", created_at: "2008-01-10 18:30:17", updated_at: "2008-01-10 18:30:17">]
    >> example.flavors
    => [#<Flavor id: 1, name: "Shockolate", created_at: "2008-01-10 18:30:13", updated_at: "2008-01-10 18:30:13">, #<Flavor id: 2, name: "Rawberry", created_at: "2008-01-10 18:30:17", updated_at: "2008-01-10 18:30:17">]

Let’s see what’s happened in the DB.

candy_development=# SELECT * from candies_flavors ;
 candy_id | flavor_id |         created_at         |         updated_at         
----------+-----------+----------------------------+----------------------------
        1 |         1 | 2008-01-10 18:30:13.002001 | 2008-01-10 18:30:13.002001
        1 |         2 | 2008-01-10 18:30:17.905373 | 2008-01-10 18:30:17.905373
(2 rows)

Unsurprisingly candy 1 (Candy.find(1).name) is associated with flavor id 1 and 2 ( Shockolate and Rawberry, respectively).

Sweet (ur, Shockolate-y?). We have a 1 to many relationship now (“The name “PowerThirst Bar” corresponds two two flavors: Shockolate and Rawberry”). But we want those to also work in reverse. That we could get all the candies that are flavored, say with good old “Strawberry”. To the console!

Add another candy

>> Candy.create :name=>"Now and Later"
=> #<Candy id: 3, name: "Now and Later", created_at: "2008-01-10 19:02:35", updated_at: "2008-01-10 19:02:35">   

Now let’s associate a few candies with ‘Strawberry’ flavor. I’m going to include the PowerThirst bar because Rawberry is a subclass of Strawberry.

    >> strawberry=Flavor.find_by_name('Strawberry')
    => #<Flavor id: 4, name: "Strawberry", created_at: "2008-01-10 18:30:38", updated_at: "2008-01-10 18:30:38">
    >> strawberry.name
    => "Strawberry"
    >> strawberry.candies
    => []
    >> strawberry.candies << Candy.find(1,2,3)
    => [#<Candy id: 1, name: "PowerThirst Bar", created_at: "2008-01-10 18:26:22", updated_at: "2008-01-10 18:26:22">, #<Candy id: 2, name: "Sweet Tart", created_at: "2008-01-10 18:26:38", updated_at: "2008-01-10 18:26:38">, #<Candy id: 3, name: "Now and Later", created_at: "2008-01-10 19:02:35", updated_at: "2008-01-10 19:02:35">]
    >> strawberry.candies
    => [#<Candy id: 1, name: "PowerThirst Bar", created_at: "2008-01-10 18:26:22", updated_at: "2008-01-10 18:26:22">, #<Candy id: 2, name: "Sweet Tart", created_at: "2008-01-10 18:26:38", updated_at: "2008-01-10 18:26:38">, #<Candy id: 3, name: "Now and Later", created_at: "2008-01-10 19:02:35", updated_at: "2008-01-10 19:02:35">]    

So there you have it. You can see the structure beautifully with the .to_yaml method:

    >> puts strawberry.to_yaml
    --- !ruby/object:Flavor 
    attributes: 
      name: Strawberry
      updated_at: 2008-01-10 18:30:38.250826
      id: "4"
      created_at: 2008-01-10 18:30:38.250826
    attributes_cache: {}

    candies: 
    - !ruby/object:Candy 
      attributes: 
        name: PowerThirst Bar
        updated_at: 2008-01-10 18:26:22.882081
        id: "1"
        created_at: 2008-01-10 18:26:22.882081
      attributes_cache: {}

    - !ruby/object:Candy 
      attributes: 
        name: Sweet Tart
        updated_at: 2008-01-10 18:26:38.846037
        id: "2"
        created_at: 2008-01-10 18:26:38.846037
      attributes_cache: {}

    - !ruby/object:Candy 
      attributes: 
        name: Now and Later
        updated_at: 2008-01-10 19:02:35.926161
        id: "3"
        created_at: 2008-01-10 19:02:35.926161
      attributes_cache: {}

    => nil

Or….

    >> puts Candy.find(1).flavors.to_yaml
    --- 
    - !ruby/object:Flavor 
      attributes: 
        name: Shockolate
        updated_at: 2008-01-10 18:30:13.002001
        id: "1"
        flavor_id: "1"
        candy_id: "1"
        created_at: 2008-01-10 18:30:13.002001
      attributes_cache: {}

      readonly: true
    - !ruby/object:Flavor 
      attributes: 
        name: Rawberry
        updated_at: 2008-01-10 18:30:17.905373
        id: "2"
        flavor_id: "2"
        candy_id: "1"
        created_at: 2008-01-10 18:30:17.905373
      attributes_cache: {}

      readonly: true
    - !ruby/object:Flavor 
      attributes: 
        name: Strawberry
        updated_at: 2008-01-10 18:26:22.882081
        id: "4"
        flavor_id: "4"
        candy_id: "1"
        created_at: 2008-01-10 18:26:22.882081
      attributes_cache: {}

      readonly: true
    => nil

With this in shape, we are able to manipulate the tables and the model via the script/console. We next need to beef-up the views — but that’s for the next installment!

In the immortal words of Sid Meier’s “Civilization”: “Time Passes…”

1. \xC4\x81 is the UTF-8 encoding for the Unicode code point U+0101.

2. [Q:] Which table does U+0101 fall into?
   
   [A:] “So the first 128 characters (US-ASCII) need one byte. The next 1920 characters need two bytes to encode. This includes Latin alphabet characters with diacritics, Greek, Cyrillic, Coptic, Armenian, Hebrew, and Arabic characters. The rest of the BMP characters use three bytes, and additional characters are encoded in four bytes.”

3. OK this means that the code point will be of the form: “110yyyyy 10zzzzzz”

4. We will now work to fill in the “y” and “z” values:

5. Hexidecimal “U+0101” converts to binary: “100000001”

6. There are 5 y’s and 6 z’s. So let’s split the above number to match that form: “[00]100-000001”. Note, we moved from the right. Where the leading 0’s were required to turn 100 into 00100, they were pre-pended.

7. Integrate and produce: “110” + “00100” : “10” + “000001” => 11000100 : 10000001

8. Take THESE numbers and convert them back to hex => c4 81

9. String notation for this is \xc4\x81 - violá!

10. Figuring this out letter by letter is a major pain in the keester. A good URL resource is: Fileformat.info or, handily a URI of the form:

http://www.fileformat.info/info/unicode/char/<unicode char value>/index.htm

Special Thanks to: Michael Flester

>>reload!

Changes introduced by rake db:migrate and other tools will not be integrated into the console environment until you reload!

• “Fixtures are used to load sample data before a unit test”.
• “Migrations are used to build DB tables and alter structure of contents thereof ( e.g., delete the “name” column and split the field on comma and put the resultant entries into the “firstname” column and the “lastname” column )”

But what if you need to bring in some good data — not test data, but data that you want for testing and seeing how things look with a “real” data set? What then smarties?

Here was my situation: I had entered data via the scaffolded interface and the the data included many unicode characters (&258;éæ, etc.). I wrote a little JavaScript table specifically to make entering these characters easy from an English keyboard.

I knew that I was going to invariably mess up the data and wanted to have the ability to get this preliminary data set back in ( it’s just safer that way ).

Furthermore the datas contained Unicode and I’ve just not had time to wrap my head around “entering Unicode values via command line into PostGres.

I dumped the data to a YML file with:

[code lang="ruby"]
x=File.open("models.yml")  
x.puts Model.find(:all).to\_yaml  
x.close  
[/code]

Looking at that Yaml data, I have my records.

I put that information into ../test/fixtures/models.yml

This file requires a bit of editing.

You will start with entries that look like:

    - !ruby/object:Model 
      attributes: 
        updated_at: 2008-01-04 19:32:10.874607
        id: "5"
        classification: Fourth
        created_at: 2008-01-04 19:32:10.874607
      attributes_cache: {}

You want to turn this into….

first:
  updated_at: 2008-01-04 19:32:10.874607
  id: "5"
  classification: Fourth

That is, reduce the indents of the “meaty data”, remove the “- !ruby” declaration and then put a numbering tag ( “first” ). This will help you import. You may find it handy to try the following in the console:

[code lang="ruby"]
directory="./test/fixtures"
require 'active_record/fixtures'
Fixtures::create_fixtures( directory, "models")
Conjugation.find(:all)
[/code]

Obviously, good data here is a good sign; errors, a sign of more work.

Then with rake db:load:fixtures I could get my data back in….but I wanted to make this addition hinge on a migration, so that I could move forward and backwards in the migration queue. Thanks to the skateboard book p.273 I found a way.

First I created a migration script/generate migration importBaselineData

Edit the 0xx_import_baseline_data.rb

[code lang="ruby"]
require 'active_record/fixtures'  
  
class LoadSampleData < ActiveRecord::Migration  
  def self.up  
    directory = File.join(File.dirname(__FILE__), "../../test/fixtures")  
    Fixtures::create_fixtures( directory, "models")  
  end  
  
  def self.down  
    Model.delete_all  
  end  
end  
[/code]

Thus with a rake db:migrate my migration with data entry gets entered.

Hello,

I’ve read the (many) re-posts about problems around scaffolding in Rails 2.0 and have followed a number of tutorials and fully understand “how to scaffold” from a technical perspective, but I don’t understand the mindset of how to use the new scaffolding. It seems like a productivity- / agility- regress and I’m thinking I may have failed to properly grok the new setup. In the interest of full disclosure, I’m coming back to Rails after being in other toolkits for about 9 months.

Thanks to the intrepid work of Sean Lynch at ( http://fairleads.blogspot.com/2007/12/rails-20-and-scaffolding-step-by-step.html ) I found a tutorial that would familiarize me with the raw “how to scaffold” material.

I followed his tutorial’s step of:

“ruby script/generate scaffold Movie”

Great! From that point I filled in the “columns” in the migration as I had done in Rails 1.x. All I should need to do is run “rake db:migrate” and try adding a new record via the dynamically-created view.

When I started the server and navigated localhost:3000/movies I had the “create new” button. When I pushed that button there were no text widgets to enter despite having defined the columns that corresponded to said widgets having been added to the migration ( I have a lengthy blog post about how my diagnostics went, for anyone else’s edification ). In short the scaffold that had been created knew nothing of the columns I had added in the migration and, as such, the ‘new’ view had no widgets.

This struck me as well, wrong. On Sean’s post another user confirms the same experience. I have tried it with sqlite3 / mysql / postgres connectors.

Research showed that the scaffold had remained static relative to the time that I had done the original aenemic invocation. Per “script/generate scaffold —help”:

./script/generate scaffold post` # no attributes, view will be anemic

To fix this I had to re-issue the script/generate command with all the attributes in “final draft” mode ( “script/generate scaffold movie title:string text:description one_sheet_url:string” ) and then over-write the old templates ( output stored below, for legibility, Fig. 1).

The solution implies:

• You have to get the script/generate command’s “attributes” arguments perfect at time of creation OR
• You do this overwriting thing that I describe below.

As I recall Rails 1.x’s dynamic scaffolding allowed us to use a scaffold flexibly strictly based on migrations and rake db:migrate. This flexibility allowed us to “sketch” ideas very rapidly. Or is it considered a “Good Thing” that you get a “perfected” “generate scaffold” command at some point? If so, what’s the reasoning? Am I missing some sort of rake command that “refreshes” the scaffold templates?

Based on the comments at Sean’s site and some of the questions in the comments to DHH’s Rails 2. announcement I think there are others grappling with this quandry as well. Can anyone help?

Steven

Fig. 1

bash-3.2$ script/generate scaffold movie title:string text:description one_sheet_url:string
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/
      exists  app/views/movies
      exists  app/views/layouts/
      exists  test/functional/
      exists  test/unit/
overwrite app/views/movies/index.html.erb? (enter "h" for help) [Ynaqdh] y
       force  app/views/movies/index.html.erb
overwrite app/views/movies/show.html.erb? (enter "h" for help) [Ynaqdh] y
       force  app/views/movies/show.html.erb
overwrite app/views/movies/new.html.erb? (enter "h" for help) [Ynaqdh] y
       force  app/views/movies/new.html.erb
overwrite app/views/movies/edit.html.erb? (enter "h" for help) [Ynaqdh] y
       force  app/views/movies/edit.html.erb
   identical  app/views/layouts/movies.html.erb
   identical  public/stylesheets/scaffold.css
  dependency  model
      exists    app/models/
      exists    test/unit/
      exists    test/fixtures/
   identical    app/models/movie.rb
   identical    test/unit/movie_test.rb
        skip    test/fixtures/movies.yml
      exists    db/migrate
Another migration is already named create_movies: db/migrate/001_create_movies.rb