[Overview]
論理削除に関しては、既存の構造を使ったサポートを提供する。
そのやり方と同時に論理削除のDB設計について色々書いておく。
(DBFlute自体の修正は特になし)

　o 「現状の考え方」と「あえてやるならこうする」を両方説明する。
　o 論理削除フラグの設計について色々なやり方があることを示す。

[Reference]
http://www.infoq.com/jp/news/2009/09/Do-Not-Delete-Data
※個人的に非常に近い考え方の記事

[Contents]
<< 現状 >>
論理削除に関して特に何も支援はしていない。

更新時の自動化は共通カラムの自動設定で可能であり実利用されている。
なので更新時の話は特に問題領域ではない。

検索時の自動化は特に支援はない。
その理由は：
「業務によって論理削除の仕様がマチマチで統一化できない」

その内訳は：
　o 結合先テーブルの論理削除フラグ条件を付与するかどうか
　o 結合先テーブルの論理削除フラグ条件に対して依存(Where句)か非依存(On句)か
　o 論理削除済みのデータを検索するかどうか

現状は検索時は明示的に論理削除の条件を入れる方が良いと考えている。
CBは書いてあることが素直に条件になることを重視するため
中途半端な状態での暗黙の検索条件は絶対に不可。
(本当に統一的で安全な仕様とやり方がある場合じゃないとサポートしない)

<< 検討 >>
基本的に問題領域は検索時の条件の自動付与だけである。
DBFluteが提案する良いと思われる論理削除の仕様に特化した
サポートをするのはどうであろうか？

　o 業務的に必要なところにだけ論理削除フラグを付与(一律全テーブル付与はしない)
　o 論理削除フラグを正常状態に戻すような業務はしない(非表示フラグの役割を持たせない)
　o 結合先テーブルの論理削除フラグを付与するしないがリレーション毎に明確である

ExConditionQueryのコンストラクタにて自動で設定するやり方を提供する。
(機能追加というわけではなくドキュメント等でやり方のみを提供)

ExConditionQueryにてアプリケーション特有の仕様をベタに実装する。
引数の「ReferrerのCQ」を見ればリレーションが特定できるので、
結合時の結合先テーブルの論理削除フラグを付与するかどうかの条件も
実装することが可能。ベタな感じなのでディベロッパーにとっても
わかりやすく制御しやすい。Where句で論理削除フラグが真っ先に
来るのがやだかもだけど、明確な機能を実現したとしてもそれは
逃れられないかもしれない。

/**
 * Constructor.
 * @param referrerQuery The instance of referrer query. (Nullable: If null, this is base query)
 * @param sqlClause The instance of SQL clause. (NotNull)
 * @param aliasName The alias name for this query. (NotNull)
 * @param nestLevel The nest level of this query. (If zero, this is base query)
 */
public MemberCQ(ConditionQuery referrerQuery, SqlClause sqlClause, String aliasName, int nestLevel) {
    super(childQuery, sqlClause, aliasName, nestLevel);

    if (referrerQuery == null) {
        // 基点テーブルの場合
        setDeleteFlg_Equal_False();
    } else if (referrerQuery instanceof MemberWithdrawalCQ) {
        // 会員退会情報からの結合の場合
        //   →依存ありで論理削除フラグを見る
        setDeleteFlg_Equal_False();
    } else if (referrerQuery instanceof MemberLoginCQ) {
        // 会員退会情報からの結合の場合
        //   →依存なしで論理削除フラグを見る
        on().setDeleteFlg_Equal_False();
    } else if (referrerQuery instanceof PurchaseCQ) {
        // 購入からの結合の場合
        //   →論理削除フラグは見ない
    }
}

万が一、論理削除されたデータを検索したい場合は、
アプリ側で同じカラムに対して別の値で条件を付与すれば上書きになる。
論理削除されたものされてないもの両方とも検索したい場合は、
Unionを利用することで可能。多少面倒な面はあるが、論理削除フラグの
条件を一律付与したいくらいの状況であれば、あまり問題はないかと。