Mega-Flaskチュートリアル、パート8：サブスクライバー、連絡先、およびフレンド

これはシリーズの8番目の記事で、Flaskマイクロフレームワークを使用してPython Webアプリケーションを作成した経験を説明しています。



このガイドの目的は、かなり機能的なマイクロブログアプリケーションを開発することです。オリジナリティが完全に欠如しているため、マイクロブログアプリケーションと呼ぶことにしました。

短い繰り返し

私たちの小さなマイクロブログはゆっくりと成長しており、今日は完全なアプリケーションに必要なトピックを取り上げます。



今日は、データベースで少し作業します。 アプリケーションの各ユーザーは、追跡するユーザーを選択できる必要があり、データベースには、誰が誰を追跡しているかに関するデータも保存する必要があります。 すべてのソーシャルアプリケーションには、さまざまなバリエーションのこれらの機能があります。 連絡先、リンク、友達、友達、購読者などと呼ばれる人もいます。 一部のサイトでは、許可ユーザーと無視ユーザーのリストに同様の考え方を使用しています。 それらをサブスクライバーと呼びますが、名前を保持して実装することはありません。

サブスクライバー機能の設計

コードを書き始める前に、この機能から取得したい機能について考えてみましょう。 最も明白なものから始めましょう。 ユーザーが他のユーザーへのサブスクリプションのリストを便利に管理できるようにしたいと考えています。 一方、各ユーザーのサブスクライバーのリストを知りたいです。 また、ユーザーがサブスクライバーを持っているかどうか、または他のユーザーをサブスクライブしているかどうかを確認できるようにしたいと考えています。 ユーザーは、他のユーザーのプロファイルにある「購読」リンクをクリックして、追跡を開始します。 同様に、登録解除リンクをクリックすると、ユーザーの登録が解除されます。 最後の要件は、ユーザーがデータベースから監視対象ユーザーのすべての投稿を要求できることです。



それで、あなたがそれが速くて簡単であると思ったならば、もう一度考えてください！

データベース内の通信

すべてのユーザーのサブスクライバーとサブスクリプションのリストが必要だと言いました。 残念ながら、リレーショナルデータベースは@@ list @@型ではありません。レコードとレコード間のリレーションを持つテーブルだけがあります。 データベースにはすでにユーザーを表すテーブルがありますが、サブスクライバーとサブスクリプションの関係をシミュレートする依存関係を考え出す必要があります。 これは、リレーショナルデータベースの3種類の関係を解析する良い機会です。

1対多

データベースに関する以前の記事で、1対多の関係をすでに見ました。





このような関係で接続されている2つのエンティティは、 users



とposts



です。 ユーザーは多くの投稿を持つことができ、投稿にはユーザーが1人しかいないと言います。 これらの関係は、「多」側に外部キー（FK）を持つデータベースで使用されます。 上記の例では、外部キーはposts



テーブルに追加されたuser_id



フィールドです。 このフィールドは、各投稿をユーザーテーブルの作成者に関する投稿に関連付けます。



user_id



フィールドがこの投稿の著者への直接アクセスを提供することは明らかですが、フィードバックについてはどうですか？ リンクが役立つためには、ユーザーが書いた投稿のリストを取得できなければなりません。 データベースには「user_idがXであるすべてのメッセージを取得する」などのクエリを作成できるインデックスがあるため、 posts



テーブルのuser_id



フィールドで質問に答えることができます。

多対多

多対多の関係はもう少し複雑です。 たとえば、 students



とteachers



が保存されているデータベースを考えてみましょう。 学生は多くの教師を持つことができ、教師は多くの学生を持つことができると言えます。 これは、2つの部分的に重複する1対多の関係に似ています。



このタイプの関係については、データベースにクエリを実行し、学生を教える教師のリストと教師のクラスの学生のリストを取得できる必要があります。 データベースでは想像するのがかなり難しいことがわかります。そのような関係は、既存のテーブルに外部キーを追加してモデル化することはできません。



多対多のリレーションシップを実装するには、ピボットテーブルと呼ばれる補助テーブルを使用する必要があります。 たとえば、ここでは、生徒と教師のデータベースのようになります。







