Продолжение в связке с ActiveRecord каких-либо ошибок? - PullRequest
8 голосов
/ 06 августа 2009

Я подумываю использовать Sequel для некоторых моих SQL-запросов, которые я нахожу слишком сложными в Active Record.

Есть ли что-то, что мне нужно знать при использовании Sequel и ActiveRecord в одном проекте? (Помимо очевидных, таких как отсутствие проверок AR в сиквеле и т. Д.)

Ответы [ 2 ]

20 голосов
/ 07 августа 2009

Отказ от ответственности: я сопровождающий сиквела.

Сиквел легко использовать рядом с ActiveRecord или вместо него при использовании Rails. Вы должны настроить соединение с базой данных вручную, но в остальном использование аналогично. Ваши файлы моделей Sequel находятся в app / models и работают аналогично моделям ActiveRecord.

Настройка соединений с базой данных не утомительна, обычно требуется одна строка в environment.rb, требующая продолжения, и строка в каждом файле среды (development.rb, test.rb, production.rb), выполняющая что-то вроде:

DB = Sequel.connect (...)

Так что это только утомительно, если считать 4 строки кода установки утомительными.

Использование необработанного SQL обычно не является проблемой, если вы не нацелены на несколько баз данных. Основная причина, чтобы избежать этого - повышенное многословие. Sequel поддерживает использование необработанного SQL по крайней мере так же легко, как ActiveRecord, но времена, когда вам нужно использовать необработанный SQL, в Sequel, как правило, довольно редки.

Кстати, сиквел поставляется с несколькими плагинами проверки. Плагин validation_class_methods похож на валидации ActiveRecord, используя методы класса. Плагин validation_helpers имеет более простую реализацию с использованием методов уровня экземпляра, но оба могут делать примерно одно и то же.

Наконец, я скажу, что если у вас уже есть работающий код ActiveRecord, который делает то, что вы хотите, вероятно, не стоит усилий переносить код на Sequel, если вы не планируете добавлять функции.

3 голосов
/ 06 августа 2009

Лично я бы этого не делал. Для начала просто управлять соединением более или менее вручную было бы утомительно. Я был бы более склонен, если бы я чувствовал, что Sequel был более сильным вариантом, отложить для Rails 3.0 (или, возможно, начать разработку против Edge Rails), где должно быть довольно легко переключать ORM, если Yehuda и co все делают правильно , По крайней мере, гораздо более похожий на Merb, чем сейчас.

Это был взгляд DHH на эту тему (я не говорю, что это следует воспринимать как истину Евангелия, разум, но это, так сказать, изо рта лошади):

Но разве это не грязно?

С тех пор, как программисты начали слой объектно-ориентированных систем сверху реляционных баз данных, они боролся с вопросом о том, как глубоко запустить абстракцию. Немного объектно-реляционные картографы стремятся полностью искоренить использование SQL, стремление к объектно-ориентированной чистоте форсировать все запросы через другой OO слой.

Активная запись отсутствует. Было построено при условии, что SQL не является ни грязно ни плохо, просто многословно в тривиальные случаи. Основное внимание уделяется устраняя необходимость иметь дело с многословие в тех тривиальных случаях, но сохраняя выразительность для сложные запросы - тип SQL был создан, чтобы иметь дело с элегантно.

Поэтому вы не должны чувствовать себя виноватым когда вы используете find_by_sql () для обработки либо узкие места производительности или жесткий запросы. Начните с использования объектно-ориентированный интерфейс для производительность и удовольствие, и падение под поверхностью для близкий к металлу опыт, когда вы надо.

(цитата была найдена здесь , оригинальный текст на стр. 334 AWDRWR , книга "Гамак").

Я думаю, что это разумно.

Мы говорим о чем-то, с чем find_by_sql не может справиться? Или мы говорим о сложных невыбранных вещах, с которыми execute не может справиться?

Какие примеры мы могли бы посмотреть?

...