アカウント名:
パスワード:
連続性が担保されているデータならともかくどう途切れるか不明なデータの連続性で何か判定しようとするのは狂っている
たぶんwhile(処理件数 > 0) { 処理件数 = 送金処理(リスト#next1000件);}みたいなループなんだと思う。このループ処理の実装者と送金処理の実装者が違うなら、まぁ分からなくもないかなぁ。狂ってるというか、仕様をちゃんとチェックせずに実装しちゃった系のよくある普通のバグでしょ。
とにかく1000件読んできて、1件も処理すべき内容がなかったら終了というのがエラー検出ではなく正常な終了判定なんですかね。
不思議なのは、自動送金の処理プログラムが何件処理すべきか分かっていないということ。三菱東京UFJ銀行では、顧客から依頼されている自動送金の依頼数をコンピュータシステム上に持っていない(実際に処理してみないと分からない)ということだろうか?
# 「1度に読み込む件数を5000件に増やしたのでもう取りこぼすことはありません」となったりして。
高速化や別件対応でありそうな「正常終了判定」という印象。某都市銀行のバグ管理簿みたことあるけどテスト漏れとしか思えないバグばっかだった。「よくある普通のバグ」に全面的に賛同だわ。
> 1000件連続で「データ無し」になるとすべての処理が完了したものとして
こんな終了条件が必要なケースが思いつかないバグというより余計な処理入れてるわけで高速にもならんしスタブミスとしても不可解
うーん、ハード増強したから一括処理件数増やしたらシステムダウンとか端末で特定のミス2回連続したら無限ループとか紙伝票の余白が終了条件で余白がなければ白紙挿入という仕様で白紙が連続したら処理停止とかそういうマヌケなバグいっぱいみたんで思い付かないといわれてもありそうとしか。増税直後で何かしらシステム変更してるだろうし。1000件連続データなしはうかつだけど、一定アイドルで次の処理はあった気がする。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
話にならない (スコア:0)
連続性が担保されているデータならともかく
どう途切れるか不明なデータの連続性で何か判定しようとするのは狂っている
Re: (スコア:3)
たぶん
while(処理件数 > 0) {
処理件数 = 送金処理(リスト#next1000件);
}
みたいなループなんだと思う。
このループ処理の実装者と送金処理の実装者が違うなら、まぁ分からなくもないかなぁ。
狂ってるというか、仕様をちゃんとチェックせずに実装しちゃった系のよくある普通のバグでしょ。
Re: (スコア:1)
とにかく1000件読んできて、1件も処理すべき内容がなかったら終了というのが
エラー検出ではなく正常な終了判定なんですかね。
不思議なのは、自動送金の処理プログラムが何件処理すべきか分かっていないということ。
三菱東京UFJ銀行では、顧客から依頼されている自動送金の依頼数をコンピュータシステム上に
持っていない(実際に処理してみないと分からない)ということだろうか?
# 「1度に読み込む件数を5000件に増やしたのでもう取りこぼすことはありません」となったりして。
Re:話にならない (スコア:0)
高速化や別件対応でありそうな「正常終了判定」という印象。
某都市銀行のバグ管理簿みたことあるけどテスト漏れとしか思えないバグばっかだった。
「よくある普通のバグ」に全面的に賛同だわ。
Re: (スコア:0)
> 1000件連続で「データ無し」になるとすべての処理が完了したものとして
こんな終了条件が必要なケースが思いつかない
バグというより余計な処理入れてるわけで
高速にもならんしスタブミスとしても不可解
Re: (スコア:0)
うーん、ハード増強したから一括処理件数増やしたらシステムダウンとか
端末で特定のミス2回連続したら無限ループとか
紙伝票の余白が終了条件で余白がなければ白紙挿入という仕様で白紙が連続したら処理停止とか
そういうマヌケなバグいっぱいみたんで思い付かないといわれてもありそうとしか。
増税直後で何かしらシステム変更してるだろうし。
1000件連続データなしはうかつだけど、一定アイドルで次の処理はあった気がする。