論理削除？

Seasar S2DAO

今日は、1:Nマッピング以外の機能について言及してみます。


makotanの日記から引用。

public String DELETEFLAG = "deleteflag,0,1";

っていうアノテーションがあったとき、削除時の処理がupdateでdeleteflagに1をセットするに勝手に変化する

もちろんcreateの所では勝手に0を入れようとする。

public String DELETEFLAG = "deletedate,null,current_timestamp";

応用記述方法としてこんなのもあり

ついでに

public String getHoge_NOTDELETE = "";

っていうアノテーションがあったとき、削除フラグが0のものだけ検索する

これは、機能として相当幾つもあるような気がします。
以下にちょっと挙げてみました。
他にもあるような気がします、でも文章にならないのでとりあえず…。

  1. アノテーションによって、DAOの引数を(自由に)変更する
  2. アノテーションによって、SQL文の選択ロジックに影響を与える
  3. アノテーションによって、SQLに条件を追加する。

１番目の機能は、少し怖いな…と思いつつ、少し違いますが、実はもっと派手な機能の実装経験があります。
特定のinterfaceを実装する引数に、ある程度固定的な値を設定するAspectです。
更新日付や、更新者IDといった余り業務とは関係無いもののセキュリティ確保や、
障害時の運用の為にどうしても必要なカラムに値を設定するのに使っています。
S2DaoInterceptorを継承して作成してしまいました…。
今となっては、S2DAO自体に手を入れられるので、もう少しスッキリした実現方法があると考えています。


２番目の機能は、現状DaoMetaDataImpl辺りが持っている機能を拡充するイメージになるかなぁ…と思います。
正直、DaoMetaDataImplは細切れにして.diconファイルで、処理内容を出来うる限り構成しなおせるようにしてしまった方が良いのでは？…と思う事もあります。
特に、SqlCommandの実装クラスを選択したり、SQLを設定したりしている部分。
もう1つは、ResultSetHandlerの選択処理部分。


と、思ったらDaoMetaDataFactoryと言う形で既に、
DaoMetaDataの実装を切り替えられるようになっていますね…。流石…。
少し前から気になっていたFactoryのキャッシュを格納する変数がstaticで無くなっています。
lockアルゴリズムも微妙に変わっています。
何か心変わりがあったんでしょうか…少し気になります。


３番目の機能は、既にQUERYアノテーションで実現されているので、現状のままで良いかな…と思います。