私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】Laravel【フレームワーク】 Part.6
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
>>349
バッチ処理の意味知らない人初めて見たかもしれない
このURLに説明書いてますよ
http://www.otsuka-shokai.co.jp/words/batch-processing.html
バッチ処理の意味知らない人初めて見たかもしれない
このURLに説明書いてますよ
http://www.otsuka-shokai.co.jp/words/batch-processing.html
>>351
そのリンク先とLaravelのバリデーションとの関係は説明できます?
そのリンク先とLaravelのバリデーションとの関係は説明できます?
上の方のレスも読んでなんとなく言ってる意味は分かったが
バッチ処理の内部で起きてる話のことで、
それをバッチ処理と相性悪いって言われても意味は伝わらんわな
言い方が悪い
バッチ処理の内部で起きてる話のことで、
それをバッチ処理と相性悪いって言われても意味は伝わらんわな
言い方が悪い
>>352
こんな設計あるわけないでしょ
routeによってバリデーションの内容が変わるってのを極端に書いただけ
ここまで極端じゃなくとも大なり小なりrouteで変化するルールをどうやって対応するのかが聞きたかっただけ
それからクライアントからの絶対条件だったっ場合
設計がおかしいから変えないなら仕事したくありませんとかって言うわけでもないだろうし
FormRequestに書くって選択肢を許容すればそんなゴネる必要ないのに・・・
バリデーション分けると寿命が減ったりするわけでもないんでしょ?
こんな設計あるわけないでしょ
routeによってバリデーションの内容が変わるってのを極端に書いただけ
ここまで極端じゃなくとも大なり小なりrouteで変化するルールをどうやって対応するのかが聞きたかっただけ
それからクライアントからの絶対条件だったっ場合
設計がおかしいから変えないなら仕事したくありませんとかって言うわけでもないだろうし
FormRequestに書くって選択肢を許容すればそんなゴネる必要ないのに・・・
バリデーション分けると寿命が減ったりするわけでもないんでしょ?
>>357
だからrouteでモデルの解釈が変わるというのが設計が悪いという証拠
だからrouteでモデルの解釈が変わるというのが設計が悪いという証拠
その考え方だと
モデルに対してwebで出来ること以上の機能を持ったapiは設計が悪いってならない?
モデルに対してwebで出来ること以上の機能を持ったapiは設計が悪いってならない?
別にrouteによらなくてもバリデーションルールが様々な条件によって変わることは普通にあり得るし
Laravelも他のフレームワークもその辺は割と柔軟にできるように工夫してるでしょ
そしてそれはFormRequestに書くかどうかと全く関係ないぞ、スレを面白くしようとしてるのか知らんが変にややこしくするな
Laravelも他のフレームワークもその辺は割と柔軟にできるように工夫してるでしょ
そしてそれはFormRequestに書くかどうかと全く関係ないぞ、スレを面白くしようとしてるのか知らんが変にややこしくするな
FormRequestはバッチで使用できないから廃止しようというissuesが前に立ったけど
結局否決されてクローズだったな
結局否決されてクローズだったな
>>351
機能文盲のようなので横から捕捉しておくと、ここで求められているのは、バリデーションを必要とするバッチ処理というものが何なのかって話だよ。
おそらく、それをはっきりさせた後にバリデーションについて語りたいんだろう。
機能文盲のようなので横から捕捉しておくと、ここで求められているのは、バリデーションを必要とするバッチ処理というものが何なのかって話だよ。
おそらく、それをはっきりさせた後にバリデーションについて語りたいんだろう。
>>364
違う 俺が言ってるのはまずはバリデーション抜きでバッチ処理を語ってくれってこと
違う 俺が言ってるのはまずはバリデーション抜きでバッチ処理を語ってくれってこと
バッチでユーザーリストのcsvファイルを読み取って、追加更新するとか。
これくらいも思いつかないのか。。。
これくらいも思いつかないのか。。。
>>365
俺が機能文盲だったのか。100年ぐらいROMってるわ。
俺が機能文盲だったのか。100年ぐらいROMってるわ。
FormRequestでバリデーション実装しているやつはバッチ処理を考えていないを指摘したら、急にスレの流れが変わってそのことに触れないようにしててワロタ
やっぱLaravelスレって零細しか居ないんだろうなぁ
大企業向けワクチン接種の予約した人もここには居ないんだろうな
大企業向けワクチン接種の予約した人もここには居ないんだろうな
>>369
おれ一応大企業ね。1000人超えてるから。ただし事業部制だから全然実感は無い。
おれ一応大企業ね。1000人超えてるから。ただし事業部制だから全然実感は無い。
おそらくWEBインターフェースを使用しない話をしてるのだろうが、
それをバッチ処理という括りで話すのがまずおかしい
おそらく永遠に話が噛み合わない
バッチ処理言ってるのは古いシステムを触ってるおっさん世代と思われる
それをバッチ処理という括りで話すのがまずおかしい
おそらく永遠に話が噛み合わない
バッチ処理言ってるのは古いシステムを触ってるおっさん世代と思われる
>>374
後学のために教えて欲しいんだが、例えば50万件のデータを毎日DBに投入するときは、どんな設計にすれば良いの?
後学のために教えて欲しいんだが、例えば50万件のデータを毎日DBに投入するときは、どんな設計にすれば良いの?
>>377
すごい!モダンだ。
すごい!モダンだ。
俺の会社も考えたらバッチ処理ってないな
いろいろな設備や予約を行うためのシステムだけど利用者に関するデータはそもそも他社のアカウント管理サーバがあるからそこを参照しているだけだし
実際の予約情報もまた他社のExchange Web ServicesにアクセスしてデータのCRUDを行うだけ
備品や施設情報もExchange Web Servicesから参照しているだけだし
いろいろな設備や予約を行うためのシステムだけど利用者に関するデータはそもそも他社のアカウント管理サーバがあるからそこを参照しているだけだし
実際の予約情報もまた他社のExchange Web ServicesにアクセスしてデータのCRUDを行うだけ
備品や施設情報もExchange Web Servicesから参照しているだけだし
>>361
俺としてはフレームワークでlaravelを選択した際には
リクエストされた値に対してのバリデーションなんだからform requestに書くって自然な流れだと思ったんだけど
modelに書くのが一般的って言うからどう対応してるのかが知りたかったんだよね
そっちのがlaravelの文脈として理にかなってるなら考えを改めて、ウソ教えちゃった人達に謝って訂正しようと思ったから粘着質になってしまった
申し訳ない
俺としてはフレームワークでlaravelを選択した際には
リクエストされた値に対してのバリデーションなんだからform requestに書くって自然な流れだと思ったんだけど
modelに書くのが一般的って言うからどう対応してるのかが知りたかったんだよね
そっちのがlaravelの文脈として理にかなってるなら考えを改めて、ウソ教えちゃった人達に謝って訂正しようと思ったから粘着質になってしまった
申し訳ない
FormRequest書いたルールをrule()メソッドで参照したらどこでもバリデーションできるけどそういう話じゃないだろな多分
いやほとんどのケースでFormRequestに書くで別に問題ないだろうし
他で必要な場合は>>381みたいな方法でも別にいいと思うぞ
でも他のFWみたいにモデルに書く手もあると思うし、何故かそれを認めない輩も一定数いる模様(一人かも知れんが)
他で必要な場合は>>381みたいな方法でも別にいいと思うぞ
でも他のFWみたいにモデルに書く手もあると思うし、何故かそれを認めない輩も一定数いる模様(一人かも知れんが)
転職サイトとか見ててもLaravel案件は単価低いから仕方ないよね
Laravelというかphpが低いのかもしれないけど
Laravelというかphpが低いのかもしれないけど
Windowsの古のシステムを保守してたおっさんが紛れ込んだと思われる
AWSだってわざわざバッチ用のサービスを用意しているというのに、このスレの奴らは大量のデータを一括で処理するようなユースケースに遭遇したことがないのか?それとも、その場合バッチ以外の手段で対処している?
キャリア1、2年目のエンジニアがバッチ処理必要になった時に、設計したことないって話は聞くけども。
キャリア1、2年目のエンジニアがバッチ処理必要になった時に、設計したことないって話は聞くけども。
俺もそれは不思議
バッチという言葉も知らず実装したこともない初心者無職が、なぜか開き直って偉そうに罵倒してくるスレ
バッチという言葉も知らず実装したこともない初心者無職が、なぜか開き直って偉そうに罵倒してくるスレ
当然知ってるからこそパラメータとか言ってるのが滑稽なのだよw
定期処理ならパラメータなんて無いし
(あってもその日時とかやろ)
必要に応じて動かすならフォームからパラメータ入れたりして実行するし
そもそもそういうパターンは管理画面だから非同期にする必要も本来は無いのだけどな
定期処理ならパラメータなんて無いし
(あってもその日時とかやろ)
必要に応じて動かすならフォームからパラメータ入れたりして実行するし
そもそもそういうパターンは管理画面だから非同期にする必要も本来は無いのだけどな
パラメータおじさんが何もわかってないことはわかった
お前はずっとROMでいいよ
お前はずっとROMでいいよ
>>391
へー、最近は数十万件のデータの処理であっても、オンラインでhttpタイムアウトする前に処理終わるんだ?
へー、最近は数十万件のデータの処理であっても、オンラインでhttpタイムアウトする前に処理終わるんだ?
>>391
エンジニアじゃない人はロムっててね
エンジニアじゃない人はロムっててね
1日に1回、基幹システムからデータを取り込む処理とか作ったことないの?零細の俺ですらあるというのに
>>391
よくあるサブスクのサービスとかで月に一度クレジットカード会社に請求する仕組みとか世にいくらでもあるんだが、君はどうやって実装してるのか知りたい
よくあるサブスクのサービスとかで月に一度クレジットカード会社に請求する仕組みとか世にいくらでもあるんだが、君はどうやって実装してるのか知りたい
>>391
FormRequest使ってるバカwwwww
FormRequest使ってるバカwwwww
>>394
1日1回じゃなくて1日中やりつづけたらいいよねって話
1日1回じゃなくて1日中やりつづけたらいいよねって話
みんなの評価 :
類似してるかもしれないスレッド
- 【PHP】Laravel【フレームワーク】 Part.9 (884) - [98%] - 2022/3/13 12:00
- 【PHP】Laravel【フレームワーク】 Part.8 (148) - [98%] - 2021/8/8 21:30
- 【PHP】Laravel【フレームワーク】 Part.7 (779) - [98%] - 2021/7/9 16:18
- 【PHP】Laravel【フレームワーク】 Part.5 (568) - [98%] - 2021/5/1 22:00
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
- 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
- 【PHP】Laravel【フレームワーク】 Part.10 (446) - [96%] - 2022/6/6 19:30
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [96%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [96%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
- 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
- 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46
トップメニューへ / →のくす牧場書庫について