[Seasar-user:18312] Re: 【DBFlute】Bhv共通処理

2009年 8月 18日 (火) 15:14:17 JST

お世話になっております。
hatti です。

> なるほど、論理削除されていれば再度業務キーが利用可能というケースでしたか。
> 失礼しました。
> ※ただ、そのパターンでも私でしたら制約はつけないかな・・
いえいえ、私の説明不足でした。
制約をつけるか消すかについてはどちらがよいか、アプリ作成しながら考えたいと思います。
現在仕事のプロジェクトでこのようにしていたので真似てみました。
参考にさせていただきます。

> 会員の例でしたら、有効会員テーブルと、会員マスタみたいなのを設けて、
> 業務的One-To-Oneで結び、常に有効な会員が取れるようにするという手もあるかとは思いますが、
> 全てのテーブルとなると厳しいですね。（テーブル二つ用意しないで自分への参照でもいけるかもしれませんが）
> http://d.hatena.ne.jp/jflute/20081201/1228126523
なるほど
しかしやはり全テーブルでは厳しそうですね、、、

> ExBhvに関しては
> [プロジェクトルート]\mydbflute\dbflute-[version]\templates\om\java\bsbhv\BaseBhv.vm
ありがとうございます。先ほど確認してみました。
BaseBhv の extends org.seasar.dbflute.bhv.${myExtendClassName} を修正して、
extends CommonBhv<${myExtendedObjectClassName}> みたいにしてみようかと思いました。
(CommonBhv は自動生成で、再生成時に上書きされないよう。)
また家でじっくり考えます。

> 極端な話、CBのConditionQueryを初期化するところで、常に削除フラグを条件に入れてしまう
> という手もあるかもしれませんね。
なるほど、こういう手もあるのですね。
vm のほうが安全に触れそうなので、 vm でやってみようと今のところ考えています。

他にもご意見あればお待ちしております。
私も自分なりに良い方法を考えてみます。
(今のところは vm ファイルの修正ですかね)

以上、よろしくお願いいたします。

