0

編集: 実際、私はリブログの方法に反対することに決め、代わりに、記事からまったく新しいレコードをコピーして作成し、それに reblogged: true 列を追加することで実装することにしました。私の意見では、ロジックが少しきれいになり、以下にリストされているすべての問題が回避されます。

ブログ アプリで、2 つの外部キーを使用した結合リブログ モデルを使用して、他の人のブログの記事をリブログする可能性を実装しました。

私のブログ show アクションでは、blog.reblogged_articles を含む blog.articles を 1 つの記事配列に追加しています。次に、この配列を各要素の created_at 属性で並べ替えます。

ただし、リブログされた記事については、リブログ結合モデルの created_at 属性を使用して、リブログされた記事が最初にブログの上部に表示されるようにしたいと思います。リブログされた記事は、ブログの所有者によって作成されたかのように、常にブログ内での位置を取得する必要があります。ただし、現在、3 年前に作成された記事の場合、リブログされた記事がブログの下部に表示されることがあります。

2 つの配列をまとめる前に、おそらく reblogged_articles 配列の created_at 属性を変更する必要があります。しかし、どうすればそれを行うことができますか？

編集：明確にするための単なる例：

ブログ ID 1:
記事 ID 1、created_at: 1 年前。
記事 ID 2、created_at: 1 か月前。
記事 ID 3、created_at: 1 週間前。
記事 ID 4、created_at: 1 日前。

ブログ ID 2:
記事 ID 5、created_at: 1 日前。
記事 ID 6、created_at: 1 時間前。
記事 ID 7、created_at: 30 分前。
記事 ID 8、created_at: 約 10 分前。

さて、Blog 2 は Blog 1 の記事 1 をリブログします。この記事を、Blog 2 の上部に、作成したばかりのように表示したいと思います。しかし、その記事は実際には 1 年前に作成されたものなので、Blog 2 の下部に表示されます。これを回避するにはどうすればよいですか?

記事自体の created_at ではなく、結合モデル Reblog の created_at に基づいて、リブログされた記事を「正しい」位置に配置するための最もスマートなアプローチは何ですか?

4

1 に答える 1

0

おそらく最も簡単な解決策は、記事モデルに last_activity_date 列を追加することです。記事がリブログされるたびに、対応する記事の last_activity_date を更新します。次に、記事を取得しているときに、Article.order(:last_activity_date => 'DESC')

編集：あなたの説明に基づいて -

# Merge arrays of article objects
all_articles = current_blog_articles | reblogged_articles 
all_articles.sort_by! {|x| -x.created_at } # Sort by created_at descending
于 2012-10-24T22:45:26.267 に答える