makotan _at_ gmail dot com

マスメンを拡張する

buri

4時間半の生放送見てて気が向いた
マスメンって大抵はシンプルすぎるくらいシンプルなんだけど、たまにめんどくさくなったりする・・・

登録する前に予約登録を作って有効日時になったら有効にして欲しい

まぁ良くある話の様な気はする
つーことで
まず、基本的な画面遷移等々

  1. 検索
  2. 検索結果
  3. 新規追加
  4. 変更
  5. 削除

今回の重要な違いは検索結果に予約と登録済みが表示できることかな〜
じゃあ中核の処理は？って書こうと思ったけどあんまり変わらない気がしたので省略してSQLへ・・・


普通に作った場合の登録済みの検索SQL（論理削除してる場合）はこんな感じ

select * from hoge where deleteFlg = false and reserveLimit <= current_timestamp

じゃあぶりを使った場合の登録済みの検索SQLはこんな感じ・・・=をinに変更してる（実はこれが重要なポイント）

select hoge.* from hoge,buriPathData
where hoge.id = buriPathData.pkeyNum and buriPathData.pathName in ( 'pkg.hoge.登録済み' )


普通に作った場合の予約中の検索SQL（論理削除してる場合）はこんな感じ

select * from hoge where deleteFlg = false and reserveLimit > current_timestamp

じゃあぶりを使った場合の予約中の検索SQLはこんな感じ・・・

select hoge.* from hoge,buriPathData
where hoge.id = buriPathData.pkeyNum and buriPathData.pathName in ( 'pkg.hoge.予約中' )


普通に作った場合の予約中＆登録済みの検索SQL（論理削除してる場合）はこんな感じ

select * from hoge where deleteFlg = false

じゃあぶりを使った場合の予約中＆登録済みの検索SQLはこんな感じ・・・

select hoge.* from hoge,buriPathData
where hoge.id = buriPathData.pkeyNum and buriPathData.pathName in ( 'pkg.hoge.予約中','pkg.hoge.登録済み')


普通に作ると検索条件を色々変える必要があるのに、ぶりだとinに渡すListの内容を制御すればどんな状態のデータでもとってこれるって言うのがかなり重要なポイント
たとえばチェックボックスに状態の文字列（BuriPathって呼んでるもの）を設定してやればそれで検索が出来たり・・・なんて事が可能になる。
ついでに、大小比較でどっちがどっちだっけ〜っていう初心者っぽい悩みもしなくて良い＜個人的に重要（ｗ
もっと拡張すると更に差が開くけどもういいかなぁ〜って気はする