この状況を設計する正しい方法がわからない場合は、フィードバックをお寄せください。
ストーリーとユーザーの2つのモデルがあり、3番目のモデルであるタグに関連付けたいと考えています(つまり、ユーザーとストーリーにタグを付けることができます)。
もともと私は標準の外部キーとm2mの関係を使用してこれを書きました:
class Story(models.Model):
tags = models.ManyToManyField(Place, through='StoryTagLink')
class Tag(models.Model):
name = models.CharField(max_length=255, unique=True, db_index=True)
staff_created = models.BooleanField(default=False)
created_by = models.ForeignKey(User)
create_date = models.DateTimeField(auto_now=True, auto_now_add=True, editable=False)
class StoryTagLink(models.Model):
story = models.ForeignKey(Story, db_index=True)
tag = models.ForeignKey(Tag, db_index=True)
これにより、私は次のようなことを簡単に行うことができました。
tags = story.tags.all()
また
{% if story.tags.count %}
タグの処理に関するコードは十分に複雑になったため、Generic Relationsを使用する方がよいと判断したため、同じコードを2回記述しません。1回はStory-Tag処理用、もう1回はUser-Tag処理用です。(私は文字通り同じコードを2回入力し始め、ユーザーのストーリーを検索して置き換えました。そして、自分のソリューションを一緒にハックしようとするよりも、汎用関係を使用する方が良いと考えました。)とにかく、今は次のようになっています。
class Story(models.Model):
tags = generic.GenericRelation(TagLink)
class Tag(models.Model):
(same as before)
class TagLink(models.Model):
tag = models.ForeignKey(Tag, db_index=True) # <========== was this right???
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey('content_type',
'object_id')
複数のオブジェクトが同じタグを取得でき、それぞれに独自の一意のIDとメタデータが必要なため、サイトタグの公式リストを保持するために、モデルのtag
フィールドをTagLink
元のモデルのFKにしました。Tag
厄介な副作用は、story.tags.all()を実行すると、以前のようにs自体<TagLink: TagLink object>
ではなくsのリストが表示されることです。Tag
より良い解決策を研究しようとすると、私のような他のほとんどの例が、私の同等のTag
とTagLink
テーブルを混同しているように見えることに気付きます。これは私の場合は実行可能な解決策のようには思えませんが、非常に多くの例がそれを当然のことと考えているので、ここで何かが欠けているのか、それとも私の場合が他の場合と本当に異なるのか疑問に思います。
それで:
- 私の場合、TagテーブルとTagLinkテーブルを処理する正しい方法は何ですか?それらを別々に保つのは正しいですか?
- もしそうなら、私のビューとテンプレート内のオブジェクトのすべてのタグを取得するためのクエリを構築するためのより良い方法はありますか?
- Generic Relationsを使用する唯一の理由がDRYであり(タグのすべてのユーザーとストーリーを一覧表示するケースはありません。どちらか一方を一覧表示します)、取得するオブジェクトは2種類しかないことを考えるとタグ付きの場合、Generic Relationsを回避し、ifステートメントを使用して同じ関数呼び出し内の両方の種類のオブジェクトのフォームを作成および保存するソリューションを一緒にハッキングする方がよいでしょうか?通常のFKよりも柔軟性の低い汎用FKがどれほど少ないかを考えると(たとえば、管理者のやり直しについてはまだ言及していません)、この道を進んだことを後悔し始めています...
御時間ありがとうございます!!!