OpenPNE 3

当チケットに対する修正は #3646 の Pull Request 内に含めました。
https://redmine.openpne.jp/issues/3646#note-5

#3646 でのページングの実装に追加で必要となるフィールドを仕様に追記しました。

気になった点について書いておきます。

• fetch メソッドの実行は opCursorPager にとって必須な作業になるとおもいますが、現状の opCursorPager では外からクエリ操作ができるようになっているわけでもないので、 初期化用のメソッド（コンストラクタ内で余りやるべきではなさそうなので、initとかinitializeとかいう名前のメソッドなど）を作ってその中で fetch したほうがよいかとおもいました。アクション側に fetch を実行させる理由はあまり無いように思われます（fetch メソッドが since_id や max_id などの引数をとれるようなら、話は違いますが）。
• もしくは、アクション側から opCursorPager の持っているクエリも操作できるようにしていれば、fetch をアクション側に実行させる理由はあるかとおもいます。
  

  $pager = new opCursorPager($q);
  $pager->baseQuery->addWhere('member_id = ?', $memberId);
  $pager->fetch();
  

  
  のような例であれば(現状では baseQuery が protected なので上記の例は実行できませんが)、fetch が外部から実行されるべき理由があるとおもいます（もっとも、こちらの例はもともと opCursorPager のインスタンスを生成する前にクエリ操作できるのだし、基本的にはそうすべきだとおもうので、あまり良くない例だとおもいます）
• opJsonApiActions に addSearchCondition というメソッドを追加していますが、コントローラーのなかにこのメソッドがいる理由がないとおもいます。opJsonApiActions::addSearchCondition は内容的に見るなら、opCursorPager のなかで吸収すべきだとおもいます。
  

      $pager = new opCursorPager($query);
      self::addSearchCondition($pager, $request);
      $pager->fetch();
  

  
  opCursorPager のインスタンスを生成してから fetch を実行する間に opJsonApiActions::addSearchCondition の処理があり、そのなかでページャーオブジェクトが操作されている、という処理の流れには違和感があります。

とりあえず差し戻しにしておきます。

対象バージョン変更のため、修正内容の確認を行います。