2015-11-11 1 views
0

Дано:Как Карта многие ко многим Регистрация в Ruby-Mapper объектов

create_table(:foos) do 
    primary_key(:id) 
    String(:name) 
end 

create_table(:bars) do 
    primary_key(:id) 
    String(:name) 
end 

create_table(:foos_bars) do 
    primary_key(:id) 
    foreign_key(:foo_id, :foos) 
    foreign_key(:bar_id, :bars) 
    String(:name) 
end 

class Foos < ROM::Relation[:sql] 
    dataset :foos 

    def with_bars(id) 
    prefix('foos').qualified.select(
     :foos__id, :foos__name 
    ).select_append(
     :bars__id, :bars__name 
    ).left_join(
     :foos_bars, foos_bars__bars_id: :foos__id 
    ).left_join(
     :bars, bars__id: :foos_bars__bars_id 
    ).where(foos__id: id) 
    end 
end 

class FoosModel 
    include Virtus.model 

    attribute :id 
    attribute :name 
    attribute :bars 
end 

class BarsModel 
    include Virtus.model 

    attribute :id 
    attribute :name 
    attribute :foos 
end 

Я пробовал много, много случайных вариаций на ключевые слова, показанных в (но не объяснено) документацию ROM без толку , Вот буквальная интерпретация Документов в картограф для Фооса, который не работает:

class FoosMapper < ROM::Mapper 
    relation :foos 
    register_as :foos 
    model Foo 

    prefix('foos') 
    attribute :id 
    attribute :name 

    group :bars do 
    model Bar 
    attribute :id, from: :bar 
    attribute :name, from: :bar 
    end 
end 

Как один написать картограф (или переделки отношения к работе с картографом), чтобы получить простой результат foo с атрибутом bar, имеющим все бары, связанные таблицей foos_bars?

+0

Это для Ruby on Rails или просто для автономной программы Ruby? – erapert

+0

Это в Rails, хотя я не могу сказать, что видел много интеграции между ПЗУ и Rails - хорошая вещь в моем сознании, поэтому я был бы немного удивлен, если бы был затронут пул возможных ответов. –

ответ

1

Создание сложных объединений, подобных этому, не рекомендуется, если у вас нет веских причин, таких как производительность. Гораздо проще использовать репозитории для создания отношений, определяя представления отношений, которые вам нужны для многократного использования и их компоновки различными способами в репозиториях. Также следует избегать определения настраиваемых карт, если у вас нет уникальных требований.

Я сделал суть, которая показывает, что прямо здесь: https://gist.github.com/solnic/9307e1b2e3428718dd12

Мы работаем над новым набором документации, которая будет правильно объяснить эти вещи.

+0

Спасибо за альтернативу! К сожалению, мне кажется, что нам нужен картограф, поскольку данные должны заканчиваться в пользовательских объектах, имеющих некоторую логику домена. Для чего это мало стоит, я не согласен с удалением одной строки из соединения, а затем добавлением более длинного кода, сложности и непостижимости репозитория-комбайна проще, чем обычная идиома query-and-map-the-graph. –

+0

Надежная загрузка на самом деле намного проще, чем создание большого набора результатов из нескольких объединений и сопоставление его с агрегатами. Я могу показать вам пример пользовательского сопоставления, который бы сделал это лично. Я не согласен, что это проще. Комбинированные репозитории довольно просты, а разделение взглядов на отношение отношений дает вам гораздо лучшую гибкость и способность к компоновке. – solnic

+0

oh еще одна вещь, следующая версия repo будет иметь возможность сопоставлять ваши собственные объекты через 'users.as (MyUser)'. он уже находится у мастера – solnic

Смежные вопросы