これは複雑に思えるかもしれませんが、ピボットテーブルは、次のような多くの質問に答えることができます。

• 生徒Sは誰から学んでいますか？
• T先生は誰に教えますか？
• 教師Tがいる生徒は何人ですか？
• 生徒Sには何人の教師がいますか？
• 先生Tは生徒Sを教えますか？
• 学生Sは教師クラスTに参加しますか？

一対一

1対1の関係は、1対多の関係の特殊なケースです。 ビューは非常に似ていますが、1対多にならないように、複数のリンクの追加が禁止されています。 このタイプの関係が役立つ場合がありますが、これは他の2つのタイプの場合ほど頻繁には起こりません。2つのテーブルが1対1の関係で接続されている状況では、テーブルを1つに結合することが理にかなっているからです。

サブスクライバー/サブスクリプションの提出

上記の関係から、ユーザーは他の多くのユーザーをフォローでき、ユーザーは多くのサブスクライバーを持つことができるため、多対多のデー​​タモデルが適しているかどうかを簡単に判断できます。 しかし、機能があります。 他のユーザーにサブスクライブしているユーザーを表したいのですが、ユーザーテーブルは1つしかありません。 それでは、多対多の関係で2番目のエンティティとして何を使用すべきでしょうか？



もちろん、リレーションシップの2番目のエンティティは同じユーザーテーブルになります。 エンティティのインスタンスが同じエンティティの他のインスタンスに関連付けられている関係は、自己参照関係と呼ばれ、まさにこれが必要なものです。



これは、多対多の関係の図です。







followers



テーブルはピボットテーブルです。 両方の外部キーは、 user



テーブルを指します。 テーブルを自分自身にリンクしました。 この表の各エントリは、購読しているユーザーと購読しているユーザーとの関係を表します。 生徒と教師の例のように、このような構成により、データベースは必要なサブスクライバーとそのサブスクリプションに関するすべての質問に答えることができます。 とても簡単です。

DBモデル

