kronos Jun 9 2010 at 02:17

Как можно легко и просто реализовать опции в Ruby on Rails

3 min

1.5K

Ruby on Rails*

+19

Comments 32

UFO landed and left these words here

kronos Jun 9 2010 at 09:06

А что со скоростью работы? Мы же 1 раз создаем все методы и пробегаем по константам

dieinzige Jun 9 2010 at 16:29

А при чем тут скорость?)
Ты всерьез считаешь что читаемость кода проекта важнее куда менее важна чем + 20ms на выборку?)
Оочень приятно при 20+ настройках хранить их в User.constants
это не очевидно, и дело не в программистcких способностях кого — либо, а просто плохо читаемо.
class U < AR::Base
has_many :preferences, куда проще
end
хочется еще больше простоты, не изобретай велосипеды, а посмотри на тот же gem preferences )

shaze Jun 9 2010 at 23:00

Чистейшая «джедайская» предварительная оптимизация :)

yumitsu Jun 9 2010 at 06:04

Спасибо, я когда-то уже видел подобную реализацию, но в PHP.

achurkin Jun 9 2010 at 09:24

А если вам придется делать выборку по всем пользователям, по которым у вас установлен тот или иной флаг — то запросу в базе придется обрабатывать все строки в таблице, если вы будете хранить битовые маски.

UUSER Jun 9 2010 at 10:51

Судя по приведенным примерам опций это просто необходимо будет делать.

aratak Jun 9 2010 at 12:20

Поправьте меня, если я не прав.

Взведенную опцию можно выбирать, с помощью LIKE, как вхождение в строку. Естественно, колонка у вас будет строкой, что не очень хорошо.

Если нас интерисует, допустим, NOTIFY_ON_MAIL, то получается что нас интерисуют пользователи с значением «options» в базе с еденичкой в первом разряде.

 > SELECT * FROM users WHERE users.options LIKE "???1";

А вообще, отдельная таблица options со связью к users, как has_one/belongs_to самое лучшее решение.

Разве это сильно сложно? По крайней мере не сложнее, чем добавить еще один разряд в ваше двоичное поле.

add_column :options, :notify_on_mail, :booleanб :default => :false

А вот выборки будут в сто раз лучше. И не нужно никаких дополнительных define_method и остальных плясок с бубном.

grossu Jun 9 2010 at 13:18

Мне тоже показалась булева колонка втаблице с юзерами будет без всяких извращений.

AlexanderYastrebov Jun 10 2010 at 01:11

Причем автор пишет «чтобы добавлять/изменять/удалять их было максимально просто, изменив при этом как можно меньше кода»
Меня это всегда удивляло, ведь по-идее каждая опция несет некоторую смысловую нагрузку — логику обработки ведь все равно писать.
ALTER TABLE ADD COLUMN… это < 0,01% от того кода что придется написать, вообщем я за булевские колонки в виде таблицы опций one-to-one к таблице пользователей

solenko Jun 9 2010 at 14:03

Колонка не string, а unsigned int.

Ну и запрос не
SELECT * FROM users WHERE users.options LIKE "???1";
а
SELECT * FROM users WHERE (users.options & 1)
Хотя от полного посмотре таблицы это не избавляет.

achurkin Jun 9 2010 at 15:04

а потом настроек становится столько, что они начинают не влезать в unsigned int (=

kronos Jun 9 2010 at 15:05

bigint 64 бита. 64 настройки, куда уж больше то? )

pharod Jun 9 2010 at 16:10

640K ought to be enough for anybody?

Frenzy Jun 9 2010 at 15:53

ну если субд позволяет (=если постгрес, а не мускл), то можно просто достраивать индексы конкретно по нужным опциям, тогда скорость выборки не будет уступать другим вариантам.

это конечно же не значит, что я считаю хранение юзерских настроек в битмапе хорошей идеей.

kronos Jun 9 2010 at 14:07

В рамках моего проекта [галочки оттуда] этого делать не нужно. После допустим добавления комментария проверяем, взведен ли флаг «оповещать о комментариях» и если да — делаем оповещение. Если нужна выборка по флагам, тогда придется придумать что-нибудь другое.

aratak Jun 9 2010 at 14:34

Вот буду я после вас проект доделывать (гипотетическое предположение), буду сильно ругаться на столь неочевидное решение.

Ваш вариант полезен в чисто академических целях. На практике лучше применять стандарнтые решения.
Предполагаю, что рассмотренный выход из ситуации в перспективе породит множество хлопот.

kronos Jun 9 2010 at 14:38

Я его сюда как раз разместил для академических целей. Чтобы люди рассказали как сделали бы они. Как говорится для расширения кругозора [я нигде не утверждал что мое решение единственно приемлимое и правильное]. Что почасти моего проекта, если для вас мое решение не очевидно, то скорей всего вы просто не подходите для доделки моего проекта :)

death_claw Jun 9 2010 at 16:09

>>скорей всего вы просто не подходите для доделки моего проекта :)

Упаси Б-Г!!!

at0mic Jun 9 2010 at 13:19

Мы такое через method_missing делали, но у нас правда постановка задачи была несколько иная — общие настройки сайта, хотя пара движений напильником и запросто делается и для юзеров.
github.com/jaralex/SettingTest

alexandrov Jun 9 2010 at 14:52

Поддерживаю. Я тоже такое делал через method_missing.
Примеры здесь и здесь.

edelweard Jun 9 2010 at 18:19

Всё-таки method_missing хуже, чем define_method, т.к. нужный метод будет при каждом вызове искаться.

at0mic Jun 9 2010 at 18:50

вообщем то на method_missing построено очень много Rails Magick, не думаю, что это очень критично. Зато гораздо более читабельно.

Helsus Jun 9 2010 at 13:21

Разве нельзя для этих целей пользоваться миграциями?

undr Jun 9 2010 at 14:23

class User < ActiveRecord::Base

  OPTIONS = [:option1, :option2, :option3]

  OPTIONS.each_index do |index|
    option = OPTIONS[index]
    const = 1 << index

    define_method(option) do
      self.options & const) != 0
    end

    define_method("#{option}=") do |value|
      if value != "0"
        self.options |= const
      else
        self.options &= ~const
      end
    end
  end
end

мне почемуто подумалось, что так удобней будет. Меньше возможностей запутаться в нулях и единицах, при создании опций.