Ruby / Rails Question about Creating a database 1

[Kalisto]

Hi, Ive been coopted onto a distributed team using Ruby on rails, starting next week.

My first task is to look into how we can 'bootstrap' a standard database into our code, so that all the developers are writing / testing against a standard set of sample data.

Ive been reading a few books / websites, and would like to make sure Im on the right track before I waste my time pursuing the wrong soluton.

Am I correct in that the best way to do this is to write a migration file and use rake db:migrate ?

If so, my supplemental questions are then;

Once its all set up, if the database tables are changed (such as adding a new property to a class) is there an automatic way of updating the migration file, or do I need to make sure that the whole team is aware they are responsbile for the migration script ?

Apart from writing the create code in self.up, can I also add in code there to create the default records, or does that have to be done elsewhere ?

If there are multiple tables, am I better off having all the commands in a single migration file, or do I need one per class / table ?

(FWIW Im aware that I need to do more work around creating relations between the tables, but I figured I ought to check Im on the right path, and walking before I try and run..)

TIA

K

 

[Trevoke]

1) 'bootstrap' a standard database? I'm not sure I understand what that means. To build a database from scratch, yeah, you could write everything in a single migration. It would be easier to create migrations along with the model/controller/view for each though (check out 'scaffolds').
This way you end up with several migrations which do small bits - easier to debug if something goes tits up.

2) if you REALLY want to do the whole database at once, you're better off with a schema.rb .. Sample schema.rb from one of my baby rails apps included:

# This file is auto-generated from the current state of the database. Instead of editing this file, 
# please use the migrations feature of Active Record to incrementally modify your database, and
# then regenerate this schema definition.
#
# Note that this schema.rb definition is the authoritative source for your database schema. If you need
# to create the application database on another system, you should be using db:schema:load, not running
# all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended to check this file into your version control system.

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

  create_table "counts", :force => true do |t|
    t.datetime "date"
    t.integer  "count"
    t.integer  "user_id"
    t.integer  "modality_id"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  create_table "dictated_exams", :force => true do |t|
    t.datetime "study_date"
    t.datetime "dictated_date"
    t.string   "patient_name"
    t.string   "procedure_desc"
    t.integer  "user_id"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  create_table "exam_traffics", :force => true do |t|
    t.date     "day",        :default => Date.today, :null => false
    t.integer  "dictated",   :default => 1,            :null => false
    t.integer  "proofread",  :default => 1,            :null => false
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  create_table "modalities", :force => true do |t|
    t.string   "name"
    t.datetime "created_at"
    t.datetime "updated_at"
    t.integer  "aging",      :default => 18, :null => false
  end

  create_table "report_paths", :force => true do |t|
    t.string   "path"
    t.string   "short_name"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  create_table "reports", :force => true do |t|
    t.string   "last"
    t.string   "first"
    t.string   "ssn"
    t.date     "date"
    t.string   "proc"
    t.string   "filename"
    t.string   "modality"
    t.integer  "absolute_age"
    t.boolean  "old"
    t.string   "age"
    t.string   "refphys"
    t.datetime "created_at"
    t.datetime "updated_at"
    t.integer  "report_path_id", :default => 1, :null => false
  end

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

end

3) the best place to prepare sample data is in fixtures. Look those up too

4) If the database needs to change, it is best to do it through Rails. Create a NEW migration detailing the changes, then have Rails run through the db:migrate script.

5) for the relationships between tables, check out

http://api.rubyonrails.org/

and more specifically

http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html

6) Why don't you put the project on github and use a source version control system? This way everyone can putz with the same data, modify it, break it, delete it, re-download it, upload their changes in their own branches, merges can be done as needed. Many people working on a limited and unique set of files is just trouble waiting to happen..

7) If you go to

http://www.ruby-forum.com

you'll get more chances of an answer. Here, a few talented people can help you (and lil' ol' me), and there's more traffic over there.

Mind you, I don't mind helping you - I get to learn stuff in the process

Does this help? Let us know if you need more

Tao Te Ching Discussions : Chapter 9 (includes links to previous chapters)
What is the nature of conflict?

 

[Kalisto]

Certainly helps, and I suspect I'll do the migrations as individual files, as you said its easier to manage

I'll look at the things you suggested, and no doubt I'll be back to ask more later!

Thanks