モデルの変更はそれほど大きくありません。 テーブル@@フォロワー@@（ファイル@@ app / models.py @@）を追加することから始めます。

 followers = db.Table('followers', db.Column('follower_id', db.Integer, db.ForeignKey('user.id')), db.Column('followed_id', db.Integer, db.ForeignKey('user.id')) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、図からのテーブルリンクのライブ変換です。 users



とposts



に対して行ったように、このテーブルをモデルとして宣言しなかったことに注意してください。 これは外部キー以外のデータを持たないヘルパーテーブルであるため、低レベルのフラスコsqlalchemy APIを使用して、モデルを作成せずにテーブルを作成します。



次に、 users



テーブル（ファイルapp/models.py



）で多対多の関係を説明します

 class User(db.Model): id = db.Column(db.Integer, primary_key = True) nickname = db.Column(db.String(64), unique = True) email = db.Column(db.String(120), index = True, unique = True) role = db.Column(db.SmallInteger, default = ROLE_USER) posts = db.relationship('Post', backref = 'author', lazy = 'dynamic') about_me = db.Column(db.String(140)) last_seen = db.Column(db.DateTime) followed = db.relationship('User', secondary = followers, primaryjoin = (followers.c.follower_id == id), secondaryjoin = (followers.c.followed_id == id), backref = db.backref('followers', lazy = 'dynamic'), lazy = 'dynamic')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

関係の構成は重要であり、説明が必要です。 前の記事で行ったように、 db.relationship



関数を使用して、テーブル間の関係を決定します。 User



インスタンスを別のUser



インスタンスに関連付けます。同意するために、関連するユーザーのペアでは、左のユーザーが右のユーザーにサブスクライブされると言います。 関係の説明からわかるように、左側の関係を要求すると、サブスクライバのリストが取得されるため、左側をfollowdと呼びます。 すべてのdb.relationship



引数をdb.relationship



見てみましょう。

• 'User'
  
  
  
  関係のエンティティの右側です（左側は親クラスです）。 自己参照関係を定義する場合、両側で同じクラスを使用します。
• この関係で使用されるピボットテーブルへのsecondary
  
  
  
  ポイント。
• primaryjoin
  
  
  
  は、エンティティの左側とピボットテーブルの間の関係を記述します。 followers
  
  
  
  テーブルはモデルではないため、フィールド名を取得するために少し奇妙な構文が使用されていることに注意してください。
• secondaryjoin
  
  
  
  は、右側とピボットテーブルの関係を表します。
• backref
  
  
  
  は、エンティティの右側でこれらの関係がどのように利用可能になるかを説明します。 特定のユーザーについて、 followed
  
  
  
  クエリは、左側のユーザーに関連付けられている右側のすべてのユーザーを返すと言いました。 バックリンクはfollowers
  
  
  
  と呼ばれ、右側のユーザーに関連付けられている左側のすべてのユーザーを返します。 オプションのlazy
  
  
  
  引数は、このリクエストの実行方法を指定します。 このモードは、明示的に要求されるまで要求を実行しないことを示します。 これはパフォーマンスを改善するのに役立ちます。また、実行前にこのリクエストを受信して​​変更できるためです。 これについては後で詳しく説明します。
• lazy
  
  
  
  パラメーターはbackref
  
  
  
  の同じ名前のパラメーターに少し似ていますが、これはフィードバックではなくリクエストを参照しています。

理解するのが難しい場合、絶望しないでください。 これらのクエリの使用方法を確認すると、すべてが明確になります。 データベースの更新を行ったので、新しい移行を作成できます。

 ./db_migrate.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでデータベースの変更が完了しました。 少し突っ込んだままです。

サブスクライバーの追加と削除

コードの再利用をサポートするために、 User



モデル内にsubscription \ subscribers機能を実装し、ビューに配置しません。 したがって、この関数を現在のアプリケーション（ビューから参照）に使用し、テストで使用できます。 原則として、アプリケーションロジックをビューからモデルに移動する方が常に優れています。これにより、テストが大幅に簡素化されます。 自動モードでテストするのは難しいため、提出物はできるだけシンプルにしておく必要があります。



以下は、 User



モデルのメソッド（ファイルapp/models.py



）として定義されている、サブスクライバーを追加および削除するためのコードです。

 class User(db.Model): #... def follow(self, user): if not self.is_following(user): self.followed.append(user) return self def unfollow(self, user): if self.is_following(user): self.followed.remove(user) return self def is_following(self, user): return self.followed.filter(followers.c.followed_id == user.id).count() > 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くの作業を行うSQL Alchemyのパワーのおかげで、これらの方法は驚くほど簡単です。 要素を追加または削除するだけで、残りはSQLAlchemyが行います。 follow



unfollow



とunfollow



、すべてがうまくいったときにオブジェクトを返し、操作が失敗したときにNoneを返すように定義されています。 オブジェクトが返されたら、データベースに追加してコミットする必要があります。



is_following



メソッドは、1行のコードにもかかわらず、非常に多くのことを行います。 ユーザーの参加を伴うすべてのペア(follower, followed)



を返すリクエストを受け入れ、 (follower, followed)



された列でそれらをフィルタリングします。 変更されたリクエストは、まだ完了していないfilter()



から返されfilter()



。 したがって、このリクエストでcount()



を呼び出すと、このリクエストが実行され、見つかったレコードの数が返されます。 少なくとも1つ取得すれば、接続があることがわかります。 何も得られない場合、接続がないことがわかります。

テスト中

コードのテストを作成しましょう（ tests.py



ファイル）：

 class TestCase(unittest.TestCase): #... def test_follow(self): u1 = User(nickname = 'john', email = 'john@example.com') u2 = User(nickname = 'susan', email = 'susan@example.com') db.session.add(u1) db.session.add(u2) db.session.commit() assert u1.unfollow(u2) == None u = u1.follow(u2) db.session.add(u) db.session.commit() assert u1.follow(u2) == None assert u1.is_following(u2) assert u1.followed.count() == 1 assert u1.followed.first().nickname == 'susan' assert u2.followers.count() == 1 assert u2.followers.first().nickname == 'john' u = u1.unfollow(u2) assert u != None db.session.add(u) db.session.commit() assert u1.is_following(u2) == False assert u1.followed.count() == 0 assert u2.followers.count() == 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストをテストフレームワークに追加した後、次のコマンドでテストスイートを開始できます。

 ./tests.py
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、すべてが機能する場合、すべてのテストに合格します。

データベースクエリ

現在のデータベースモデルは、最初にリストした要件のほとんどをサポートしています。 欠けているのは、実際に実現するのが最も難しいことです。 サイトのメインページには、ログインしているユーザーがフォローしているすべての人が書いたメッセージが表示されるため、これらすべてのメッセージを返すリクエストが必要です。



最も明らかな解決策は、既に作成できる追跡対象のユーザーのリストを提供するクエリです。 次に、これらの各ユーザーに対して、そのメッセージを受信するためにリクエストを実行します。 すべてのメッセージが揃ったら、それらを1つのリストにまとめて、時間順に並べ替えることができます。 それはいいですね？ そうでもない。



このアプローチにはいくつかの問題があります。 ユーザーが1000人を追跡するとどうなりますか？ メッセージを収集するためだけに、データベースに対して1000のクエリを実行する必要があります。 そして今、私たちはメモリ内に何千ものリストを持っています。 メインページにはページ番号が実装されているため、使用可能なすべてのメッセージは表示されませんが、最初の50件と次の50件を表示できるリンクのみが表示されます。日付順にメッセージを表示する場合、どのメッセージが最後の50件であるかを知るには最初にすべてのメッセージを受信して​​ソートしない限り、すべてのユーザー。



これは実際には非常に貧弱な規模のひどい解決策です。 収集とソートのこの方法は何らかの形で機能しますが、十分に効果的ではありません。 これはまさに、リレーショナルデータベースが成功する仕事です。 データベースにはインデックスが含まれており、クエリを実行したりソートしたりするのに、自分でできるよりもはるかに効率的です。



受け取りたいものを表すクエリを作成する必要があり、データベースは必要な情報をより効果的に抽出する方法を見つけ出します。



謎を払拭するために、私たちが必要とすることをするリクエストがあります。 残念ながら、これは別のオーバーロードされた単一行であり、ユーザーモデル（ app.models.py



ファイル）に追加します。

 class User(db.Model): #... def followed_posts(self): return Post.query.join(followers, (followers.c.followed_id == Post.user_id)).filter(followers.c.follower_id == self.id).order_by(Post.timestamp.desc())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この要求を段階的に解読してみましょう。 3つの部分があります：join、filter、order_by。

参加する

結合操作の機能を理解するために、例を見てみましょう。 次の内容のUser



テーブルがあるとします：

ユーザー
id	ニックネーム
1	ジョン
2	スーザン
3	メアリー
4	デビッド

例を複雑にしないために、テーブルの他のフィールドは表示されません。



ピボットテーブルで、ユーザー「john」は「susan」と「david」にサブスクライブされ、ユーザー「susan」は「mary」にサブスクライブされ、「mary」は「david」にサブスクライブされていると仮定します。 ピボットテーブルは次のようになります。

フォロワー
follower_id	followed_id
1	2
1	4
2	3
3	4

結論として、 Post



テーブルには各ユーザーからの1つの投稿が含まれています。

投稿
id	テキスト	user_id
1	スーザンからの投稿	2
2	メアリーからの投稿	3
3	デビッドからの投稿	4
4	ジョンからの投稿	1

ここでは、例を複雑にしないために、いくつかのフィールドも削除されています。



以下は、結合が他の部分から分離されたリクエストの一部です。

 Post.query.join(followers, (followers.c.followed_id == Post.user_id))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

join



操作は、 Post



テーブルで呼び出されます。 2つの引数があります。最初の引数は別のテーブル、この場合はfollowers



です。 2番目の引数は、テーブルを結合するフィールドを示します。 join



操作は、指定された条件に従って、 Post



およびfollowers



データがマージされた一時テーブルを作成します。



この例では、 followers



テーブルのuser_id



フィールドをuser_id



テーブルのuser_id



フィールドと一致させuser_id



。



このマージを実行するには、 Post



テーブル（結合の左部分）から各レコードを取得し、条件に一致するfollowers



テーブル（結合の右部分）のレコードからフィールドをアタッチします。 レコードが条件を満たさない場合、テーブルに分類されません。



この一時テーブルの例で結合を実行した結果：

投稿			フォロワー
id	テキスト	user_id	follower_id	followed_id
1	スーザンからの投稿	2	1	2
2	メアリーからの投稿	3	2	3
3	デビッドからの投稿	4	1	4
3	デビッドからの投稿	4	3	4

subscribersテーブルにfollowed_id = 1が存在するエントリがないため、user_id = 1のメッセージがどのように参加から削除されたかに注目してください。 また、サブスクライバーテーブルにはfollowed_id = 4のオカレンスが2つあるため、user_id = 4のメッセージが2回表示されることに注意してください。

フィルター

参加操作は、サブスクライバーが誰であるかを指定せずに、誰かがフォローしているユーザーからのメッセージのリストを提供しました。 特定の1人のユーザーによって追跡されるメッセージのみが含まれるこのリストのサブセットに関心があります。 したがって、このテーブルをサブスクライバーでフィルター処理します。 フィルター要求の部分は次のとおりです。

 filter(followers.c.follower_id == self.id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストはターゲットユーザーのコンテキストで実行されるため、このコンテキストのUserクラスのself.idメソッドは、対象のユーザーのIDを返します。 このフィルターを使用して、ユーザーがサブスクライバーとしてリストされているjoinを使用して作成されたテーブルのレコードのみを残したいことをデータベースに伝えます。 例を続けると、id = 1のユーザーをリクエストすると、別の一時テーブルに移動します。

投稿			フォロワー
id	テキスト	user_id	follower_id	followed_id
1	スーザンからの投稿	2	1	2
3	デビッドからの投稿	4	1	4

そして、これらはまさに私たちが必要とする投稿です！



クエリはPostクラスで実行されたため、どのモデルにも関係しない一時テーブルになったとしても、結果はこの一時テーブルに含まれ、結合操作によって追加の列が追加されることはありません。

仕分け

プロセスの最後のステップは、基準に従って結果をソートすることです。 リクエストの一部は次のようになります。

 order_by(Post.timestamp.desc())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、結果は降順でtimestamp



でソートされるべきであるため、最後の投稿が最初になります。



リクエストを改善するための詳細は1つだけです。 ユーザーが購読している投稿を読むとき、フィードに自分の投稿を表示したい場合があります。クエリ結果に含めると便利です。



これを行う簡単な方法があり、変更は必要ありません！ 各ユーザーが自分のサブスクライバーとしてデータベースに追加されていることを確認するだけで、この小さな問題はもう気にしません。 クエリに関する長い議論を締めくくるために、クエリの単体テスト（tests.pyファイル）を作成しましょう。

 #... from datetime import datetime, timedelta from app.models import User, Post #... class TestCase(unittest.TestCase): #... def test_follow_posts(self): # make four users u1 = User(nickname = 'john', email = 'john@example.com') u2 = User(nickname = 'susan', email = 'susan@example.com') u3 = User(nickname = 'mary', email = 'mary@example.com') u4 = User(nickname = 'david', email = 'david@example.com') db.session.add(u1) db.session.add(u2) db.session.add(u3) db.session.add(u4) # make four posts utcnow = datetime.utcnow() p1 = Post(body = "post from john", author = u1, timestamp = utcnow + timedelta(seconds = 1)) p2 = Post(body = "post from susan", author = u2, timestamp = utcnow + timedelta(seconds = 2)) p3 = Post(body = "post from mary", author = u3, timestamp = utcnow + timedelta(seconds = 3)) p4 = Post(body = "post from david", author = u4, timestamp = utcnow + timedelta(seconds = 4)) db.session.add(p1) db.session.add(p2) db.session.add(p3) db.session.add(p4) db.session.commit() # setup the followers u1.follow(u1) # john follows himself u1.follow(u2) # john follows susan u1.follow(u4) # john follows david u2.follow(u2) # susan follows herself u2.follow(u3) # susan follows mary u3.follow(u3) # mary follows herself u3.follow(u4) # mary follows david u4.follow(u4) # david follows himself db.session.add(u1) db.session.add(u2) db.session.add(u3) db.session.add(u4) db.session.commit() # check the followed posts of each user f1 = u1.followed_posts().all() f2 = u2.followed_posts().all() f3 = u3.followed_posts().all() f4 = u4.followed_posts().all() assert len(f1) == 3 assert len(f2) == 2 assert len(f3) == 2 assert len(f4) == 1 assert f1 == [p4, p2, p1] assert f2 == [p3, p2] assert f3 == [p4, p3] assert f4 == [p4]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストには多くのプリセットコードがありますが、テストコード自体は非常に短いものです。 最初に、各ユーザーに返される追跡された投稿の数が予想と等しいことを確認します。 次に、各ユーザーに対して、正しい投稿が返され、正しい順序で到着したことを確認します（タイムスタンプが常に同じ順序を保証するメッセージを挿入したことに注意してください）。



followed_post（）メソッドの使用に注意してください。 このメソッドは、結果ではなくクエリオブジェクトを返します。 遅延=「動的」は、DB関係でも機能します。



結果の代わりにオブジェクトを返すことは常に良い考えです。なぜなら、呼び出し元に実行前にクエリを補足する機会を与えるからです。



クエリを実行するには、クエリオブジェクトにいくつかのメソッドがあります。 count（）がクエリを実行し、結果の数を返し、データ自体を破棄することがわかりました。 また、first（）を使用して、リストの最初の結果を返し、残りを破棄しました。 テストでは、all（）メソッドを使用して、すべての結果を含む配列を取得しました。

可能な改善

必要なすべてのサブスクリプション機能を実装しましたが、デザインを改善してより柔軟にするための方法がいくつかあります。 私たちが嫌いなソーシャルネットワークはすべて、こうしたユーザーの接続方法をサポートしていますが、情報を管理するためのオプションは他にもあります。 たとえば、サブスクライバーをブロックする方法はありません。これは、ユーザーを選択するだけでなく、ブロックしたユーザーの投稿を除外する必要があるため、リクエストに別の複雑さを追加することです。これを実装する方法は？



簡単な方法は、誰かをブロックしている人を記録するための多対多の関係を持つ別の自己参照テーブルと、追跡された投稿を返すクエリの別の結合+フィルタです。ソーシャルネットワークのもう1つの一般的な機能は、サブスクライバーをリストにグループ化する機能です。これにより、後で各グループと情報を共有できます。また、追加の接続が必要になり、クエリが複雑になります。



マイクロブログにはこれらの機能はありませんが、それが十分な関心を引き起こす場合は、このトピックに関する記事を書いていただければ幸いです。コメントで教えてください！

物事を整理する

今日は非常に進歩しています。しかし、データベースとクエリの設定に関する問題は解決しましたが、アプリケーションに新しい機能を含めることはしませんでした。幸いなことに、これには問題はありません。必要に応じて、プレゼンテーションモデルとテンプレートを修正して、ユーザーモデルの新しいメソッドを呼び出すだけです。やってみましょう。



私たちは自分自身を加入者にします。

フィードで自分の投稿を見ることができるように、自分自身に登録しているすべてのユーザーをマークすることにしました。



OpenIDのafter_loginハンドラー（ファイル 'app / views.py'）の最初のアカウント設定がユーザーに割り当てられた時点でこれを行います。

 @oid.after_login def after_login(resp): if resp.email is None or resp.email == "": flash('Invalid login. Please try again.') return redirect(url_for('login')) user = User.query.filter_by(email = resp.email).first() if user is None: nickname = resp.nickname if nickname is None or nickname == "": nickname = resp.email.split('@')[0] nickname = User.make_unique_nickname(nickname) user = User(nickname = nickname, email = resp.email, role = ROLE_USER) db.session.add(user) db.session.commit() # make the user follow him/herself db.session.add(user.follow(user)) db.session.commit() remember_me = False if 'remember_me' in session: remember_me = session['remember_me'] session.pop('remember_me', None) login_user(user, remember = remember_me) return redirect(request.args.get('next') or url_for('index'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リンクの購読と購読解除

次に、サブスクリプションおよびサブスクリプション解除プレゼンテーション機能（app / views.pyファイル）を定義します。

 @app.route('/follow/<nickname>') @login_required def follow(nickname): user = User.query.filter_by(nickname = nickname).first() if user == None: flash('User ' + nickname + ' not found.') return redirect(url_for('index')) if user == g.user: flash('You can\'t follow yourself!') return redirect(url_for('user', nickname = nickname)) u = g.user.follow(user) if u is None: flash('Cannot follow ' + nickname + '.') return redirect(url_for('user', nickname = nickname)) db.session.add(u) db.session.commit() flash('You are now following ' + nickname + '!') return redirect(url_for('user', nickname = nickname)) @app.route('/unfollow/<nickname>') @login_required def unfollow(nickname): user = User.query.filter_by(nickname = nickname).first() if user == None: flash('User ' + nickname + ' not found.') return redirect(url_for('index')) if user == g.user: flash('You can\'t unfollow yourself!') return redirect(url_for('user', nickname = nickname)) u = g.user.unfollow(user) if u is None: flash('Cannot unfollow ' + nickname + '.') return redirect(url_for('user', nickname = nickname)) db.session.add(u) db.session.commit() flash('You have stopped following ' + nickname + '.') return redirect(url_for('user', nickname = nickname))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは理解できるはずですが、エラーを防ぎ、問題がまだ発生したときにユーザーにメッセージを提供しようとするチェックに注意を払う価値があります。これでプレゼンテーション機能ができたので、それらを接続できます。サブスクライブまたはサブスクライブ解除へのリンクは、各ユーザーのプロファイルページで利用できます（ファイルアプリ/テンプレート/ user.html）：

 <!-- extend base layout --> {% extends "base.html" %} {% block content %} <table> <tr valign="top"> <td><img src=""></td> <td> <h1>User: {{user.nickname}}</h1> {% if user.about_me %}<p>{{user.about_me}}</p>{% endif %} {% if user.last_seen %}<p><i>Last seen on: {{user.last_seen}}</i></p>{% endif %} <p>{{user.followers.count()}} followers | {% if user.id == g.user.id %} <a href="{{url_for('edit')}}">Edit your profile</a> {% elif not g.user.is_following(user) %} <a href="{{url_for('follow', nickname = user.nickname)}}">Follow</a> {% else %} <a href="{{url_for('unfollow', nickname = user.nickname)}}">Unfollow</a> {% endif %} </p> </td> </tr> </table> <hr> {% for post in posts %} {% include 'post.html' %} {% endfor %} {% endblock %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「編集」リンクがあった行には、ユーザーが持っているサブスクライバーの数と、次の3つのリンクのいずれかが表示されます。

• プロファイルがログインしているユーザーに属している場合、「編集」ボタンが表示されます
• それ以外の場合、ユーザー「サブスクライブ」にサブスクライブしていない場合
• それ以外の場合は購読解除リンク

これで、アプリケーションを起動し、さまざまなOpenIDアカウントからログインして複数のユーザーを作成し、新しい機能を試すことができます。



残っているのは、追跡されたユーザーの投稿をメインページに表示することだけですが、パズルの重要な部分はまだないので、次の章まで待つ必要があります。

最後の言葉

今日、アプリケーションの大部分を実装しました。

データベース接続とクエリのトピックは非常に複雑なので、質問がある場合は、以下のコメントで質問を送信できます。

次の記事では、ページ番号付けの素晴らしい世界を見て、最終的にデータベースから投稿を受け取ります。



：私たちのマイクロブログの更新ソースへのリンクの下の怠惰kopipaster用



のダウンロードmicroblog-0.8.zip。



いつものように、アーカイブにはフラスコデータベースや仮想環境は含まれていません。以前の記事では、それらの展開方法について説明しました。



チュートリアルを読んでくれてありがとう。またね！

ミゲル