0


1

このコードは前の質問からのものですが、私の質問はそれに直接関連しているので、ここにコピーしました。

クラスUser <ActiveRecord :: Base has_many:group_memberships has_many:groups、:through =>:group_memberships end

クラスGroupMembership <ActiveRecord :: Base belongs_to:ユーザーbelongs_to:ロールbelongs_to:グループ終了

クラスRole <ActiveRecord :: Base has_many:group_memberships end

クラスGroup <ActiveRecord :: Base has_many:group_memberships has_many:users、:〜>:group_memberships end

下記の新しい質問

上記のコードをさらに一歩進めて、友達を追加して一緒に仕事をする方法は?

class User <ActiveRecord :: Base has_many:group_memberships has_many:groups、:through =>:group_memberships has_many:friends#ここに来るものは? has_many:アクション終了

上記のコードでは、アクションも追加しました。 システムがサイト上の各ユーザーの行動を追跡したとしましょう。 各アクションが一意であり、すべてのユーザーの友人のために最新のものが最上位にソートされるように、これをどのようにコーディングしますか。

<%@ @ user.friends.actions内のアクション%> <%= action.whatever%> <%end%>

上のコードは有効ではないかもしれません、あなたは私が下に持っているもののような何かをすることができます、しかしそれから行動はソートされないでしょう。

<%in @ user.friends%> <%in friend.actions%> <%= action.whatever%> <%end%> <%end%>

更新

私はここで本当の問題は友達を定義する方法であると思いますか? ユーザーを他のユーザーにリンクする新しいモデルまたは結合テーブルを作成しますか? 理想的には、他のユーザーの共通のグループメンバーシップを通じて友達を定義したいのですが、それを定義する方法がわからないのです。

has_many:friends、:through =>:group_memberships、:source =>:user

しかし、それはうまくいきません。 何かアイデアやベストプラクティスの提案はありますか?

3 Answer


0


私がRailsを使って作業してからしばらく時間が経ちました(Rails 1.xを考えてください)が、私はあなたが以下のようなことをすることができると思います:

Action.find(:all、:conditions => ['user_id in(?)'、@ user.friends.map(

それからあなたの見方では:

<%@ actions.each do | action | %> <%= action.whatever  - %> <%end%>


0


友達を追加するには、has_and_belongs_to_manyまたはhas_many:throughを使用できます。 その方法の例は、 こちらです。 あなたはusersテーブルに自己結合するべきです。

最近のアクションを一覧表示するには、:order ⇒:created_at(または :updated_at). Than you can filter out actions that not belongs to users.

@actions = Action.all(:order =>:created_at).select {| a | a.user.friends.include?(@ user)}

おそらくこれを行うためにSQLクエリを書くこともできます。


0


"user"テーブルを使用してそこから移動する "friend"オブジェクトを作成するか、または友人を部分的なエンティティ(友人名とuser_id参照)として定義し、ユーザーオブジェクトを友人オブジェクトにプルすることができます。

それはあなたがより簡単に "削除された"友人を表現することを可能にするので私はこの最後のモデルがより好きです。 ユーザー名が重複している場合でも、友人名のコピーと、ユーザーがいなくなったかどうかを識別するIDを保持することができます。 「友だち」の概念を「ユーザー」の概念およびセキュリティ上の意味から少し遠ざけます。 私はそれが存在していたユーザーについての柔軟性と "シャドウ"情報を追加するので "name"フィールドを複製することが適切な非正規化を主張します。

私はそれをします、しかし。 それでもやはり最終的にはユーザーテーブルに自己結合する必要がありますが、おそらくそれほど多くはありません。 何かを正規化解除したくない場合は、FriendとUserの両方が情報として参照するPersonオブジェクトを持つことができます。 個人的には、これはいい理論的な構成だと思いますが、コードの大部分に複雑さをもたらすほどの価値はありません(その80%はユーザーについて、20%は友人についての話です)。 私はユーザーが話をするのを簡単にし、友人を少し難しくするでしょう…​ 両方ではありません。 :)

お役に立てれば。 私はこれと精神的にもてあそびました。 :)