и выборку делать по ней

так, спасибо, пойду гуглить про eager_load и полиморфные ассоциации

если все эти сущности что-то типо новостей, то можно сделать агрегирующую сущность и связать с этими полиморфной ассоциацией

если я так сделаю, я не смогу, допустим, у Articles сделать Article.where(approved: true) ?

@feed = Article.approved + Image.approved + Video.approved @feed = @feed.sort_by { |obj| obj.created_at } вот простой вариант, но как впихнуть туда пагинацию блин..

пагинацию впихнуть легко, но тут ты кладешь в память все эти записи

https://github.com/amatsuda/kaminari#paginating-a-generic-array-object

ну да, я про это и говорил) как выбрать только нужные записи в @feed = Article.approved + Image.approved + Video.approved непонятно

ща все работает вот с этим https://github.com/mislav/will_paginate/blob/master/lib/will_paginate/array.rb , но когда будет много записей будет печаль

заведи ещё одну модельку Post has_one :article, :image, :video и работай с ней

заведи ещё одну модельку Post has_one :article, :image, :video и работай с ней

потом нужно будет как-то выбирать допустим только Article с category_id: 1, если я сделаю Post, то не получится же так?

получится через джойны

Post.joins(:article).where(articles: { category_id: 1 })

окей, большое спасибо всем, пойду дальше пытаться))

Используй paginate_by_sql. sql = 'SELECT *, 'article' AS category FROM articles UNION ALL SELECT *, 'image' AS category FROM images UNION ALL SELECT *, 'video' AS category FROM videos ORDER BY "created_at" DESC' Feed.paginate_by_sql(sql, :page => @page, :per_page => @per_page) Где Feed будет AR::Base моделью без собственной таблицы. Замени * в селектах на поля которые тебе нужны, и опрелели в Feed эти поля через attr_accessor.

печальный совет

печальный совет

а почему печальный, не мог бы объяснить? а то он мне кажется самым простым)

мне кажется feed должен быть реальным а не генерироваться на лету.

а почему печальный, не мог бы объяснить? а то он мне кажется самым простым)

ну если ты с результатом работать потом не планируешь, то ок. Тебе потенциально нужно созавать sql для каждой комбинации таблиц и непонятно как эти комбинации потом фильтровать. Если появится ещё одна таблица — будет ещё груснее. И это если не брать в расчёт производительность union.

article, image, video

это все наверное стоит сделать STI?

ну если ты с результатом работать потом не планируешь, то ок. Тебе потенциально нужно созавать sql для каждой комбинации таблиц и непонятно как эти комбинации потом фильтровать. Если появится ещё одна таблица — будет ещё груснее. И это если не брать в расчёт производительность union.

все, понял, спасибо!

Тогда производительность будет лучше чем делать три выборки

и псевдоленту будет проще генерировать

это все наверное стоит сделать STI?

STI же для таблиц с одинаковыми полями или я что-то не так понял?) У меня сейчас разные поля в каждой таблице

Насколько сильно разные?

sti просто будет оставлять ненужные поля пустыми

Я так понимаю что это типо пикабушный сайт или подобный?

я когда нечто подобное делал решил что с STI оптимально.

Выборки получаются быстрые, а шаблонизатор сам разберется как каждый тип записи обработать

и псевдоленту будет проще генерировать

И как будет выглядеть запрос для получения всех трёх типов с order by created_at?

Post.fresh ?

и полагаться на created_at, ну ... не факт.

скорее published_at ?

сейчас и есть published_at, я написал created_at для упрощения)

поля достаточно разные

сайт новостной (кусок говна какой-то) :D

Насколько разные?

STI редко бывает оптимальным решением

У тебя есть поле заголовок, описание, контент, автор_ид и дата_публикации полагаю. что то еще?

STI редко бывает оптимальным решением

Ну, выборки быстрые получаются. Псевдоленту на лету можно формировать

Да и у схожих сущностей многие поля схожие.

ага, только потом ты станешь постепенно замечать, что твои модельки не такие уж и одинаковые

и начнется ад

Это если задача не ясна.

А если тебе ясно как это будет выглядеть, то можно получить и плюсы.

Например если всех наследовать от Post, то можно делать state машины только для Post

можно, но в исключительных ситуациях

Например убрать пост в черновик и т.д

а как пост выглядит уже дело шаблонизатора

Ну STI далеко не панацея, и далеко не везде удобен.

Но здесь, имхо конечно, зависит от задачи, должен прокатить.

ладно, сейчас тогда попробую STI заюзать, попробовав как можно больше схожими сделать таблицы. Спасибо)

ладно, сейчас тогда попробую STI заюзать, попробовав как можно больше схожими сделать таблицы. Спасибо)

От задачи зависит как выше сказали, с STI тоже можно обжечься. Но вроде должно прокатить.

Через полиморфные связи тоже неплохо может выйти. И

И это попроще в реализации, чем сейчас на уже созданных моделях городить STI, как мне кажется

Вот публикация видео/статьи/фотки - это что за операция? При одном раскладе - это изменение условного поля статус или state у видео/статьи/фотки, и апдейт published_at. Либо просто установка published_at текущей датой вместо nil.

При другом же раскладе мы можем хранить факт публикации в отдельной модели Publication. В ней оформляем полиморфную связь на ресурс, который публикуем. И операция публикации любого из трех ресурсов - это создание записи publication со ссылкой на этот ресурс

Таким образом построение ленты сведется к Publication.all.order(created_at: :desc).page(params[:page])

А во вьюхе в цикле будем делать так: - publications.each do |publication| = render publication

Ошибка, рендер вот так: = render publication.resource

где resource - полиморфная ссылка на публикуемый ресурс

рельса должна сама определить при этом тип ресурса и отрендерить его в соответствующем паршиале (_video.slim, _picture.slim, _article.slim)

Полиморфная связь это разве не несколько выборок сразу?

с STI выборка из одной таблицы идет

плюс расчет на то что многие поля одинаковые.

кстати задавался уже вопросом

ERROR: S client not available

В данном случае выборка будет одна, из Publication

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

полиморфная модель в этмо случае

а полиморфные ресурсы будут на eager_load

там же будет джоин

а полиморфные ресурсы будут на eager_load

Т.е 4 запроса

то есть кеширование

Получить публикации, получить для каждого из них

для ленты это отлично

то есть кеширование

Заткнуть проблему вместо решения, отлично.

Может сразу поставить 4 DB сервера? так же проще

пфф, ты хотел сказать - решить проблему?

http://blog.diatomenterprises.com/remove-n1-queries-in-your-ruby-on-rails-app/

ой не, это не то

пфф, ты хотел сказать - решить проблему?

Ну решить проблему покупкой железа, да, или хаком.

недавно просто статья как раз в тему была, о панической нелюбви населения к N+1 запросам в рельсе

Тут N+1 вообще непричем.

нуу, вообще то причем

https://rossta.net/blog/n+1-is-a-rails-feature.html

Вот она

DHH рассказывает почему N+1 это фишка и почему turbolinks рулит https://www.youtube.com/watch?v=ktZLpjCanvg

всего 4 запроса же, к общей коллекции и к релативным

больше

один запрос к publications на коллекцию, и кучка запросов к каждому resource при построении ленты

N+1, где N - количество публикаций на странице

так надо includes сделать

Не надо

+1 includes и inverse_of

Статья выше как раз об этом

Вас в статье вот эта строчка не смущает? Post.all.order(published_at: :desc)

Не-а, и не должна смущать

Пагинацию поставить - не возбраняется