Сегодня в нашей заметке мы рассмотрим паттерн под названием ActiveRecord, который представляет из себя средство работы с базой данных. Сразу же попрошу профессионалов сильно такого рода заметки не критиковать. Написаны они лишь для того, чтобы заитересовать, дать стимул читать такие книженции как Agile Web Development with Ruby on Rails.

ActiveRecord правильнее даже будет назвать реализацией технологии ORM:
«ORM (англ. Object-relational mapping) — технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных»

ActiveRecord в Ruby on Rails очень меня порадовал, когда впервые с ним познакомился. Его реализации можно найти в разных веб фреймворках, как RoR, CakePHP, Castle и так далее. Идея его состоит в том, что каждая таблица базы данных превращается в класс, каждая строка таблицы в объект этого класса. ActiveRecord обеспечивает методы работы с данными каждого столбца таблицы.

Случилось так, что осваивая Zend Framework я решил написать компонент Zend_ActiveRecord по функциональности как можно более похожий на Rails. Подобное предложение возникало на комьюнити зенда, но давно не обновлялось, да при этом требовало php 5.3 из-за его __callStatic(). Меня этот факт не устроил, но необходимость вызова динамических методов класса модели как статичных по прежнему остается очень актуальной темой, я же попробовал разобраться с этим как раз на примере моей собственной ActiveRecord для зенда

Привет, %username%!

Недавно я начал изучать Ruby on Rails и передо мной встала задача — реализовать импорт данных из CSV файла в MySQL таблицу. Задача не сложная и код я написал довольно быстро, но вот только я был очень удивлен тем, что пока он выполнялся, я успел налить себе кофе и выкурить сигарету.

— Что-то здесь не так! — подумал я и начал копать.

Каждый, кто разрабатывал приложение на RoR знает, что в консоли (./script/console) не слишком удобно просматривать ActiveRecord объекты, они имеют мягко говоря не читабельный вид

Например в моем последнем проекте есть модель Schema

Вчера, в заметке про полиморфные связи в комментариях был упомянут паттерн STI. Как выяснилось, не все знают что это такое, как работает и зачем нужно. Решил восполнить этот информационный пробел и вкратце рассказать об этом шаблоне проектирования и его реализации в Рельсе.

STI (Single Table Inheritance) — паттерн проектирования, который позволяет перенести объектно-ориентированное наследование на таблицу реляционной базы данных. В таблице БД должно присутствовать поле идентифицирующее название класса в иерархии. Зачастую, в том числе в RoR, поле называют type.

Таким образом, мы можем иметь одну таблицу и несколько типов объектов (моделей), которые будут в ней храниться. В случае с вышеупомянутой хабразаметкой — это одна таблица постов, которая хранит посты разных типов: ссылка, подкаст, статья, перевод и т.д.

Дабы не усложнять себе жизнь, в этой статье мы рассмотрим более простой пример: несколько типов пользователей с разными полномочиями и любой другой бизнес-логикой. Пусть это будут: администратор, менеджер и рядовой пользователь.

Приступим.

В данном переводе рассмотрены нововведения в следующей версии ActiveRecrod для Ruby on Rails 3, а так-же описана часть модуля, которая будет исключена в пользу поддержки новых интерфейсов.

Что потеряет поддержку в Rails 3.1?

Следующие методы будут считаться устаревшими в релизе Rails 3.1 (но не Rails 3.0), и будут полностью исключены из Rails 3.2 (хотя можно будет установить специальный плагин для их дальнейшего использования). Имейте в виду это предупреждение, т.к. оно влечет за собой значительные изменения в коде.

В кратце, передача хеша options, содержащего :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :having, :from, :lock любому методу класса, предоставленного ActiveRecord’ом отныне считается устаревшим.

Рассмотрим это более подробно.

Yehuda Katz опубликовал эту запись в своем блоге 10 января 2010 года.

Огромное количество действительно хорошей функциональности Rails 2.3 скрыты в его монолитных компонентах. Я уже публиковал несколько сообщений о том, как мы упростили код маршрутизатора, диспетчера и некоторых частей ActionController, частично реорганизовав функциональность ActionPack. ActiveModel — еще один модуль, появившийся в Rails 3 после реорганизации полезной функциональности.

Библиотеку для работы с базами данных ActiveRecord можно использовать и вне Rails.

Я хотел бы начать серию статей о развитии движка LiveStreet, а именно его фреймворковой части. LiveStreet получил довольно широкую популярность как блогосоциальный хабраклон, но за 2 года перерос уже в нечто значительно большее. Особенно с выходом версии 0.4.*, когда появились широкие возможности для написания плагинов с функционалом наследования и делегирования.
Достаточно большое количество крупных социальных сетей уже построено на LiveStreet с использованием этих технологий.

В связи с этим у разработчиков появляется необходимость в разработке функционала, модулей и хаков для своих проектов. Внедрение плагинов упростило этот процесс в разы. Мы продолжаем работать в этом направлении: сейчас я расскажу об альфа-версии реализации ORM-подхода на основе паттерна ActiveRecord, который мы разработали (и продолжаем разрабатывать) в LiveStreet.

Выход версии 0.5 для меня было нечто большим, чем добавление страницы активности и ленты топиков из подписанных блогов. В новой версии реализованы ORM и ActiveRecord. Вместе они дают мощнейший инструментарий для разработчика, избавляя того от кучи однотипного кода, который приходилось писать каждый раз при разработке плагина. Тот-же форум, о котором будет идти речь в статье, после обновления похудел на 2177 строк кода. В этой статье я хочу углубиться в ORM и AR на примере создания плагина для LiveStreet.

