date fromtoについて

2 views
Skip to first unread message

mokkouyou

unread,
Jan 9, 2026, 7:43:34 AM (2 days ago) Jan 9
to DBFluteユーザの集い
mokkouyouです。
今年もよろしくお願いします。

さて、cbで便利な機能としてdateのfromtoがありますが、
昨今のmysql厳密化もあり、
最大の日付として9999/12/31など設定している場合で、
こいつをTOに指定した場合には
条件としてxxx<10000/01/01となり、実行時にエラーとなってしまいます。

昨今のmysqlの厳密化の流れでちょっと困ったケースとして出てきました。
fromtoを使わずtoはlesseaualにすればいいだけなんですが、
FROMTOが良き様に動いてくれる便利な方法がないでしょうか?

また、from toが生成されない方法などないかな?も知りたいです。
データとしては許されるけど、fromtoで利用するとエラーになってしまうデータ依存の微妙なので。ナレッジとして以外の対応が出来ないかなと。

以上よろしくお願いいたします。
※スマホで開くと新しい会話始めるボタンないんですね。pcサイトとして開くとメニューに出てきましたけども

kubo

unread,
Jan 9, 2026, 1:05:54 PM (2 days ago) Jan 9
to dbf...@googlegroups.com
jfluteです。

mokkouyouさん、こんばんは。
こちらこそよろしくお願いします!(^^。

なるほど...試してみたら確かに落ちますね。
// dbflute-test-dbms-mysql
https://github.com/dbflute-test/dbflute-test-dbms-mysql/commit/84727ed3408fd4c2a15acf3e4b8497c31ca61def

FromTo 自体を消す時は、
conditionBeanMap.dfprop にて、自動生成対象外にすることはできると思います。

; Date = map:{
# [Include]
# Date columns may not be needed
# to be set these condition-keys basically.
; NotEqual = map:{}
; InScope = map:{}
; NotInScope = map:{}
; FromTo = map:{}

// conditionBeanMap | DBFlute
https://dbflute.seasar.org/ja/manual/reference/dfprop/includequery/index.html


ただ、せっかくの機能がもったいないのでどうにかしたいところですね。

以下のIssueであれこれ試行錯誤しています。

// DBFlute Runtime: MySQL, FromTo 9999/12/31 moves to 10000/01/01
https://github.com/dbflute/dbflute-core/issues/316

要は、9999/12/31なら埋める方式で lessEqual にするってことですが...

DATE型に対するFromToなら9999/12/31のまんまで lessEqual すればOKな一方で、
DATETIME型に対するFromToなら時分秒ミリ秒を埋めて lessEqual することになって...

ミリ秒なしDATETIMEの場合はミリ秒が四捨五入されるので.499まで埋める、
ミリ秒ありDATETIMEの場合は完全にその日を含むためには.999まで埋める、
でも、ミリ秒なしありかどうか?がDBFluteで判断できるかな!?
あと、厳密にはDATETIME(1), DATETIME(4) とかの可能性もあるので、
精度に合わせた埋めをしないと、ってところが課題で。

もうちょい練ってみます。

mokkouyou

unread,
Jan 9, 2026, 10:23:51 PM (2 days ago) Jan 9
to dbf...@googlegroups.com
jfluteさん

ありがとうございます。

生成制御出来るのであれば、
一旦抑制して利用箇所見つけてみたりも出来ますね。試してみます。

fromtoはたしかにもったいないんですが、
おっしゃるとおり課題も多そうですし、dbmsによっても違ったりしそうで怖い部分ですよね。そもそも今回は9999年ですが閾値がどこにあるんだ?というのからして。
(対応されるにせよ、標準実装と、それを拡張出来る仕組みないと大変そうだなとは思いました、、、)

該当プロジェクトだとどのみちバージョンアップは適応出来ないので、私の方は気にせずいつもの素敵なバランス感覚でご検討頂ければと思います。





2026年1月10日(土) 3:05 kubo <dbf...@gmail.com>:
--
このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには dbflute+u...@googlegroups.com にメールを送信してください。
このディスカッションを表示するには、https://groups.google.com/d/msgid/dbflute/CAALfU-AWQCyDsDa%3DPZ-OCK165qQEx1wE-bRs8OZE%2BDdZfHA7Fw%40mail.gmail.com にアクセスしてください。

kubo

unread,
Jan 10, 2026, 10:30:33 PM (14 hours ago) Jan 10
to dbf...@googlegroups.com
jfluteです。

> 該当プロジェクトだとどのみちバージョンアップは適応出来ないので、私の方は気にせずいつもの素敵なバランス感覚でご検討頂ければと思います。

ありがとうございます。とりあえずフィードバック頂いたということで、
何かしらアプローチはしていきたいと思います。
確かに、簡単に落ちるってなるとちょっと今後も使うの不安になってしまいますからね。


> dbmsによっても違ったりしそうで怖い部分ですよね。

たぶん、MySQL限定とかDBMSを列挙して対応するような感じにしようと思っています。
もしくは、dfpropによるオプションとか。


ちなみに参考までにお聞きしたいのですが、
FromToにsetすると条件値として 9999/12/31 が入るケース、
業務としてもう少し具体的に教えてもらってもよろしいでしょうか?

> 最大の日付として9999/12/31など設定している場合で、
> こいつをTOに指定した場合には

これって、すでにDBの終了日付カラムとかに9999/12/31が入る仕様になっていて、
(実質、終了日付がないという感覚で。よくやるパターンではありますが)

fromDate以降終了日付を全部ヒットさせるのに?、toDate に 9999/12/31 を入れるという感じ???でしょうか...

こういうケースがあり得ると、説明する際とかに使えたらと思いまして。

mokkouyou

unread,
Jan 10, 2026, 10:52:04 PM (13 hours ago) Jan 10
to dbf...@googlegroups.com
jfluteさん

仕様としましては、そうですね。そのパターンです。
社員マスタとその所属みたいなものイメージですよね。

所属には履歴があって、from toを持っていて、現在の所属のtoには9999が入る仕様で、ユーザ入力によらない部分です。入力は基本fromだけ。

この期間を調整(あらたな所属登録)する際に、新たな所属となる期間において参照、たとえば、現部署での実績みたいなのがないか?の確認みたい検証で落ちてしまうと。



2026年1月11日(日) 12:30 kubo <dbf...@gmail.com>:
--
このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
このグループから退会し、グループからのメールの配信を停止するには dbflute+u...@googlegroups.com にメールを送信してください。
このディスカッションを表示するには、https://groups.google.com/d/msgid/dbflute/CAALfU-AXMuhmDuu%2Bmg5LV1HWUpG4o6s1AmgOXLOfDFCteqsGGQ%40mail.gmail.com にアクセスしてください。

kubo

unread,
3:35 AM (9 hours ago) 3:35 AM
to dbf...@googlegroups.com
jfluteです。

なるほど、ありがとうございます。

ふと思ったのですが、toDate を 9999/12/31 にするときってのは、
実質的に「まで」の部分の条件は無しにするのと同等なのかなと。

なので、MySQLにおいては、toDate が 9999/12/31 だったら、時分秒ミリ秒を埋めるのでは無く、
条件自体を無しにするってのもアリかと思いました。
実装してみて埋める方が逆に楽とかもあるかもなので、
そこは実装しながらどっちにするかは考えるということで。


でも、書きながら思い直しました。

対象日付カラムに null のレコードがある場合、<= 9999/12/31 では弾かれますが、
条件ナシにするとヒットしてしまいますね。。。

やはり、「時分秒ミリ秒を埋め」ですね。
Reply all
Reply to author
Forward
0 new messages