Ruby on Rails c нуля!

Ассоциации между моделями ч. 2. Экземпляры моделей представляют собой сущности реального мира, а ассоциации между ними являются ни чем иным как отношениями этих сущностей между собой.

ActiveRecord предоставляет несколько возможных ассоциаций (типов отношений) между моделями и все они представлены ниже.

 belongs_to — принадлежность другой модели. Пример:

class Post < ActiveRecord::Base
  belongs_to :category
end

Read the rest of this entry »

RubyDev — ваш друг в изучении Ruby и Rails!

Что такое модель?
Модель — это составляющая часть архитектурного паттерна MVC, которая хранит бизнес логику. В вашем приложении все модели должны храниться в директории app/models в отдельных файлах, имена которых должны соответствовать имени модели, например: Post -> post.rb, InvoiceProduct -> invoice_product.rb.

Как связаны модель и таблица?
В большинстве случаев модель ассоциируется с определенной таблицей в базе данных, например модель Post будет ассоциироваться с таблицей posts. Экземпляр модели являет собой объект представляющий одну запись из таблицы, а сама модель (класс) используется для работы со всей таблицей, например для поиска всех записей соответствующих некоторому условию.

Обратите внимание на то, как называется модель и как называется соответствующая ей таблица. Имя модели — всегда в едином числе, а имя таблицы во множественном.

Как создать модель?
Создать модель можно вручную, но лично я предпочитаю использовать генератор моделей:

$ rails g model Product name:string description:text price:integer
      invoke  active_record
      create    db/migrate/20120210115708_create_products.rb
      create    app/models/product.rb
      invoke    test_unit
      create      test/unit/product_test.rb
      create      test/fixtures/products.yml

Вызывая генератор я передаю в него в качестве аргументов имя модели и имена полей таблицы ассоциируемой с моделью вместе с типами данных этих полей (столбцов).

Генератор модели мне кажется более удобным потому, что одной командой я создаю сразу все необходимые для работы файлы: собственно модель, миграцию для создания соответствующей модели таблицы в БД, файл фикстур и болванку для написания тестов.
Read the rest of this entry »

Rails 3 снабжен очень мощной системой уведомлений о происходящем внутри приложения. Давайте на примере простого приложения рассмотрим то, что есть уведомления и как с ними работать.

Мною было создано простое приложение с одной моделью и контроллером:

$ rails g scaffold User name:string email:string login:string

Именно на примере такого простого приложения мы и рассмотрим уведомления. Давайте запустим наше приложение:

После запуска приложения мы увидим в консоли следущее:

$ rails s
=> Booting WEBrick
=> Rails 3.0.7 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-05-22 11:48:04] INFO  WEBrick 1.3.1
[2011-05-22 11:48:04] INFO  ruby 1.9.2 (2010-08-18) [i686-linux]
[2011-05-22 11:48:04] INFO  WEBrick::HTTPServer#start: pid=3670 port=3000

Это означает, что приложение загружено в память и что сервер приложения был запущен, однако само приложение ничего не выполняет. При переходе на http://localhost:3000/ мы также ничего нового в консоли не убидим, поскольку мы перешли на статическую страницу приветствия, которая нам была отдана нашим сервером, по умолчанию, а не приложением. Однако, когда мы перейдем по адресу http://localhost:3000/users/ то есть приложение выполнит экшен index в контроллере UsersController, то в консоли мы увидим следущее:

Started GET «/users» for 127.0.0.1 at 2011-05-22 11:52:59 +0300
Processing by UsersController#index as HTML
User Load (0.8ms)  SELECT «users».* FROM «users»
Rendered users/index.html.erb within layouts/application (4.4ms)
Completed 200 OK in 158ms (Views: 11.4ms | ActiveRecord: 0.8ms)

Это называется записью логфайла, которая создается на основе уведомлений (Rails Notifications). Если интересно, то файлы логов можно найти в ../log/ в нашем случае это development.log по названию окружения в котором мы работаем. Файл логов содержит абсолютно то же, что было напечатано в консоли.

Если мы перейдем по ссылке создания нового пользователя, то в лог-файле и в консоли появится еще одно сообщение логера:

Started GET «/users/new» for 127.0.0.1 at 2011-05-22 14:20:03 +0300
Processing by UsersController#new as HTML
Rendered users/_form.html.erb (87.8ms)
Rendered users/new.html.erb within layouts/application (107.4ms)
Completed 200 OK in 431ms (Views: 153.4ms | ActiveRecord: 0.0ms)
Read the rest of this entry »

Миграции всегда были одной из основных «фишек» Ruby on Rails. В Rails 3.1 миграции приобретают еще один козырь, который упрощает процесс поддержки логики в up и down методах миграции. Если вам нужно немного восстановить свои знания о миграциях, я рекомендую прочитать официальный .

Давайте начнем с разбора примера миграции из Rails 3.0:

#db/migrate/20110505090317_create_posts.rb
class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end

  def self.down
    drop_table :posts
  end
end

Эта миграция создает в базе данных таблицу posts с двумя полями — title и body тип хранимых данных в которых соответственно string и text. Хэлпер timestamps создает поля типа datetime — created_at и updated_at. Для отката этой миграции нам просто необходимо удалить таблицу posts. Метод .down как раз и занимается откатом миграции — удалением таблицы posts. Когда Rails использует миграцию, миграция запускает метод .up. Для отката миграции (которая выполняется командой rake db:rollback) миграция выполняет метод .down.

Глядя на эту миграцию возникают два вопроса:

- Почему именно методы класса, вместо методов экземпляра класса?
- Для простых случаев почему бы не объявить только метод выполнения миграции и защитить миграцию от отката?

Замечательный человек Аарон Петерсон думает так же и решил упросить миграции.
Read the rest of this entry »