Вы знаете, что когда требуется организовать many-to-many отношения между двумя моделями, прогрессивная часть человечества применяет join-таблицы и метод has_many с опцией :through => :join_model_name. Каждая связь между двумя ActiveRecord-объектами представляет собой ActiveRecord-объект.

И это чудесно, ибо в join-таблице можно насоздавать полезных (так называемых «extra») полей с дополнительной информацией о связях между объектами.

Вопрос в том, как красиво достучаться до этих extra атрибутов.

Все скринкасты и книжки, как назло, оперируют простыми примерами. Например, дружат между собой модели Article и Category. Само собой, для join-класса интуитивно напрашивается имя Categorization или ArticleCategorization.



Соответственно, если у нас есть два объекта — article и category, и мы хотим найти AR-объект (или объекты), олицетворяющий связь между ними, то авторы книжек с чистым сердцем предлагают делать так:

relations = article.article_categorizations.find_by_category_id(category)

В жизни все сложнее. Модели нередко имеют длинные составные имена, либо между моделями такая связь, что придумывание имени для каждой join-модели превращается в маленькую пытку. Представим, что у нас модели не Article и Category, а UserGroup и Community, или Preorder и CustomerNotification. Как должна называться связующая модель? Возможны варианты.

Autodafe — node.js фреймворк для разработки веб приложений

Содержание статьи может описывать неактуальный код. У фреймворка уже давно свой сайт autodafe.ws

Самые вкусные плюшки из коробки:

• архитектура: MVC + подключаемые модули
• Mysql ORM (ActiveRecord с поддержкой отношений, асинхронное подобие того, что предлагает Yii framework для PHP )
• HTTP сервер
• WebSockets ( обертка для socket.io )
• удобное перенаправление запросов и человеко понятные УРЛ
• управление пользователями
  • аутентификация и авторизация, сессии
  • система управления правами ролей пользователей
• почта
• логирование в консоль, фс и на почту
• шаблонизатор

Ложка дегтя:

• очень малая часть задокументирована
• задокументированная часть плохо задокументирована
• плохо задокументированная часть задокументирована только на русском языке
• тестами покрыт не весь фреймворк

Autodafé — node.js фреймворк, начало читайте в этой статье: habrahabr.ru/blogs/nodejs/135089

Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.

Откуда берется пыль

Начнем со схемы, отображающей подключение клиентов к приложению:



На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)

В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.

Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.

Сегодня, занимаясь разработкой одного Ruby on Rails проекта обнаружил странную особенность: падают две spec-и. Ни у кого в проекте не падают, а у меня — падают. Код, gem-ы, система и софт один и тот же, только у меня спеки падают, а у других участников проекта — нет.

Доброго времени суток, дорогой читатель. Ты наверное знаком с популярным web-framework Ruby on Rails. Если нет, то в этом посте ты сможешь найти много интересной и познавательной информации. Одно из его правил – «Одна модель – одна таблица». Следуя ему модель Cat должна брать информацию из таблицы cats, если не указано другое имя. А если наша модель состоит из нескольких, допустим шести, таблиц? Стандартный joins/include методы activerecord тут уже не в помощь.

В процессе превращения большей части web-проектов в браузерные приложения, появляется много вопросов. И один из самых весомых из них – обработка прав доступа без лишнего кода. Размышления на эту тему привели нас к большой проблеме: комфортного способа реализовать защиту на уровне полей модели для ActiveRecord просто нет (Егор, привет! ;). CanCan добавляет ограничения на уровне контроллеров, но это слишком высокий уровень чтобы решить все проблемы.

Немножко пободавшись, мы написали два милых гема. Встречайте, Heimdallr (Хеймдаль) и его расширение Heimdallr::Resource. Они принесут в ваши модели мир и безопасность.

Вышла версия 0.3 node.js фреймворка для разработки веб приложений Autodafe.

У фреймворка появился сайт autodafe.ws, который стремительно обрастает документацией и статьями. (Документация на сайте генерируется автоматически из кода, задокументированного по правилам jsdoc. Поэтому если вы хотите быстро поднять сайт с документацией вашего проекта, можете спросить меня «как?».

В новой версии фреймворка значительно улучшена работа с моделями, писать классы для сохранения данных стало удобнее, а сами они стали выглядеть красивее. Множественное задание атрибутов, их неявная фильтрация во время присвоения, асинхронная валидация моделей и изумительное использование статических методов моделей несомненно сделают вашу жизнь лучше и проще. Работа с моделями в Autodafe.

Подкаст

http://ruby.rpod.ru/281312.html

Новости

• Занимательное функциональное программирование в Ruby
• Active Record loves blocks
• Gitlab 2.7
• Ошибка безопасности в рельсах, новые версии 3.0.16, 3.1.7, 3.2.7
• Active Record Deep Dive
• An Introduction to Celluloid, Part I
• An Introduction to Celluloid, Part II
• RubyMine 4.5
• Rubinius debugging session
• Pat Shaughnessy написал кусок из своей книги «Ruby Under a Microscope» Objects, Classes and Modules
• Fun with ruby hashes

Подкаст

http://ruby.rpod.ru/284727.html

Новости

• Bundler 1.2
• Ruby exit, exit!, SystemExit and at_exit blunder
• Вышел ruboto 0.8.1
• ActiveRecord inheritance and contexts
• Красивый RFC от Heroku
• Pg_power
• Jack Daniels
• How we keep GitHub fast
• Avoiding hash lookups in ruby
• Падшие ангелы: gem fallen
• Recursive sql in activerecord

Вывод результата в JSON достаточно прост в Rails:

render json: @statuses

Это работает отлично, если нужно вывести небольшое количество записей. Но что случится, если нам потребуется вывести сразу 10'000 записей? Производительность серьезно просядет, а самыми затратными по времени окажутся сериализация JSON и операции с базой данных.