Fork me on GitHub

The WebDevil

Enjoy development

Робко и нерешительно я начал делать первые шаги по рельсам. И что я могу сказать – мне нравится.

Первое с чем я пока столкнулся – с ковырянием в БД. Реализация – просто зверь!
Миграции – это нечто. Итак, для начала имеем пустую миграцию – версия 0. Далее была создана миграция (автоматом) v1. Что есть миграция? Вот что:

class CreateNews < ActiveRecord::Migrationdef self.up
create_table :news, :force=&gt;true,  :options=>"ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_unicode_ci" do |t|
t.column :title, :string, :limit=>255, :null => false
t.column :teaser, :text, :null => false
t.column :body, :text, :null => false
t.column :created_at, :datetime, :null => false
t.column :updated_at, :datetime, :null => false
end
end

def self.down
drop_table :newsend
end

По привычке у меня установлен mysql (v5). И когда первый разописал структуру, тотекстовые данные сплошь были latin1. Потому в опциях добавил кодировку. Но после этого таблица стала не InnoDB! Оказалось, что по умолчанию рельсы создают таблицы типа InnoDB, если другое не указано в опциях. Как только добавляешь опции – требуется указать и таблицу. Ну вот и указал.

У многих возникает вопрос: а зачем же описывать структуру БД в коде? А для того, чтоб можно было красиво и легко переходить между изменениями, внесенными в процессе разработки. И не говорите, что БД спроектированная в начале работы над проектом не меняется никогда- не поверю, сам давно так думал, но всегда что-то но менялось.

И вот можно в следующей миграции описать какие поля добавить, что где поменять и т.п. – и в консоли на сервере сделать rake db:migrate VERSION=x. Разве это не удобно? Например, при откате на предыдущую версию тут же можно описать какие действия выполнять.

Ну и кроме миграций есть еще один плюс, который бросился мне в глаза: ведь эту же структуру не изменяя (вероятней всего, еще не пробовал) можно загнать и в PostgreSQL, и хоть в оракл.

И после этого – вот такой код для выбора всех новостей:

def index
  @news = News.find(:all)
end

После написания таких кусочков задумался, а как же реализованы шаблоны и сильно порадовался – есть такая штука как layout и, собственно, view. View используется для отображения конкретного куска, а layout и есть шаблон всей страницы.

Layout:

<html><head><title>FirstStep</title>
< %= javascript_include_tag 'prototype'%>
</head><body>
< %= yield %></body>
</html>

View:

<ul>< % @news.each do |sss| %>
<li>
< %= sss.title %>

</li>
< % end %>
</ul>

Вот что я могу сказать о первых своих шагах – жутко нравится.

4 Responses to “Rails: first steps”

  1. В Оракле все колонки таблицы должны быть большими буквами. Или я что-то незнаю.

    Артём Курапов

  2. С точки зрения пользователя ORM-у, тебе должно быть всеравно как это ложиться в базу данных. Ты за это не “отвечаешь”. Rails сами думают большие или маленькие должны быть колонки у таблиц. Ты пишешь только код обьекта, а за тебя сохраняют, удаляют обьект.

    erka

  3. >Артём Курапов
    Имел опыт (небольшой) работы с ораклом. Совсем необязательно.

    >erka
    Вот за это я и люблю ORM.

    dm

  4. И вот можно в следующей миграции описать какие поля добавить, что где поменять и т.п. – и в консоли на сервере сделать rake db:migrate VERSION=x. Разве это не удобно? Например, при откате на предыдущую версию тут же можно описать какие действия выполнять.

    Удобно, но местами заставляет сильно помучаться. В миграциях можно юзать модели рельсов. Т.е. сделал add_column, обновил состояние моделей через Post.find(:all).each{|post| …}.
    Через какое-то время добавил еще поле, а в модели — after_save метод, который использует это поле. Все, приплыли: теперь ты не сможешь запустить первую миграцию, посколько будет валиться модель, использующая поле, которое добавилось позже.

    Честно говоря, ваще не знаю, что с этим делать. Такое случается слишком часто и отбирает кучу сил и времени…

    Dmytro Shteflyuk