ClassificationDBFlute-1.1だとこうなるシリーズ、すいません、まだあります。区分値の設定とか微調整的なものですが、大切な話。Strictという感じでした。デフォルトfalseだが、ほとんどtrueでOKのプロパティ名付けて「隠れ区分値」そういったものが万が一あったらと。「データの内容次第で検索できない」ってのは、なかなか厳しいこともあると思うんですよね。そんなレアケースに縛られてても、いや、安心というポリシーからしたら逆に、うーん。いうことで、結局こうしました。落とさないけど「おかしいかもしれないよ」って感じで。ベタうち復活cb.query().setMemberStatusCode_Equal("FML");member.setMemberStatusCode("FML");わざとやっているのか?まちがいなのか?ということで、デフォルトの状態でちょっとだけ厳しくなりました。実行時の「紛れ」で下手にシステム落ちないように。究極は自動で判別できないというところでした。ヒアリングをしていると、やっぱりjfluteの想像を超えるシステム構成や運用をしている話が耳に入りました。使われるかどうか!?って話はあるのですが、結論としては「ありえそう」でした。「一つのDBで、複数のアプリ、複数の組織が運用している」なんてことがあると、そういうことあるかなーと。変なコードが来たら検知したいってのはありますが、それを仕組みのデフォルト設定ではちょっとできないなと。デフォルトで落とすのは、やめようと。いって、何かしら警告はしたいので、ログという形にしました。遠慮なくデフォルトで削除。必要であれば、isMake...してしまえばいい。本番で発生するのか、開発中に発生するのか?本番で発生する可能性があるものは、100%まちがい!と言い切れないとチェックしづらい。いうジレンマがあります。ネイティヴ型メソッドを削除すると、CDefのcodeOf()を使うから未定義区分値の検索どうする?っていう話につながっていたのですが、そのつながりをやめました。未定義区分値を検索することはできる、という風に。チェックの話と切り離せて考えられるようになりました。似たような話で、NotNull制約などがあります。アプリを再リリースせずに、NotNull制約だけ付けたり外したりって、ありえるだろうと思って、DBFluteではドキュメント要素という位置づけでしか使っていません。DBスキーマとDBFluteがズレてもある程度は動くようにしておかないとというところで。undefinedHandlingTypeに統合されました。「EntityのSetter呼び出し時チェック」に統合されたと言えるかもしれません。別に検索時だけチェックである必要はないし、ほとんど似たような機能だったので、わかりやすさも考慮して一緒にしました。undefinedHandlingTypeに統合されました。「EntityのSetter呼び出し時チェック」に統合されたと言えるかもしれません。別に検索時だけチェックである必要はないし、ほとんど似たような機能だったので、わかりやすさも考慮して一緒にしました。今までと同じプロパティがそのまま利用できます。(classificationDefinitionMap)これらは、1.1からはドキュメント上からも削除されますが、しばらく動き続けるプロパティです。基本的に同じ挙動になるはずです。「厳しくなるのではなく緩くなる、もしくは、ログが出るだけ」というポリシーで実装しています(そのはず)。falseなら、それだけでOK。古いプロパティを削除しても同じ動きになるかと。実は、いわゆる「大規模がっちり業務システム」みたいな開発の経験は実は少なかったり。DBFluteは、変化の激しいインクリメンタルな世界を主なターゲットではありますが、様々な応用も効かせたい。色々な話は聞いて疑似体験として積み重ねていますが、やはり感覚としては薄れてしまうもの。なにを心配するか?なにを安心と思うか?なにが効率的なのか?これら、現場でいろいろ違うわけで、バランスよく考えて良いものを提供するために、コミュニケーションマニアにならないとぅ。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。