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

[HATTI]

お世話になっております。
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
>>
>>
>