2009/08/18 14:54 に mokkouyou<[E-MAIL ADDRESS DELETED]> さんは書きました:
> mokkouyouです。
>
> なるほど、論理削除されていれば再度業務キーが利用可能というケースでしたか。
> 失礼しました。
> ※ただ、そのパターンでも私でしたら制約はつけないかな・・
>
> それはそうと、
> 会員の例でしたら、有効会員テーブルと、会員マスタみたいなのを設けて、
> 業務的One-To-Oneで結び、常に有効な会員が取れるようにするという手もあるかとは思いますが、
> 全てのテーブルとなると厳しいですね。（テーブル二つ用意しないで自分への参照でもいけるかもしれませんが）
> http://d.hatena.ne.jp/jflute/20081201/1228126523
>
>
> 全体的にとなると、やはりテンプレートのカスタマイズでしょうか？
> vmにつきましてはVelocityの知識が必要です。
> 1ユーザの私としてはこの拡張性が好きですが、
> 一気に自己責任になる部分ですので、あまりお勧めするわけではありません。
> （そもそも自己責任なんでしょうけど）
>
> ExBhvに関しては
> [プロジェクトルート]\mydbflute\dbflute-[version]\templates\om\java\bsbhv\BaseBhv.vm
>
> 辺りを見てください。
>
>
> 極端な話、CBのConditionQueryを初期化するところで、常に削除フラグを条件に入れてしまう
> という手もあるかもしれませんね。
>
> 結合(setUp)などを考えるとよく内部を調査しないといけませんが。
> それこそ、業務的One-To-Oneと整合性が取れるかも不明。
> ※そしてそのことを忘れるといざ削除済をほしい場合など、後々大騒ぎをすることになるかもしれませんね。（＾＾；
>
> 2009/08/18 14:12 HATTI <[E-MAIL ADDRESS DELETED]>:
>>
>> お世話になっております。
>> hatti です。
>>
>> mokkouyou さんのご回答へ返信いたします。
>> ご回答ありがとうございます。
>>
>> >> 論理削除済みのレコードは対象としない（質問にもありますよね）とすれば、
>> >> 論理削除済みのレコードが再度削除されることが無いのではないでしょうか？
>> おっしゃるとおり、論理削除済のレコードをアプリから再度検索、削除されないように考えています。
>> そのため、自動生成された検索/更新などのメソッドの WHERE 句に「削除番号=0」を付加させたいと考えています。
>>
>> >> 論理削除=新規インサートということでしょうか？？
>> 論理削除は UPDATE 処理です。
>> 対象テーブルの論理削除番号カラムにシーケンスによる採番を行います。
>>
>> >> 更新ならともかく削除にバージョニングして履歴管理では
>> >> そもそも、何度か削除されるという前提になっているような・・・
>> バージョン管理は、別途バージョン番号カラムを用意してそちらで行います。
>> 楽観排他もこちらのカラムで行います。
>>
>> >> それは別として、以下のスマートな解決方法があればいいですが、
>> >> 無いようであれば、（本当に全てのテーブルで共通なのであれば）
>> >> テンプレートとなる、vmファイルに手を入れるというのもありかと思います。
>> なるほど、vmファイルというものがあるのですね。
>> また確認させていただきます。
>>
>> 以上、よろしくお願いいたします。
>>
>> 2009/08/18 12:49 に HATTI<[E-MAIL ADDRESS DELETED]> さんは書きました:
>> > hatti です。
>> >
>> > 質問がわかりづらく申し訳ございません。
>> > 例えば会員マスタ(ユーザID, ログインID, パスワード, 論理削除番号) のテーブルがあるとします。
>> >
>> > ユーザID(連番PK) / ログインID / パスワード / 論理削除番号
>> > ----------------------------------------------------------------------
>> > 1 / id1 / aaa / 0
>> > 2 / id2 / bbb / 1
>> > 3 / id2 / ccc / 0
>> >
>> > PK のユーザIDには当然自動でインデックスが作られるのでいいのですが、
>> > 業務キーとなる、ログインIDも一意としたいためログインIDにも一意制約をかけようとしています。
>> > しかし、論理削除のため、論理削除番号もユニークインデックスに含めないと、
>> > テストデータ1, 2 のように、同一のログインIDが登録できません。
>> >
>> > そして、論理削除を表すものが論理削除フラグだった場合、
>> > さらに id2 のユーザを論理削除した場合に、
>> >
>> > 2 / id2 / bbb / 1
>> > 3 / id2 / ccc / 1
>> >
>> > となってしまい、ユニークでなくなってしまいます。
>> > そこでフラグでなく、削除番号とし、
>> >
>> > 2 / id2 / bbb / 1
>> > 3 / id2 / ccc / 2
>> >
>> > となるようにしようとしています。
>> >
>> > まだ説明不足な点があればご指摘ください。
>> >
>> > 以上、よろしくお願いいたします。
>> >
>> > 2009/08/18 12:30 に mokkouyou<[E-MAIL ADDRESS DELETED]> さんは書きました:
>> >> mokkouyouです。
>> >>
>> >> 論理削除がかち合う意味が若干わかりませんのでなんとも・・・ですが、
>> >>
>> >> 論理削除済みのレコードは対象としない（質問にもありますよね）とすれば、
>> >> 論理削除済みのレコードが再度削除されることが無いのではないでしょうか？
>> >>
>> >> 同時性の問題であれば、楽観でも悲観でもいいのでロックすればいいだけのような。
>> >>
>> >>
>> >> とここまで書いて気づきましたが、
>> >> ユニークインデックスとありますので、
>> >> 論理削除=新規インサートということでしょうか？？
>> >>
>> >> 更新ならともかく削除にバージョニングして履歴管理では
>> >> そもそも、何度か削除されるという前提になっているような・・・
>> >>
>> >> というのが4.に対する「私なら」の回答でしょうか
>> >>
>> >>
>> >> それは別として、以下のスマートな解決方法があればいいですが、
>> >> 無いようであれば、（本当に全てのテーブルで共通なのであれば）
>> >> テンプレートとなる、vmファイルに手を入れるというのもありかと思います。
>> >>
>> >> 以上宜しくお願いいたします。
>> >>
>> >> 2009/08/18 12:09 HATTI <[E-MAIL ADDRESS DELETED]>:
>> >>>
>> >>> お世話になっております。
>> >>> hatti と申します。
>> >>>
>> >>> DBFlute9.5.3 / OracleXE(10g) を使用しております。
>> >>> 特に急ぎの質問ではないため、時間のあるときに回答いただけるとありがたいです。
>> >>>
>> >>> 現在 DBFlute の学習として、サンプルアプリを作成しています。
>> >>> サンプルではテーブルのレコードを物理削除せずに、論理削除で削除しようと考えております。
>> >>>
>> >>> 全テーブルに論理削除番号(フラグではなく連番 ※1以上は削除済)をサフィックスカラムとして持たせました。
>> >>> フラグではなく、連番なのは業務キーと削除Noを合わせてユニークインデックスを張りたいためです。
>> >>> (フラグだと 0/1 のみなので、同一の業務キーレコードが2回削除されるとかち合うため。)
>> >>>
>> >>> そこで、4点ほど質問させていただきたいことがあります。
>> >>>
>> >>> 1．論理削除番号を常に検索条件に付加
>> >>> 自動生成されるメソッド(selectByPK など)は、純粋に PK のみで検索されるため、
>> >>> 論理削除されているものも取れてしまうと思いますが、
>> >>> これら自動生成されるメソッドに対して、論理削除番号を常に条件に付加させることはできないでしょうか。
>> >>>
>> >>> 2． 1．が無理な場合、全 Bhv に共通な自作メソッドを持たせたい
>> >>> 自動生成が無理ならば、自分で作成するしかないです。
>> >>> その場合、全 ExBhv に findAll などを持たせるのはテーブル数が多いと困難です。
>> >>>
>> >>> そこで、全 ExBhv に共通な処理(findByPk, findAll, logicalDelete
>> >>> など)を持たせることは可能でしょうか。
>> >>> 自動生成された Bhv を見ると、ExBhv とそれに対する BsBhv しかなく、各テーブルごとに処理を持たせないと
>> >>> いけないのかなと感じております。
>> >>>
>> >>> ※最悪、commonBhv などを作って、全 ExBhv に DI しようかと考えていますが、、、
>> >>>
>> >>> 3．2．が可能な場合、自動生成されるメソッドが不要
>> >>> 自ら作成した共通メソッドをディベロッパに使用してもらいたいです。
>> >>> 大規模な開発の際に、全員に情報伝達できず、
>> >>> DBFlute によって作成されたメソッドが使われて論理削除されたデータが
>> >>> 画面表示されたりしてしまうとまずいので、、
>> >>>
>> >>> ※テストをしっかりしろと言われるかもしれないですが、現実問題起こりそうなので、、
>> >>>
>> >>> 4．また、こんなことをせずともその他解決、品質を高くできる方法
>> >>> 論理削除番号の持たせ方、実装方法など、ご指摘があればお願いいたします。
>> >>> ※私ならこうする～など
>> >>>
>> >>> 以上、お手数をおかけしますがよろしくお願いいたします。
>> >>> _______________________________________________
>> >>> Seasar-user mailing list
>> >>> [E-MAIL ADDRESS DELETED]
>> >>> https://ml.seasar.org/mailman/listinfo/seasar-user
>> >>
>> >>
>> >>
>> >> --
>> >> mokkouyou
>> >> [E-MAIL ADDRESS DELETED]
>> >>
>> >> _______________________________________________
>> >> Seasar-user mailing list
>> >> [E-MAIL ADDRESS DELETED]
>> >> https://ml.seasar.org/mailman/listinfo/seasar-user
>> >>
>> >>
>> >
>> _______________________________________________
>> Seasar-user mailing list
>> [E-MAIL ADDRESS DELETED]
>> https://ml.seasar.org/mailman/listinfo/seasar-user
>
>
>
> --
> mokkouyou
> [E-MAIL ADDRESS DELETED]
>
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user
>
>