ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
和訳ドキュメント
http://laravel.jp/
※前スレ
【PHP】Laravel【フレームワーク】 Part.5
https://medaka.5ch.net/test/read.cgi/php/1618535648/
探検
【PHP】Laravel【フレームワーク】 Part.6
レス数が1000を超えています。これ以上書き込みはできません。
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
和訳ドキュメント
http://laravel.jp/
※前スレ
【PHP】Laravel【フレームワーク】 Part.5
https://medaka.5ch.net/test/read.cgi/php/1618535648/
PHPフレームワーク Laravel Webアプリケーション開発 バージョン8.x対応
それとも9や10でガラッと変わったりする？
相変わらず気持ち悪いやつだな
たまには部屋から出て太陽の光でも見てこい
9でめちゃくちゃ変わる
今は時期が悪い
そうなのか・・・
じゃ、>>2も買わないほうが良いのか
それ、どこ情報？前も似たようなこと言ってた人居るけど、同一人物？
今週Taylor兄貴が海外で放送されているIT関連の専門チャンネルに出演したんだけど
そこでLaravel9について質問された際に答えた内容がどう考えても多少の変更ではないレベルだったんだよ・・・
Laravel9ではまだそこまで影響でないと思うけど・・・
それをやめてMVVMパターンにしたいって話ね
私としてはMVVMを採用したいけど変更が多すぎるからMVCのままでしょうね HAHAHAHA
って言ってただろ MVVMになることはない
そういうことか。ありがとう。
>>12
それだと大きな変更にはならんよね。MVVMパターンてLivewire使ったら自然とそうなるし。JetstreamなんてまさにMVVMパターンの典型。controller要らなくなるなーてのを実感してる。
せやね
誰かのレビュー待って検討するか
>>2は大抵の人にとってはゴミだからやめろ。
お前が大丈夫か？
オウム返しじゃなくて、具体的な反論を頼む。
composerの時代になってからこれが起きまくって困る、なんでこんなクソシステムが支持されてるの？
今vendor消してやり直したら復活したけど時間かかってしゃーないわ全く
そんなのなったこと無いがどうやればそうなるの？
phpの時代になってからこれが起きまくって困る、なんでこんなクソ言語が支持されてるの？
よく分からんから全部消して最初から書き直したら解決したけど時間かかってしゃーないわ全く
おまえだけやろそんなのw
マジかよ
Windows10上のDocker環境で普通に開発してるだけなんだがよくなるぞ
ならない環境教えて欲しい
エラーの具体的なメッセージ書かないと分からんやろ。
ここに詳しく書いても誰かが解決してくれるわけじゃないから書かなかったけど、抜粋するとこんな感じ
composer clear-cache
composer update --no-plugins
とか色々試したが駄目だった
- Upgrading symfony/var-dumper (v5.2.3 => v5.2.8): Update failed (Could not delete /var/www/html/vendor/symfony/var-dumper/Caster: )
- Upgrading nesbot/carbon (2.44.0 => 2.48.1): Update failed (Could not delete /var/www/html/vendor/nesbot/carbon/src/Carbon: )
0/5 [>---------------------------] 0% Install of psy/psysh failed
1/5 [=====>----------------------] 20% Update of league/commonmark failed
2/5 [===========>----------------] 40% Update of nikic/php-parser failed
3/5 [================>-----------] 60% Install of phpunit/phpunit failed
4/5 [======================>-----] 80% Update of nesbot/carbon failed
5/5 [============================] 100%
[ErrorException]
file_put_contents(/var/www/html/vendor/bin/var-dump-server): failed to open stream: File exists
ありがとうございます！
初心者向けかそれ以外かだけでもレビューください
既にファイルあるぞって警告出てるだろ
var-dump-server消せよ
昔よくあった「PHPで掲示板を作る本」的な、
Webアプリ作りながら進めるような内容かも教えて下さい。
公式のドキュメントは機能紹介が中心で、とっつきにくかったので。
何が起きてるか、どんなエラーなのか書かないとそもそも対策すら立てられない気がするが
こちらはhomesteadで開発してるけど問題起きたことは無いなぁ
たぶんそういう本じゃないと思う
詳しくは目次
https://honto.jp/netstore/pd-contents_0630901278.html
ほんとですね・・・
Laravelのドキュメントも見てるんですが、よくわからないんですよねぇ
最初からDockerがどうのって時点で詰みます。
Composerはわかるものの、専門用語が多くてパニックになってます。
だから、もう少し初心者向けなら良かったんですが
目次を見る限り、ドキュメントと変わらないっぽいですね
まんま>>29と一緒だろ
エラーメッセージくらい読めば大抵のこと解決するのに
じゃあエラーださなければいいのでは
なんでこんなスレまで来て粘着してるのか
初回以外に構成が変わったりしない限りそう叩くものじゃなくね？
composer dump-autoload
は叩くことがあるかもしれないが
laravel/uiとか
1つの開発に数回ぐらい感覚的にある
>>39
そりゃそうなんだけどなんでそんなことになるんだよ
エラー出たら都度手動で削除しながら使うツールがあるかいや
それともただの趣味？
趣味とかwebの学習でと言う人はPHPにあんまり行ってない気がする
仕事はPHPが一番ありそうだけど素人はPythonとかに何故か行くよね
求人数と年収ともにjavaに負けるが
求人数と年収がjavaに負けているということは
javaに負けているという可能性があるな
でもそれがPHPの世界のスタンダードだよ
それが受け入れられないんだったら暗黒の世界へお帰り
立ち読みしてから買うの決めるか
カスタマイズ系の本が少なすぎるので出版してもらいたい
いつも先行発売してくれるジュンク堂になかったからamazonで購入
明日届く
明日なら店頭にも並んでそうだな
お願いします！せめて初心者向けかだけでも教えて下さい
初心者向けだよ
初心者しか読まないのに
必要なページだけ読みたいね
どういう意味だ？
user()の中に情報入ってました
user関数とかで情報取得できない？
Laravel初心者さんはぜひ買っても問題ないです。
ただ、PHP初心者さんには難しいかもしれないです
本の手順で進めればひと通り理解できる内容ですか？
あと本が分厚くて読みにくい（学習しにくい）とかありますか？
ページ数が多いので全部読んでいませんが
辞書として必要なところを調べる形で使っています
それでも問題ない認識です
なるほど。順番に進めて覚えるような感じではないんですね
Windows環境でも解説ある？
Windows XPのことですか？
キャッシュかとおもってキャッシュクリアコマンド実行しても反映されず
OSの再起動を実施すると反映されることがごくたまにある
Note: 開発過程の一環としてconfig:cacheコマンド実行を採用する場合は、必ずenv関数を設定ファイルの中だけで使用してください。設定ファイルがキャッシュされると、.envファイルはロードされません。したがって、env関数は外部システムレベルの環境変数のみを返すだけです。
いいえ、普通にwindows10ですが？
どうしてそんな古いOS使ってると思ったんですか？
laravelスレの人はこんな捻くれた回答しかできないんですか？
一応皆スルーしてるみたいなので、お前もスルーしとけ。下手に触ると喜ばせるだけ。
滑ってるぞ
他のフレームワークと比較したときに人間が感知できるレベルで
処理などが遅くなるのでしょうか？
遅いと言えば遅い。Railsとどっこいどっこいって感じ。ただしそれはOPcaheを使ってない場合。OPcache使えば、おおよそ5-10倍のリクエストを捌けるようになり、十分な速さになる。
.envの使い方間違ってるだろ
CakePHPと比べるとどうですか？
ちゃんと自分の環境を書かないからそうなる
5系だとお安いので迷ってます。
サポートが長いバージョンとのことで大丈夫かと思ったのですが
もうサポート切れてたようです…
大人しく8系で安く出るの待ちます！
分からん。けどcakeのほうが早い可能性が高い。ただしOPcacheを使っているならば、ビジネス上懸念されるような差は無いと予想。
なるほど・・・。
cakeは2までの知識しかないのですが、2でも遅いって話があるのに
それよりも遅いってのもなかなか辛いですね。
今はページ表示速度もSEOの指針になるので
金ないならアルバイト1日頑張ればええやん
タイムイズマネーだよ
そんなの待ってたらずっと取り残されたままで永遠にものにならないよ
正直公式読んで分からないやつは趣味なら大丈夫だけど仕事ではキツいぞ
本なんて買う必要ないよ
職人のフレームワークだから公式は初心者には寄り添ってないしね
公式読み解けるレベルまで行けばそれ以降は本は不要
ビジネス上懸念されるようなことは無いって書いたのにスルーしないでくれ。cakeにしても遅い遅い言ってる奴は、どうせOPcache使ってないだろ？
SEOに関してはDBのI/Oやフロントエンドで使用するアセットのサイズ、ブロッキングの有無の方が1万倍重要。
本を読まないやつは無能
他人を無能扱いするなよ無能
必要なところだけ読めばいいのでは？
それで分かりにくいとかならググれば大抵はヒントがあるやろ
第一、じゃあその本書いた人たちはどうやって習得したんだろう？て話。無能な奴らが書いた本をありがたがってるってことになるわけだが。
多分106はいつもの荒らしだから相手にしないほうが良い
必要なところだけ、しかもググった結果を集めてくれてる
それが書籍じゃないのかな
だとしたら有料であるという以外は書籍有利では？
・動かして学ぶ! Laravel開発入門
・PHPフレームワーク Laravel Webアプリケーション開発 バージョン8.x対応
を立ち読みしてきました。
どちらも初心者向けだと感じましたが、前者の方が読みやすかったです。
ただ、前者のはバージョン6対応とのことですが、
8とか9を勉強するなら問題ありますでしょうか？
後者は初心者にとって半分以上ゴミになる可能性があるから、1冊目にしとけ。
どちらが優れてるかなんて状況次第だし、本でもネットでも好きなので覚えればいいのに
すまん、前レス見てなかったが「どちらが優れてるいるか」のくだりは書籍かネットかの話ね
113のどちらの書籍が良いかという話は俺には分からん
ここの主かなんかなん？
きちんとググり方がわかっていて予備知識があるなら必要ないよ。
過去の技術書殆捨てちゃたよ
作者乙
そうだぞ。本はマニュアル読み解けないレベルの初心者向けって感じの位置付けで良いと思う。
これ基礎から学ぶのに何かええ教材ないかな
無理に使うことないんじゃね？
使うと最初から色々できてて楽なんだよ
これをベースにしたい
なんでそんな言い方するの？
これどっちにしても流行らないでしょ？
ググればすぐに出てくるやん…
初期状態で認証とチーム管理が扱えるということですか？
model-view-viewmodel というアーキテクチャのこと。フロントとバックエンドは、controllerを介さずview modelという層を挟んでmodelと状態やデータを同期させる仕組み。
絶滅危惧種だろ
JavaScriptが怖いのは基本的にはXSSで、それは「信頼したいサイト」ほど仕込まれたときの影響が大きい
無駄に利便性を削ってると思うぞ
9になればどうせすぐにアップデートするんだから
機能だけなら今で十分だよなぁ
コレクションがもう少し処理速度が改善すればとは思うけど
ソーシャルログインはsocialite使うって話なら、8にも対応してるから大丈夫。
対応してる・してないってどう見極めたら良いの？
ググって使いたいライブラリやプラグイン探して、
あればそのバージョンを勉強していく感じ？
いや、composer.json見りゃわかるよ。
composer.json見りゃわかるんだけど
サポートと依存が違うことが分からないのか
サポートしているから必ずしも依存しているとは限らない
自分で確認してこい
https://packagist.org/explore/?query=laravel
書いてないな
>>160のは誤っているので参考にしないようにしましょう
DB保存のお問合せフォームみたいなの作るんだけど、
過去に作ったオレオレ使うか、Laravel使うかで悩んでる
テーブル1つ2つで済むような規模でFW使うのもなぁ
字面だけでメチャクチャヤバそう
そんなゴミさっさと捨てて、前に進む勇気を持った方が幸せになれる
>>163みたいなお問い合せフォーム程度でも使ってるの？
納品する時ファイル数多くなって余計に面倒な気もするが
彼はbigintを枯渇させたらしいけど一体何のシステムを作っているのだろうか
そのサイトがこの先ずっとお問い合わせだけで終わる保障はないし、納品後誰が触るかわからないじゃん？
だから規模に関わらずLaravel使ってるよ
あくまで私はそうしてると言うだけで、万人に対するベストアンサーかは知らん
サポートと依存が異なるっていうか、特に下位互換性については、main(master)のcomposer.json見ても分からんから、ReadMe読めってことかな？
バージョン落とせば古いLaravelにも対応できるパッケージがある一方、最新の8しかサポートしてないやつもあるよね。
Googleフォームで十分すぎる
Laravel使っといた方が制御が楽でしょ
bigintを枯渇させた！？
それって全世界規模のシステム作ってないと枯渇しないのでは・・・
にわかに信じがたいな
ここアホしかいないから…
それは>>168の捏造。
実際はINT型で数年で破綻する設計があるので、
オーバーフローする型を主キーにする設計はおかしいという話だった。
>>168は以前から虚言癖あるからあんまりマトモに相手しない方が良い。馬鹿だから。
increment()をおすすめする記事があるんだよな
どんな案件でも得意のFW使うって、考え方として正しいのかもね
たとえCakeみたいに古くなっても、更新できるしな
要はフォームをPOSTで更新するかAJAXで更新するかの違いなんだけどどっちが使い勝手いいんだろうか？
個人的には本当にどっちでもいいしだったらユーザーが使いやすい方が良いんだけどそれもわからん
POSTかajaxかの違いは、MVCかどうかには関係ないだろ。
例えば、トップ、料金システム、サービス内容、ブログ、お知らせ、問い合わせのページがあるような場合です。
俺が迷ってるのはLivewire(MVVM)使うかMVC使うかって所な
後者でもAJAXできるが前者はAJAXオンリーになる
それならコンテンツ（モデル）毎にコントローラー作るべきだよ
なにせ用途が違うんだから
オーバーフローってことは枯渇についての話でしょ？
いまいち>>168の内容が捏造ってのがよくわからないんだけど
毎年出すほどは売れないから
フレームワーク限定の本なんて今の時代より売れない気がする
もうちょっとPHPのシェアが上がらないとなぁ
釣り針デカすぎ。荒らしは消えてどうぞ。
bigintであれば数年で枯渇するようなレベルではなくないか？
普通にbigintのインクリメント使ってもいいとおもうけど
920京だとunsignedだからPHPでは読めない！とか馬鹿みたいなこと言ってたし(920京はsigned)。
laravelだとパージョン6から、標準のusersテーブルだとidにbiggntを使うようになっている。
何故increments()ではないのかの議論がissueかフォーラムか忘れたけどどこかにあったね
5.7まではincrements()、6.×でbigIncrements()、7.×でid()だな。その議論は7じゃなくて6の時じゃね？
なんで正論言ったら荒らしになるんだよ
何が気に障ったんだ
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
しつこい
釣られちゃったね キミの負け＾＾
黙れお前のせいで発狂しそうだ
INT でオーバーフローが懸念されたので BIGINT型に変更したのは Twitter くらいしか話を聞いた事は無いけど、
俺が言ってるのは、オートインクリメントでプライマリキー作るような奴はそもそもデータ型に対する理解なんか一切無い場合が殆どだから、
INT型の範囲がどの位あって、何年で溢れそうか？
みたいな計算一切せずに、何となくINT型にする馬鹿だらけだろう、って話。
で、問題が発生してなにが起こったのかすら分からず、連日徹夜で闇雲に調査してやっと気付いた時には大問題、みたいな、恒例のパターンになるだろ？って事。
この手の本なんて売れてもせいぜい数千部、頑張っても数万部とかだからね
印刷代、倉庫代、取次手数料、編集者の取り分なども考えたら著者に渡せる金はホント少ない
専業の人は何冊も書かないと食っていけないし、そうでない人は趣味みたいな気持ちでやるしかない
ただ、出版社も編集者も出版点数のノルマがあるので、
タイミングによっては数稼ぎでそこそこ手堅く損はしないだろうと判断できたら数稼ぎで本を出す
Laravel本は改定本出てるのが多いから、そういう対象にはギリギリなってるみたいね
おそらく次のLTSでも何冊かは出るよ
＞INT型の範囲がどの位あって、何年で溢れそうか？
＞みたいな計算一切せずに、何となくINT型にする馬鹿だらけだろう、って話。
これなんかデータあるの？それともお前の妄想？
これっていつ頃の出来事？そんなニュースあったっけ
たった一例しか知らないのに「何となくINT型にする馬鹿だらけだろう」って決めつけてるの矛盾してない？
仮に1日あたり1億レコード消費する計算だとsignedBigint(63bit)を消費するまで何年かかるか分かる？
そのぐらい人に聞かないで自分で計算しろよ・・・
214じゃないけど、聞きたいのって「何年か」ではなく「分かるか」であって、
integerではなくbooleanを求めているんでしょ
2.5億年かかるけど、おそらく彼は分からない
もしくはLaravelじゃなくてExpressにするか
ただしRailsだけは使わん
phpかjsだけにしておきたい
9を待つ意味はない
3、4年くらいかな？
2.35億年じゃないか？
8から9のほうが移行楽
6で開発してる人が移行するにしても9からだろ
6より8のほうがbugfixのサポート長いし、移行も楽だし。
seederはあくまでもテストデータを登録する用途だから
本番データを登録したいならartisan make:command等で専用コマンドを作ったほうがいい
--seedの指定しなければ良いんでしょうけどうっかりもあるので
破壊的操作に関して本番環境でチェック入ってるのは当然かと
面倒なことが多すぎる
APIだけなら別に何でも良さそうだけどね
でもAPIはオレオレ詐欺フレームワークで作るのきつくない？
それだったらLaravel使ったほうがいいでしょ
むしろフレームワーク通すとややこしくなりそうだが
過疎板でいつ消えるかわからんけど
インストール手順変わったよね？今回めっちゃ苦労したぞ
Composerに依存したシステムは破綻する
多分日本語で書いてあっても読まないだろうな
読んで対応したぐらいで解決してりゃ誰も苦労しないよ
githubにアップされてるLaravelベストプラクティスを読めば良いぞ。
同時に Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors. って出てるはずだけど
だったけど、ぐぐって出た対策じゃ解決しなかった。タイムアウトとか言われてもどうしたらいいんだよ。
https://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md
バリデーションはモデルでやれよ
Requestでやるとバッチ処理の時に困るぞ
前もそれ書いてたよね。Laravelエアプかよ。
そりゃそうよ。まぁtailwindCSS使った方が楽なことが多いから。アホみたいにCSS設計とか命名規約とかに無駄な時間使うことも無くなるし。
エアプって何？
言いたいことがあるなら普通に言えよ
Laravelのフォームリクエストは、外部からの入力を検証するための機構だからモデルでやれって主張はアホすぎるってこと。MVCでは、入力値の検査はコントローラーの責務。
RailsとかがModelで検査してるのは、MVCよりActiveRecordのルールを優先した結果に過ぎない。
そもそも画面やAPIからの入力とバッチの入力のバリデーション仕様が同じになるケースなんてまず無いと思うんだけど？
誰にも相手にされなかった主張を、また繰り返すのはやめたほうが良いぞ。
え、そんなことはなくない？
1つのテーブルにデータを追加するシンプルな要件だと、WebからフォームをPOSTしてもバッチで追加してもルールは一緒になるだろう
エラーメッセージの出し方とかは異なると思うけども、バリデーターをそれぞれ別に書いたりはしないと思う
どのフレームワークを使うか選択できなかったっけ？
モデルに書いてもリクエストに書いても、流れ上は「コントローラーでやる」と言っても間違いではない。
って理由まで答えないと成立しないけどな
268です。ありがとうございます。
ちなみにそれだと、
Aというルートではコントローラーにバリデーションを書き、
Bというルートではモデルにバリデーション書く、
というようにバラバラになってしまうんですが、気にしないほうが良いのでしょうか？
それとも一律コントローラーに書くほうが良いのでしょうか？
例えばLivewireだとViewModelでやる。
>>265
フレームワークの仕様による。LaravelはController。
>>266
どういうバッチを想定している？ファイルから一括でデータを投入するみたいなやつ？
それが許されるなら何でもありですがな
使い回したりメンテしやすいよう別の場所に出して、コントローラーはそれを呼び出すだけにしたい
じゃあどこに書くか？となると多分モデルなんだが、LaravelのRequestに書く仕様はちょっとビックリした
一見理に適っていて便利でもあるけど、既出の通りコマンドから同じバリデーションを実行する場合は一工夫必要になる
コントローラーのメソッドから呼び出すのは良くて、コマンドのメソッドから呼び出すのが良くない理由もお願いします。
好きなように書けよ
どうせ誰もメンテしなくなるんだし
バリデーションなんて動けばいい
コマンドからはFormRequestなんて使わないから
呼び出したくても呼び出せないぞ
とは言え、rulesはpublicだしどうしようもないわけではない
うまくやれば共通化もできるかもしれない
そうだねそうなるよ
逆にフォームからとバッチからでバリデーションルールが異なるケースってどんな時だよ
そんなの見た事ないわ
「空の時に表示が崩れる」という理由で本来必須じゃなかった項目をrequiredに変えたり
クライアントは馬鹿だから色々予期せぬ事が起こる
じゃあ今度からはモデルにルール書くね
メンテは自分が見てわかりやすくするためのものでもあるだろ
好きなように書いてて、半年後に見ても思い出せるのかよ
Symfony選んどいてよかった
ボケがツッコまれてるだけやろ
モデルでやるとかは無いわｗ
何でFormRequestがやってるバリデーションって入力された値が想定してる値かってバリデーションなので
その先にあるであろうテーブルとかを考慮しちゃいけないものだと思ってる
例えば同じテーブルに入力されるデータでも管理者権限と一般ユーザー権限でバリデーションルール変えたいってケースなんてザラだし
モデルに入力される値のバリデーションは持てるの担当範囲外でその担当は
おそらくバックエンドにあるデータベースが受け持ってて入力値が正しくない場合
Exceptionって形で戻してるって解釈してる
違うかな
ここはレベルが低いからそこまで理解できないらしい
正直俺もFormRequest使ってるぜってどや顔でこのスレの住人に言われたときは愕然としたな
バッチ処理何も考慮してないよな こいつらマジでバッチ処理どうやってるんだろうか
なんの処理を気にしてるわけ？
頭悪すぎｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
こういうやつの為に、バッチにもバリデーションが必要なんだよな。
バッチ処理で間違った入力がされない保証が100%じゃない限り、本来ならバリデーションするべきとは思うけど面倒だからやらないで運用でカバーしてもらう事が多いのも事実
バッチ処理がBatchableジョブの事を言ってるのかartisanコマンドで任意に叩いた処理の事言ってるのかどちらを指してるかわからんけど
どっちにしろ動かす状況やら権限でバリデーションルールが変化するわけだから
機能(バッチ処理)ごとにそれぞれルールは必要じゃないの？
Batchableジョブでミドルウェアが使える様になってるのってリクエストの時と同じように
そこでバリデーションかけたり前処理できる様にしてあるって思ってたけど
やっぱりコミュニティでもモデルにルール書く人が大半らしい
laravelのOSSかなりみて回ったけど、FormRequest使ってる奴らばかりだったぞ。その話は疑わしいのでソースを提示してくれ。
ユーザーのロールによってバリデーションルール変える必要があった時ってどんな書き方してるのか知りたい
↓
出荷バッチが働き間違った住所のまま伝票に印刷される ※１
↓
間違った住所の伝票が貼られたまま郵便局に持ち込まれる
↓
ご指定の住所に行き当たりませんでしたといって荷物が返ってくる
↓
商品がこないからキャンセルだと客から連絡が来る
おまえらがバリデーションしないせいで月間300件の荷物が返ってくる
1つ送るのに1050円だから1050*300=315000円の損失
そして※1のところで伝票印刷アプリが「取り込みすら無理なデータだけど」ってエラー出すからバッチ処理が止まる
データ修正してバッチを再投入
だが、ほかにも間違ってる住所があるからまたやり直しっていうのを何度も繰り返す
とにかく間違ったデータが入力されてしまうっていうのは損失として大きいんだよ
Laravelで普通にできるだろ
うん？バッチってDBから一覧を抽出するバッチの話なの？バリデーションは何の関係があるの？そんなの登録画面でバリデーションすれば良いだけでしょ？
バリデーションが必要なデータを追加するバッチだよ
それを聞いてとうするんだよ
具体的にて書いたはずなんだが。モデルで書けっていってるやつの主張が意味不明だから。
まず、画面で入力と同じ操作をバッチでもやるって前提が理解できない。
俺の経験上、大体のデータは親子関係にあって、入力する画面は分かれている、バッチだとそれらをまとめて投入するから画面とバッチではバリデーションのルールは異なる。
更に、そんなバッチ自体稀だから、わざわざそのためだけにLaravelの標準を無視してモデルに書くって発想が理解不能。
煽りじゃなくて純粋な疑問
デイリーだとその日が分かればいいだけだし
特殊なバッチのようなものならそもそも管理画面でパラメータ入れて実行やろ
処理の流れからして先にバリデーションするやろ
モデルでするとかそもそも考え方が異常やろ
複数のモデルを使う時、2個目のモデルに投入するまでそこで使うパラメータはエラーが分からんの？w
バカバカし過ぎる
モデルにバリデーションがあるほうがMVCの原則としてはおかしいのだよ。上でも書いたけど、モデルにバリデーションてのは、Active Record由来。
だから、モデルでのバリデーションに違和感持たない人は、Rails以降のなんちゃってMVCフレームワークしか知らないって理解。
どこまで具体的に要るんだ？実際のコード貼れってか？ちょっとそれは今すぐできないんだが
例えば最近やったのでは、1日1回他社がS3に置いたcsvデータを取り込んで、テーブルにレコード追加するバッチ
requiredやuniqueやdateなど普通にバリデーションが必要でバリデーションしたよ
この程度の例も思い付かないなんてどんだけ経験値低いんだよ
経験値ではなくて規模の話だね。そこそこ正規化されたデータしか扱ったことないんで。
あとそれがどれぐらいあんの？画面10あって、そんなのが1、2程度なら、わざわさモデルでバリデーションするようアーキテクチャを変更するのはアホだってことぐらいは、理解してくれるよね？
その辺は一応浅く理解してるけどコントローラーにもリクエストにも書きたくない場合モデルしかなくね？と思った
Cakeでもモデルに書いてたし
他にもっといい場所あったら知りたい
確かにうちは小規模案件が多い、その意味では俺も経験値足りてないが
もちろん不必要な所まで変えなくてもいんじゃね？俺もRequestのバリデーション使うことはある
ただそれだとバッチの時に不便だから、うちではモデルに書いたバリデーションメソッドを、
Webの場合はコントローラー、バッチの場合はコマンドから呼び出すという実装が多い
だから>>257のページみたいにリクエストクラスでやるのがベストプラクティス！と言いきられるとモヤモヤする
みんな可愛い彼女連れて楽しく過ごしてるのにバリデーションごときに熱くなって悲しくならんの？
モデルに入るデータをバリデーションするんじゃなくてS3にあるCSVデータが正しいフォーマットかをバリデーションするんじゃないの？
後laravelしか触ってないからモデルに書く事に違和感があるんじゃなく
laravelがリクエストでバリデーションする機能を提供してるからその方針を尊重してるってだけ
使ってるフレームワークがビューテンプレートに書くって方針ならそうするよ
自分のやりやすいを優先して得られるものなんてないでしょ
間違った住所のままDBに登録される
↓
出荷バッチが働き間違った住所のまま伝票に印刷される ※１
バッチ動く前に「間違った住所のままDBに登録される」って書いてあるけど、そこでバリデーションが必要じゃん
cakePHPはRailsを真似たフレームワークの代表みたいなもんだから、例としては不適切。
バッチもあるやつだけ、モデルにバリデーションを移しているの？それはそれで大変そうな・・・
そうそう、フレームワークの標準にのることが大事。それを無視して俺流をはじめちゃうと、オレオレフレームワークの亜種になってしまう。
その結果、新規に参画するエンジニアや引き継ぐ場合の学習コストが跳ね上がったり、メンテできなくて匙を投げられるみたいなことが起きる。
基本的に面倒くさがりだから独自ルールで書いたらどんなルールかをドキュメントに残さないと引き継げないけど
フレームワークの標準に合わせとけば引き続ぎはフレームワークの作法でやってるのでよろしくで終わる
理解できないって話ならそれは本人の技量であってドキュメントを残してないこっちのせいじゃないって突っぱねられる
バリデーションて言っても厳密には2種類ある
・フォームから送信されたデータのバリデーション
・DBに保存するデータのバリデーション
例を挙げると長くなるので省略する
前者はリクエストで、後者はモデルで担当するのが正解だが
シンプルな要件ではこの2種類が同じになることも多く、その場合はどこに書くか議論の余地が出て来る
スルー耐性つけろ
要は正しいデータ登録できるかできないかって話だよね？
バリデーションの機能そのものの話だよな
有益な話だと思うけど
じゃあそういう時他にどうすればいいの？
そいつに対して他社システムが配置したCSVから読み込んだデータをPOSTしてるな
だからFormRequestは普通にバッチで使えてたな
それぞれでバリデーション書け。理由は、ユースケースが異なるから。結果的に今は同じだからって共通化しようとするのは、経験の浅いエンジニアが犯しやすい過ち。
それLaravelではアンチパターンだよ
あちこちに分散して書くと非常にバグの基になりやすい
それぞれの担当者が別で開発終盤の忙しい時に仕様が変わって片方にしかちゃんと伝わらないとか、超ありがち
それはそれで苦肉の策って感じで嫌だな
絶対駄目でもないけど
特定のケースならバリデーションはいらない、っていうのはむしろ例外だから考慮しなくていい。
勝手にLaravelのアンチパターンとか言い出して何様www
Laravelベースの人気OSSも一通り調べてみたけど、ユースケースごとにバリデーションは分けて定義している。例えば同じuserモデルに対する処理でも、登録と更新ではFormRequestを分けて用意している。
ログインIDが登録可能な3種類のrouteがあったとして
1. /users
2. /manager/users
3. /file/users
1は半角英数10文字まで
2半角英数10文字で先頭にmgr_が必要
3はアップロードされたファイルに書かれている文字半角英数10文字まで
これをどういう形でバリデーション実装するの？
設計が悪いと思わんのかw
バッチ処理のこと何にも考えてないんだろうね
Laravel使ってる奴らやべえな
そんな化石使ってるやつのほうがヤバいからw
バッチ処理でバリデーションとかまじで笑えるwww
お前開発したことないやろ？w
.env.helloとかは問題なく追加できる
これってLaravelの思想としては初期の.envや.env.backupを管理対象にしてないのは
初心者に対する配慮の上でのことですよね？
devenvの仕組み上.env.aとか作れるので自分で管理しろって意味ですよね？
設計が悪い 以上この話はもう終わり
バッチ処理云々言ってるやつは、
まずはバッチ処理そのものについてまずは説明してほしいわ
バリデーション云々の話はまずは置いといて良い
そんなシステムはおかしいのでこの場合のバリデーションを考えるのは時間の無駄です
バッチ処理の意味知らない人初めて見たかもしれない
このURLに説明書いてますよ
https://www.otsuka-shokai.co.jp/words/batch-processing.html
設計ひどすぎてワロタ
それは単純な例だからそういう設計ってことでいんだよな？
まさか実際にリリースしたことのある製品がそういう設計になっているんじゃないよな？
そのリンク先とLaravelのバリデーションとの関係は説明できます？
バリデーションの説明はまだいらないとのことだよ
>>349はバリデーションの話はまず置いておいてバッチ処理について教えてほしいって言ってるんだから
バッチ処理の内部で起きてる話のことで、
それをバッチ処理と相性悪いって言われても意味は伝わらんわな
言い方が悪い
いつ来ても苦笑させられる
こんな設計あるわけないでしょ
routeによってバリデーションの内容が変わるってのを極端に書いただけ
ここまで極端じゃなくとも大なり小なりrouteで変化するルールをどうやって対応するのかが聞きたかっただけ
それからクライアントからの絶対条件だったっ場合
設計がおかしいから変えないなら仕事したくありませんとかって言うわけでもないだろうし
FormRequestに書くって選択肢を許容すればそんなゴネる必要ないのに・・・
バリデーション分けると寿命が減ったりするわけでもないんでしょ？
だからrouteでモデルの解釈が変わるというのが設計が悪いという証拠
モデルに対してwebで出来ること以上の機能を持ったapiは設計が悪いってならない？
一言で済むならプログラマー入りませんよ
頭の悪い無能は引っ込んでおれ
Laravelも他のフレームワークもその辺は割と柔軟にできるように工夫してるでしょ
そしてそれはFormRequestに書くかどうかと全く関係ないぞ、スレを面白くしようとしてるのか知らんが変にややこしくするな
結局否決されてクローズだったな
機能文盲のようなので横から捕捉しておくと、ここで求められているのは、バリデーションを必要とするバッチ処理というものが何なのかって話だよ。
おそらく、それをはっきりさせた後にバリデーションについて語りたいんだろう。
違う 俺が言ってるのはまずはバリデーション抜きでバッチ処理を語ってくれってこと
これくらいも思いつかないのか。。。
俺が機能文盲だったのか。100年ぐらいROMってるわ。
大企業向けワクチン接種の予約した人もここには居ないんだろうな
おれ一応大企業ね。1000人超えてるから。ただし事業部制だから全然実感は無い。
それをバッチ処理という括りで話すのがまずおかしい
おそらく永遠に話が噛み合わない
バッチ処理言ってるのは古いシステムを触ってるおっさん世代と思われる
laravelでバッチってワードが出てくるのなんて
ジョブバッチしかないんだからそれなんじゃないの？
タスクスケジュールを指してるとはとても思えないし
artisanはコマンドだし
何年前の設計思想だよｗ
後学のために教えて欲しいんだが、例えば50万件のデータを毎日DBに投入するときは、どんな設計にすれば良いの？
>>374が毎日手で入れる
すごい！モダンだ。
いろいろな設備や予約を行うためのシステムだけど利用者に関するデータはそもそも他社のアカウント管理サーバがあるからそこを参照しているだけだし
実際の予約情報もまた他社のExchange Web ServicesにアクセスしてデータのCRUDを行うだけ
備品や施設情報もExchange Web Servicesから参照しているだけだし
俺としてはフレームワークでlaravelを選択した際には
リクエストされた値に対してのバリデーションなんだからform requestに書くって自然な流れだと思ったんだけど
modelに書くのが一般的って言うからどう対応してるのかが知りたかったんだよね
そっちのがlaravelの文脈として理にかなってるなら考えを改めて、ウソ教えちゃった人達に謝って訂正しようと思ったから粘着質になってしまった
申し訳ない
他で必要な場合は>>381みたいな方法でも別にいいと思うぞ
でも他のFWみたいにモデルに書く手もあると思うし、何故かそれを認めない輩も一定数いる模様（一人かも知れんが）
Laravelというかphpが低いのかもしれないけど
キャリア1、2年目のエンジニアがバッチ処理必要になった時に、設計したことないって話は聞くけども。
バッチという言葉も知らず実装したこともない初心者無職が、なぜか開き直って偉そうに罵倒してくるスレ
定期処理ならパラメータなんて無いし
（あってもその日時とかやろ）
必要に応じて動かすならフォームからパラメータ入れたりして実行するし
そもそもそういうパターンは管理画面だから非同期にする必要も本来は無いのだけどな
お前はずっとROMでいいよ
へー、最近は数十万件のデータの処理であっても、オンラインでhttpタイムアウトする前に処理終わるんだ？
エンジニアじゃない人はロムっててね
よくあるサブスクのサービスとかで月に一度クレジットカード会社に請求する仕組みとか世にいくらでもあるんだが、君はどうやって実装してるのか知りたい
マッチョな>>391が毎日手動で実行
FormRequest使ってるバカwwwww
1件ずつリアルタイム処理するって話なのに
どうしてリクエスト来るたびに全件処理するバッチ処理を走らせてんの？
そもそも数十万件ならHTTPのタイムアウト60秒だとして間に合うでしょ
1日1回じゃなくて1日中やりつづけたらいいよねって話
そういうの求める人いるけど、怖くて手を出せないわ
大きな会社でもしょっちゅうやらかしてるし
世の中の仕組みが古いよねって話だよ
メガバンクですら夜間バッチからリアルタイム処理に変わったのに
最近のシステムを触ってないでしょ？
どんどんリアルタイムに変わっていってるのに
そもそもサーバにクレジットカードの情報があるようなシステムは違法だぞ
こっちは頼まれた通りに作るだけだよ
例えば、1日ごとの会員の数をCSVなどでダウンロードしたいという要件を実現するとき、
1. 毎日0時時点の会員テーブルのレコード数（や会員の付随属性など）を取得する
2. 1. の結果を集計結果テーブルに挿入する
3. 出力リクエストを受けたら集計結果テーブルをCSVに変換して出力する
俺だったらこんな設計して、 1. と 2. はバッチで作るけど>>391のモダンなやり方だとどんな設計になるの？
あ、ちなみに俺はバリデーションルールをモデルに書くなんて馬鹿なことはしないよ、普通にFormRequestに書くわ。
しかしバッチをLaravelで作るかは微妙だが。
普通にリクエスト受けたらCSV生成してダウンロードさせたらええだけやん
FormRequest使ってるやつってやっぱりガイジしかいねーんだな
そのままCSVで出せばいいだろ
この人(達)わかってて言ってるから相手にしない方がいい
私生活が上手くいってなくてこういう方法でしかストレスの吐き出し方知らない
かわいそうな子だから何言っても意味ないよ
バッチ処理書いたことない人だったか
そうそう。荒らしね。知識なくて話に加われないなら黙ってりゃ良いのにといつも思うわ。
でも、あんまり知識レベルは高くないと感じるから
いくつもやってたら無知が故に画期的なアイデアを書くかもしれない
がんばれ
上位システムでは何かやってるのかもしれないけど
わざわざ「俺の会社ではないな」とか書いてくる奴ってガイジなのか？職場でもそんな感じで会話してるの？
とにかくハブられないために情報量ゼロでも何か発言せずにはいられないんだろう
悲しいね
最初にバッチ処理でFormRequest云々の話をしたのは俺なんだけど
みんながバッチ処理をそもそもしているのかどうかという正直>>379のような話がしたかったんだよ・・・・
正直今の流れは望んでいない・・・
スレ読んでて何故それが未だにわからない？
統計処理としては普通の方式だと思うけど
リクエストあるたびに集計処理が動作するんじゃ重すぎる
バッチ処理ってどれを想定してるかで答え変わるんじゃないかな？
ちなみに俺は6番だと思ってる
1. 時間のかかる処理をする事
2. 非同期で処理をする事
3. 複数の処理をまとめた機能
4. 定期的に行う処理の事
5. コンソールから行う処理の事
6. Batchableジョブの事
いやバッチ処理がいらないシステムも実際存在するし作ったこともあるから必ず必須というのは誤りだけど
実際のところ自分の構築した体感で７、８割りのシステムはバッチ処理が必要なシステムになるね
HTTPリクエスト以外からのlaravel処理起動ってことだ。
バリデーションをHTTPリクエストしか想定してないところに書くのがどうなの？って話になって、例としてバッチはどうするの？って話になって、バッチを知らない馬鹿が騒いでるのが今の流れ。
そいつに対して別システムからもらったCSV等のデータをPOSTしたりとかするようにすれば
FormRequest使えるのでは？
「バッチ」の定義にこだわってわざと話をかき回し続けている もう病気だろこれ
あれ？話がループしてね？
あなたターチは、ヴァカですかー？
俺はわざとやってる人じゃない
ややこしくしようとしてるって感じたなら謝る
書いてもらうまで「HTTPリクエスト以外からのlaravel処理」
が議論の対象だったってのは完全に頭になかった
バリデーションをHTTPリクエストしか想定してないところに書くのがどうなの？
って部分に関してはバリデーションの対象が「リクエスト」なのでFormRequestに書くべきだと思う
FormRequestを使わない処理に対してのバリデーションは必要があるなら処理単位で書くべきと思ってる
繰り返しそう書かれてるのに、スレを読んでてそこに気付かないとか考えられないんだが
案外見落とすもんなのか…？
個人的にはバッチって表現とLaravelのバリデーションを紐づけるのは違和感あるよね
Laravelのドキュメントの中でバッチって使ってたりするか？
バッチって定義はないけど、cursorやchunkメソッド、lazy collectionなんかは大量データを一括で処理するためのものだよね。
laravelはダメなフレームワークです。
でもこんなスレでそう結論付けてはいかん気がする、異常者が集まっている
何回か書いてるんだけどジョブバッチってのがあるのよ
https://readouble.com/laravel/8.x/ja/queues.html#job-batching
それやった段階でルールがどこで使われてるかが追えなくなっちゃうから
のっぴきならない事情でそのルールを変更せざるを得なくなった時に
影響範囲が全くわからなくて予想外の不具合起こしかねないからやりたくないのよね
チーム開発とそんな変更受けちゃダメってのは無しでお願いします
そういう所は嫌い、というか普通にバッドプラクティスだろそれ
その観点だとモデルに書いても同じことが起こると思うし、バリデーションに限らず何かしらのクラスを複数箇所で使ってはならないんじゃないの？
というかバッチ用クラスのテストは書かないの？
サービスって単位での使いまわしはするけど
基本的にクラス単体を複数個所で利用するって事はしてないな
当然共通処理って部分での使いまわしは当然あるけどabstractでやってる
実際に使う場合はサービスプロバイダで必要なインターフェースが実装されたクラスをbindして
コンテナから呼び出して使ってる感じ
このやり方が全くの見当はずれだったりアンチパターンとかだったりしたら早急に修正しなきゃいけないから変だったら言って欲しいのよね
要員の必須スキルが上がって人を集め難くなりそうなんだけど
その仕組みで何人くらいのメンバーで開発してるの？
いつまでやってるんだよ
プロジェクトの規模にもよるけど俺のほかに2人で外部に必要あればちょいちょいって感じ
設計とかインターフェースの部分の開発をやってもらう場合は確かに人が集め難いとは思うけど
どちらかっていうと能力が低くても依頼可能にしたかったからこうしてるんだよね
とはいえメソッドチェーンってなんすか？レベルまではカバーできないけど
.envをコミットするかしないかで延々議論していたころに比べれば健全だろ
・/vendorはコミットする必要がある
・バリデーションルールはモデルに書くべき
・テストを書く必要は無い
・いかなる場合もバッチは必要無い
・jsonは脆弱性があるので使うべきではない
ネタにマジレスして悪いがその処理だと要件満たしてないｗ
cronで60秒ごとにキックして一瞬で終わるような処理と
夜間に数時間にわたって一括で走らせるような処理
この二つを同列に語るのはちょっと違うと思うよ
テスト書かないのだけは駄目だろ
他はわからんでもないが
1は会員登録および退会の時刻を見ればいいだけだから別に0時に処理する必要はない
2はテーブルに持つべき値ではない
3も同様
磁気テープの時代ならともかく、値を取得を得られるまでの期待値が0.1秒未満の今の時代に
なぜバッチ処理をするのか？
レスポンス改善の為にあらかじめCSVを作成して静的に配置しておくっていうならともかく、そういうわけでもないようだし・・・
小さいころ数人でワイワイ砂場で遊んでたら知らない男の子が後から入ってきたからその子も含めてみんなで遊んでると
他の子が作った山とかを壊したり100万円持ってるとか意味わからん嘘ついたりを「やめて」って何回言ってもやる子だったから
またその子が砂場に来た段階でみんなで別の遊具に移動するようになって
誰もいない砂場でごく短時間だけ「楽しいなー」みたいなこと言いながら遊んでた「あの子」を思い出すからやめて・・・
長い上に意味不明で読んで損した
.envをコミットしてるガイジまで居るしとんでもない動物園だこりゃ
他も分からん方が多いわw
頭の中がおじいちゃんなのよ…
あまり責めないで
想定会員数と用途とか情報が足りてないから想定可能なボトルネックは「ある」ものとして設計しなきゃならないと思うから
100万会員/dayで運用開始から現在までって仕様だった場合、どこかで破綻するでしょ
幼児特有の「アレ」な
幼児特有？w
例えば自由に停止再開できる有料サービスを契約している会員数もCSVに載せることになった場合でもそうする？
100万会員/dayの場合OSSのDBで扱えないだろうし言語にPHPを選ばないと思う
100万DAUのサービスならPHP/MySQLのもある、ソシャゲとか結構PHPだし俺も昔モバゲーのゲームをCakeで作った
注射打つ回数に決まってんだろ！
何論点ずらしてるのこの人
だからそれも同じ
出力時に計算してCSVに出せばいいだろ
会員数としか明記されてないので
例えばアプリのインストールやログインとかのレポートなんかを提供するマーケティングツールをイメージした
データはDBのテーブルに保存されるんだからバリデーションはそれに合わせるべきでしょ
ユーザーIDなんかはカラムにユニーク制約付けて、Laravelのバリデーションでcreate時にユニークチェックする
必須項目はNULL不許可にしてバリデーションでrequired
数値はint型のカラムにしてバリデーションでnumericまたはinteger
みたいになるだろ
テーブルに紐付いたり一番近いのはモデルなんだからカラムの属性はモデルにまとめて書くべき
普通fillableまたはguardedを指定すると思うけど同じようにrulesも書いとけばいいんだよ
コントローラーやコマンドはそれを呼び出して使えばいい
DBに投入するデータと入力データはかならずしも一致しない
例えば、パスワードなんてハッシュされてしまう
おかしくないと思うしあってもいいと思うけど
ユーザー属性によってバリデーションルールが変化するサービスの場合はどうするって問題が出てくるでしょ
完全一致する必要はない、むしろ普通は完全一致しない
けどバリデーションされる情報ってだいたいテーブルに紐付く情報だろ、多少の例外はあってもそこは無視できんだろ
そんなのどうにでもなるじゃん
Laravelのバリデーションルールにはいくらでも複雑な条件書けるぞ、足りなければルール自作すればいい
動的に変化する条件も書けるぞ
それ言い出したら、フロントに一番近いとこでやっても変わらんだろ
多少の例外があっても、基本的にフロントから来たデータをバリデーションすんだろ？
そこを議論してもしょうがないんだよ
・フロントから来たデータをバリデーションする
・DBに入るデータをバリデーションする
この考え方の違いか、俺はずっと後者だったから前者の考え方はこのスレの議論で初めて知った
バリデーションは何のために必要か？と言うとDBに不正なデータを渡さないためだから、後者の方がしっくり来るけど
Laravelが提供している標準を無視して、そんなオレオレ実装にこだわる理由がわからん。どうしてもモデルでやりたいなら、cakePHPやRails使えば良いのでは？
それは「なんちゃってMVC」しか知らないからだね。元々MVCは、入力値のチェックをコントローラーの責務としている。
俺はどっちでも良いと思ってるから、その仕組みが提供しているほうに合わせるべきだと思う。それをせずにわざわざ仕組みを変えようとして無駄に工数を使うやつは、仕事ができないやつだと思う。
極論、作るシステムのステークホルダー(エンジニアの除く)にとって、バリデーションがどこで行われているかはそのシステムの価値を決める上で一切関係が無い。
標準を無視してオレオレ実装にこだわっているわけではない。
モデルに書くのも一理あるでしょ？って言ってるだけ。俺だってFormRequestのバリデーションも使うし。
なんちゃってMVCで作ってるのはわかっている。本来のMVCでないとダメなんて思ってないし。
Laravelが提供してる方法ってFormRequestのバリデーションのことだろうけど、
モデルに書いてもあまり手間変わらないよ。
そもそも公式の例ではコントローラーにバリデーション書いてる。その
[
'title' => ['required', 'unique:posts', 'max:255'],
'body' => ['required'],
]
なんかの部分を、モデルに持って行くだけだよ。コントローラーでは
$request->validate(SomeModel::getRules());
のように使う。こうすれば他のコントローラーからも同じように使える。条件によってルールが変わる時は引数で指定する。
バリデーションは入口、エスケープは出口。
どうしてModelみたいな真ん中でバリデーションしようとする？
こんな基本的な事言わんとわからんの？
>極論、作るシステムのステークホルダー(エンジニアの除く)にとって、バリデーションがどこで行われているかはそのシステムの価値を決める上で一切関係が無い。
わかりやすい所に書かれていたり、うまいこと共通化できる所はしてある方が
バグの可能性が減って価値が上がるよ。
真ん中じゃないじゃん。
モデルはデータに紐付くもので、データの入口と考える。
もちろんこれが唯一の正解じゃないから、本来のMVCがとかお前のMVCがどうとかは知らん。
https://speakerdeck.com/twada/php-conference-2016-original?slide=35
これで「出来ていいこと」が明確になる
実際に書いて試した事ないでしょ？
やったらわかるけどartisanコマンドの時にどうすんのこれってなるから
一つにまとめる事がダメって訳じゃないけど分岐していくやり方は
見通し悪くなるってのと分岐が増えると結合度が上がってどんどん変更に弱くなると思ってる
ごめん、頭の悪い子と話すの疲れるんだけどさ、
お前が作ってるの、一体何だ？ バラの部品を複数作ってるのか？
何でアプリ全体で見ないで部品単位で見てるんだよ？
空港降りたら検疫して、駅に入る前に検疫して、電車に乗る前に検疫して、県境越えたら検疫して、電車に乗る前に検疫して、バスに乗る前に検疫して、宿に入る前に検疫して…
なんてやると思うか？ 国に入ってきた時に一回だけだろ。
最初に１回きっちり検疫すればその後、どんなところを通ろうが関係ないだろ。効率って物を考えろよ。
というか、モデルはデータの入り口って、本物のバカなの？
RDBに対してデータを“出力”する場所だろ。だからエスケープが必要になる。
お前マジで、安全なアプリケーションの作り方とか、全く勉強してないだろ？
例えば携帯電話番号の入力フォームでは以下の入力を受け付ける
「09012341234」
「090-1234-1234」
「０９００１２３１２３４」
「０９０−０１２３−１２３４」
DBに格納すれる値は正規化して以下の通り
「09012341234」
って要件を実現するのにどうやってるの？
先に正規化してからバリデーションしてるわけ？
あと、もう一個言うとさ、
おまえのアプリではModelは常に１つなの？
Modelファイルが複数ある場合、どこでバリデーションするって言ってる？
流石に、各Modelでそれぞれバリデーションするとか言わないだろ？
じゃあ、どこ？ 復数のModelの前？
そこはModelじゃなくて、つまりControllerじゃん。
自分で答え書いてるじゃん
ユーザーの入力とDBに格納する形式が違うなら、
先にユーザーの入力値を整形した上でバリデーションしたらいいだけ
心の底から脱力した。
http://blog.64p.org/entry/2013/11/26/131914
『言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。』
そういう事してるから、フロントとサーバーサイドでバリデーションルールが違うみたいな事が発生してくるんだろ。
どこでも同じバリデーションが使えるような実装じゃないと、メンテ大変だろ？
で、この話って元々なんだったんだっけ？
引きこもりは出てくんなよ
１．入力時にJavascriptでチェック
２．フォームがPOSTされるときにバックエンド側でチェック
３．バッチ処理が走るときにチェック
４．ビジネスロジックが走るときにチェック
５．CSVとして出力するときにチェック
少なくとも入力されてからCSVとして出力されるまで5回はチェックされる
なんらかのロジックが走るたびにチェックされるから実際は何十回もする
いやおかしいだろ
そしたらパスワードもハッシュしてからバリデーションすんのか？
バリデーションルールを4つ書いて、saveをオーバーライドして文字列加工でよくない？
まーた頭おかしいの湧いてきたし。
内容に関係ないことで頭に血を上らせて、おまえ、脳に障害でもあんのか？
>>481にコードも書いたからよく見てくれ
俺が提案してるのは、コントローラー（FormRequestでもいいけど）でバリデーションする際、ルールはモデルに書いてあるのを参照するって事だ
Laravel公式のやり方のほんの一箇所変えてるだけなんだよ
その方が使い回しとかメンテしやすくていいじゃない？って言ってる
2と3しかやらないなあ
1はうまいことやればユーザビリティが上がる可能性はあるけど、大抵そこまでやらんな
4と5はよくわからん、出力時にバリデーションてどういうことだ？整形じゃなくて？
バックのバリデーションはシステムの為
おまえ、強迫性障害かなんかなの？
https://fdoc.jp/byouki-scope/features/covd-19_obsessive-compulsive-disorder/
> 出力時にバリデーションてどういうことだ？整形じゃなくて？
そいつ、バリデーションの意味わかってねぇんだろ。
CSV用のフォーマットに変えるって事なら、それ、バリデーションじゃねぇよ。
目視
モデルバリデーション厨はガイジだから触らないほうがいいぞ
システム屋さん以外の人は手動でデータを入れたり更新削除したりしちゃう。怖い怖い
所詮個人の感想じゃん。手間が増えることに変わり無いし、その実装のルールをチームで共有して維持しなくてはならなくなる点は全く考えてないのでは？
なぜそこまでmodelでのバリデーションに拘るのか謎。他のフレームワーク検討したら？
FormRequest厨顔真っ赤で草
システム屋さん以外の人が安く作るとそうはできない
Dependency injection関連のワードが出てこないんだけど
コンストラクタインジェクションを使ってサービスを渡しているけど、状況に応じて使い分けはしてないな
バッチ処理時にバリデーションについてissue挙げてみたら？
過去に出て却下されてるって何度もスレで言及されてるやん
零細と低収入しか居ないしね
大企業向けワクチン接種の枠の人も多分ここには居ない
同じ穴のムジナですな
お前と一緒にしないでくれ
俺は大企業向けワクチン接種の対象だわ
>>371ね。俺と上のやつで少なくとも2人は居るが？
例えば120分の設定だった場合、ログインから60分の時点でページ遷移するとそこから120分非アクティブでセッション破棄されてログアウトされる
これをログインからの時間にすることはできますか
120分の設定でログインから60分の時点でページ遷移してもそこから60分(ログインから120分)非アクティブでセッション破棄されてログアウトされる
というようにしたいです
バージョン書いたら教えてあげるよ
Version6系です
1. Illuminate\Session\Middleware\StartSession を継承するミドルウェアを作る
2. 1. のクラスで handle() をオーバーライドする。中身はとりあえず継承元と全く同じ。
3. 2. にメソッド内の $this->saveSession($request); に注目する。
4. 3. の実行に条件をつける。
5. if (Route::current()->getName() === 'login') { $this->saveSession($request); } みたいな。
6. App\Http\Kernel から \Illuminate\Session\Middleware\StartSession::class を消す
7. 消した箇所に 1. で作ったミドルウェアのクラス名を入れる。
以上
多分動くと思う
動かしてないけど
できましたありがとうございます。
大手で複雑なシステム作ってるほうが技術力あるんだなぁ
なんでわかるんだよ
大手勤務だからというよりは彼が一握りの天才だからだと思う
簡単な仕様をいっただけで構築手順をレスしてくれるとか最高すぎませんか？
さすが大手勤務だ、俺たち零細には真似できねーw
ほんと楽しいわ
どういう書き方をすればいいでしょうか？
初心者ですいませんがどなたか教えて下さい
そもそもその手法が間違ってると思った方が良いかもね
自分自身であるthisをviewに渡せばview側でcontrollerのメソッドを実行可能です
確かにcontroller毎viewに渡したらview側でcontrollerのメソッドを実行できました。
教えていただきありがとうございました。
それはMVCとかけ離れてるので設計がおかしいです
その呼びたいメソッドがviewの仕事をしているんじゃないですか？
ちゃんと見直してください
viewのメソッドにできないか考えてみます
教えていただきありがとうございました
もっとうまく成り済ませよ
突然Laravelスレでなんで敬語の話を？
このスレの零細起業の連中とは格が違うね
特定のページだけCSRF対策をする方法はあるのでしょうか？
これに対してのやり方が
>>533
って流れって釣りだよな？
この質問って120分で強制ログアウトさせたいって話だよね？
セッションでどうにかしようとしてる時点で解答ありきの質問じゃね？
まあ大芋勤務してるとベストプラクティスなのかもしれんが
自分が大手で働いてるのを自演までして自慢するのはさすがに草
俺はそんな面倒なやり方しないけど
ではどのように実装するかご高説願おうじゃないか
セッションなんか使用せずDBにログイン時間を保存しておけばいいだろ
大手勤務君、名無しでイライラしながらレスしてて草
basic認証でログインするならあるかもしれないが
俺もこっちが単純で分かりやすい気がするわ
わざわざkernel書き換えるとか大袈裟なんだよね
やめたれｗ
謎の名無し「セッション使わないでDBにログイン時間保存すればいいだけ」
この差よ…
この方法もミドルウェア作ってカーネルへの登録も必要じゃね？
rootMiddlewareに追加しないで
controllerかrouteでやるって事でしょ
だとしたら、大手くんの大勝利じゃん
コントローラーで認証チェックはちょっと遅すぎるかな…
ルートだとセッション始まってないからユーザーIDの特定無理じゃない？
認証用ミドルウェアってこんな感じの実装だと思うんだけど
作ったやつの部分に例のミドルウェアを入れとくイメージ
Route::group(['middleware' => ['auth:sanctum', 'verified','作ったやつ'] ],function (Router $router ){
$router->get('users' , 'コントローラー' )->name('users');
}) ;
webのミドルウェアグループは読み込んでる前提ね
rootMiddlewareって何だ
routeMiddlewareのこと？
あ。。。ごめん普通に
間違えてたrouteMiddleware
この間違いはあかんね
そもそもなぜKernel書き換えたくないのか知らんけど
別に>>574ここでKernelに〜って言いだしたの俺じゃないんだけどね
でもサービスとして分離する事考えるとサービスプロバイダでaliasの登録するか
['auth:sanctum', 'verified',\Package\Name\Middleware\作ったヤツ::class]
的なやり方しちゃう事が多いかも
案件次第
一定時間毎にログアウトさせて途中の作業パアにしてくれるクソシステムあるけどあれお前らが作ってんのか
根拠ゼロで草
それはさすがに知らねーよ
大手勤務の俺が120分でログアウトする仕組みで無双した件的なラノベの矛盾点が論点なんだから
どうせ大してアクセスのないサイトだろ
的外れなことばっかり言う
大手だの零細以前にまず働いてんのか？
残り半分は趣味とかやろな
ロードバランサ使ったりAWSで複数インスタンス使ってるような構成だとDBでセッション管理してると思う
だから今回のような疑問が出てくる時点でおそらくシステム構成を理解できてない
もしくは既存システムをいじりたくないのであれば別途監視アプリを作って常駐させる
C言語使えるならこっちのほうが楽かもね
独自FW作るのはLaravel以前からやってる案件
cakeの頃に独自FW作るのが流行った
codeigniterに皮かぶせて独自FWっていってるのもあったな
とにかく一世代前の話
昔からやってる人は慣れてる独自FWで揃えたいっていうのもあるだろう
会社として複数FWを利用すると教育コストがかかっちゃうから一度採用したFWは変えられないという都合もある
ただ、新陳代謝が一巡してるであろう今の時期になってもまだ独自FWのままっていうのは
特殊な事情があるのか、もしくは開発者が入れ替わってない（高齢化）のか、もしくは開発者のレベルが低すぎて
言われたままやる人しかおらずもはやFW入れ替えなんていうことをするパワーがないのだろう
独自FWっていうのは下請け企業が他社に仕事を取られない為の難読化テクニックの一つ
DBってリレーショナルDBのことか？
そんなとこでセッション管理しないだろ
今までの現場はほぼRedisだわ
どっちでもいいんちゃう？
DBでも大して遅くはならんやろ
インフラ設計したことある？IaaSとかで売上の立たない業務システム作るときは、月額のインフラコスト少しでも減らしたいからKVSじゃなくてDB使うケースはありえるでしょ。
わざわざセッションドライバやキャッシュドライバにDBが用意されているのはなぜか考えような。
ロードバランサで負荷分散が必要になる規模だとRDBでセッション管理するのは非効率極まりないね
↓
＞ IaaSとかで売上の立たない業務システム作るときは、月額のインフラコスト少しでも減らしたいからKVSじゃなくてDB使うケースはありえるでしょ。
いやさすがに別人だろ…
同一人物だったら笑うが、ワッチョイ無いのが悔やまれるな
自前FWでドキュメントもある所もあった。自前FWを作ったコストを相殺できるくらいには各種案件に使おうとしてるようだった
独自FWだと下請けに出すときに困るんだよ
というか出された下請けが困る
つまりワイが困る
パブリックなFWだと案件のほうをあわせるしかない
しかし、独自FWだとFWを案件にあわせていく
案件の数だけ枝がわかれた独自FWなんてただの悪夢だ
誰もレスポンス速度のこと言ってないよ
安いRedisを使うか高いRDBを使うか、コストの話だよ
何が言いたいのか詳しく。ちなみに>>606は俺じゃないけどな。
セッション用にNOSQLを使う場合もあるだろう
細かい条件を決めてベストを尽くすのがおまえらの仕事
ここで何も聞かずにベストプラクティスが決まるようならおまえらの仕事は不要だよ
予算ないならRDBMS1台とロードバランサー1台、インスタンス1台の構成で
アクセス増えてきたら動的にインスタンス起動ってところじゃないのかな
本当に金かけたくないならインスタンス1台に全盛りでスケーラビリティなしだ
業務システムだと負荷は無くても落としたらしばかれるからそういう構成になる。まぁ零細だと多少落ちてもそんなもんだって許されるのかもしれないが。
独自FWの場合、composerは使わない
独自FWのメリットはソースコードを非公開にできることが大きい
公開することによって脆弱性が見つかる場合もあるから
まあ非独自にしたって100%解決はせんけど
OSSの思想と真逆のアプローチをとるんだな
公開して皆で脆弱性を見つけて修正できるという思想、
非公開にすれば脆弱性を見つけるのが難しくなるという思想。
日本らしいといえば日本らしいな。
案件ごとに独自進化する地獄を見せつけてやりたい
案件バージョンとFWバージョンのグリッドを見て涙するがいい
それ言うほど問題か？SQLインジェクションなんて真っ先に対策するじゃん
XSSとかCSRFとかある程度の脆弱性対策してから開発するだろ
日本人「OSSにすれば脆弱性が見つかる」
その対策がガバガバだったらどうするの？
そんなレベルのやつはOSSフレームワーク使っても脆弱なシステムしか作れんよ
根っこが理解できてないんだから
そういうことではなくて、独自だろうが何だろうが、外に出す以上は一定の脅威に晒されることに変わりがなく、コードから脆弱性を見つけられないという点は何ら安全を保証するものでもないし、公開しているFWより安全であることの証明にもならないって指摘。
見知らぬ奴がわざわざお問合せフォームから連絡してきたっけ
当時は不正アクセス防止法とかないから、攻撃しようと思えばできたろうけど
単に教えてくるって良いやつだったんだな
一般的な会社は画面に「データを返してほしかったらビットコインをよこせ（意訳）」って表示されてから対策をはじめるんだよ
さすがにそれは違うだろ
少なくともオレオレFWで作るよりははるかに安全
海外の有名FWと公開したところで誰も使わないであろう弊社FWを比較するのはちょっと違和感を感じる
githubを巡回してるロボいるよな
あれAWS社は有名だけどあとはどこが巡回してるんだ
え、お前の会社が日本の標準なの？
社名に日本って入ってるし
あーこの部分をこうしてるんだーってFW制作者の工夫が分かるようになる。
そんでもってやっぱSymfonyとCakeは勉強になるチューニングしてあって評価の高さも納得できる。
オフィシャルサイトは良さげなのに
cakeとの比較だと
・認証周りの機能があらかじめ用意されている
・テンプレートエンジンがあらかじめ用意されている
・フロントエンド周りの環境構築が楽ちん
・ファーストパーティとサードパーティに豊富な拡張パッケージが用意されている
・クリーンアーキテクチャ的な拡張がしやすい
・redisなどの外部システムとの連携の設定が簡単
ぐらいかな。
ご丁寧にありがとうございます。
Symfonyと比べるとどのような点が使いやすいですか？
ほとんどCakeにも用意されてないか？
どうした大手勤務君
自分が答えられない質問に他の人が答えているのを見て嫉妬しちゃったの？
色々用意されていて自由度もそれなりにあるLaravelを使うと他のフレームワークを使う気になれなくなる
homesteadとか環境面も色々あるし便利だなと
個人的な感想だけどね
そうなの？なら>>651のうちcakePHPでも十分同等と言える点はどれ？
Cakeは一般ユーザーとadminを認証し分けるのや別のテンプレートエンジン入れたりするのが面倒臭かった
誰かが作ったプラグインも色々あったがメンテされなくなったら終わりだし
きみ、相変わらずキモいね
bladeは使っていて違和感を覚えるので変えたいです
違う
バッチ処理が必要なアプリ→モデルでバリデーションがベストプラクティス
バッチ処理が必要ないアプリ→FormRequestでバリデーションがベストプラクティス
アプリの構成によってベストプラクティスが変わるという結論だよ
プロジェクト直下にartisanというファイルがありこれを使ってコントローラ生成したりなど色々行うと思います。
本番環境にアプリを配置する場合このartisanというファイルは削除したほうがいいのでしょうか？
WEBブラウザからartisanファイルが実行されて変なことにならないか心配しています
そんなレベルでLaravel使うことのほうが心配だよ
そのコマンドを実行すると開発にしか使わないようなライブラリや開発専用コマンドなどのファイルを
自動削除してくれていたので今まで気にしたことはありませんでした。
laravelだとそのようなコマンドがないようだったので本番リリース時にどこまで削除すればいいのか
わからなくなって質問させていただきました。
実際WEBサーバの脆弱性ついたらドキュメントルートより上にアクセスして実行できるのかな？
なんか一覧を表示する速度が遅いなって思ってたら数年ぶりにN+1を発生させてしまっていたぜ
N+1なんて回避して当然だから自分やらかしていることに気付かず調べてから判明するまで６時間費やした
どちらを使うのが一般的なんですか？
動作が違うので必要な場面で必要な方を使うのが一般的です
複数行が対象とかで無い限りupdate()使ったりしない気がする
作ってる奴がアホなんだろうなぁ…。
ワケワカランてどういうところがそう思ったのか気になるなー。
$user->fill($request->validated())->save()
というような感じで使えばいいですか？
その使い方だとupdateでも同じでしょ？
自分はfillした後に何か処理挟むならsave、挟まないならupdateって使い分けしてる
あとコントローラー内限定だよね？その書き方
>>683
「updateでも同じ」って部分を言ってるなら多分勘違いしてるぞ
はぁ？ 場所によって書き方変わんの？
相変わらず、ワケワカラン実装してんなぁ…。
作ってる奴がアホなんだろうなぁ…。
お前はせめてPHP初心者卒業してからコメントしろよ
アホなんだからｗ
横だけど、requestオブジェクトからバリデートした値だけを受け取っている部分があるから、controller限定かどうか尋ねてるってことでしょ。Laravelのこと知らないなら黙ってたほうがいいよ。どうせお前bigintおじさんでしょ？
あえてsaveを使う理由はない
そうなんだよね、結局updateの中身だってfillしてsaveしてるだけだから
あえて->save()分のコード量増やす意味ないと思う
それよりも震えるのはプロパティに値セットしてsaveしてる人ら
何故？ｗ
そっちが普通やろ
fill()とか常に使っている方が頭おかしい
前提としてfillableかguardedをModelに設定してるよね
その値って更新可能なカラム名って感じがするけど
そうじゃなくてcreateとかupdateとかfillの引数で入力される連想配列が保存可能なカラムを定義してるのよ
なのでfillとかを使わないでセットした値はその影響を受けないのね
例えば更新なんかしちゃダメなprimaryKeyの値とかも変更可能なの
$user->id = 10 ;
$user->save();
ここまで書いたら分かると思うけど
こういう実装方法って重大なセキュリティホールの要因になりえるので
気を付けようねって意味を含めて「震える」って書いたの
別に俺はプロパティでセットしてsave呼び出してるからと言って頭おかしいとは思わんよ
上に書いた理由を知らなかったってだけだと思うし
実際、俺も使い始めの時プロパティにセットする実装してたから
こういった理由を知った上でそれでもプロパティで実装する方法を選択してるなら頭おかしいって思っちゃうかな
$user->id = 10 ;
なんて誰が書くの？君の同僚？
申し訳ない、俺の例がわかりにくかったみたいだね
こんな例が考えられるけどどうかな？
たとえば悪意のあるユーザーがリクエストでis_adminパラメータを送信して
そのパラメーターがモデルのcreateメソッドに渡されてユーザーが自分自身を管理者に格上げする
みたいなケースが考えられるでしょ？
あと、少し慣れてくるとプロパティにセットする事が手間になってきて
foreachで回して値をセットしたりしがち
そうなると完全にやばいよね
すまん、俺はそんな場面に出くわしたことないが、君の職場ではしがちなのかい？
そもそもマスアサインメント知らないLaravel初心者にそんな具体的な説明しても無駄では？
$user = User::find($request['id']);
とはやっても
$user->idの値を書き換えるとかちょっとあり得ん
アホなの？
予約語ってis_adminの事言ってるよね
https://readouble.com/laravel/8.x/en/eloquent.html#mass-assignment
https://readouble.com/laravel/8.x/jp/eloquent.html#mass-assignment
ここ読んでみたらわかると思う、君が書き込みをするべきなのは
https://github.com/laravel/framework/issues
こっちだと思うよ
リンクおかしいな
https://readouble.com/laravel/8.x/ja/eloquent.html#mass-assignment
idって基本的にauto_increment入れる為のものだから
$user = User::find($request['id']);
とはやっても
$user->idの値を書き換えるとかちょっとあり得ん
アホだ
アホは書き込み禁止
どんな時でも使うべきだぞ。じゃないとリクエストからモデルに渡してよいフィールドが、コントローラー側で決定されるメソッドが生まれてしまうぞ。
要は反知性主義なんだよね。真面目に科学的に考える奴のことを軽視している。
これって地動説否定とかトランプ支持者など外国でも見られた傾向だけど、日本は特にひどいね。教育が悪いんだろうか。
質問を質問で返すなよ お砂糖が知れるぞ
コイツが1番偉そうっていうね。
fillを必ず使え代入は危ないって言ってる人は、fillableじゃない値をどうやって入れるの？
できない訳ないじゃない
自分が知らないから無いだろうって決めつけると恥晒すよ
https://laravel.com/api/8.x/Illuminate/Database/Eloquent/Model.html#method_forceFill
いやforceFillというメソッドは分かるよ。
それを使えば解決するよって回答でいいのかな？
まず何を解決したいのかな？
それを聞かないで全て解決するなんて事は言えない
できれば具体例上げて欲しい
状況によって使うメソッドや方法も変えてるから
質問しといて申し訳ないけど
俺もfill使ってない事思い出したわ、すまんな
プロパティに入れてfillableガン無視で最後saveしてる人だったって事にしといてください
ここで言い争いしてコスト使うのが1番頭おかしいってふと気付いたわ
N+1って有名な問題だからFW設計時にそれを強制的にFW側で回避するようにできなかったのかな
いまだとwithとか明示的に使わないと回避できないよね？
いや別に喧嘩腰になったつもりは無くて、単なる興味から聞きたかっただけなんだけどな。
答えたくないなら残念。
>>721
例を挙げるならユーザーのパスワードのセットする時とかだね。
CodeIgniter4はFW側で回避してるぞ
そうなんですか？となるとやっぱりFWを使う人側で回避しないといけないというわけですね
だからfillableじゃない値はforceFill使えよ
プロパティに直接セットするとか素人ですら珍しいぞ
その実装をできた人は世界中で表彰されるだろうと言われるぐらい難しいことなんです
なるほど、>>723さんと同じ人か分からないですがありがとうございます。
例えばですが
$user->password = $hashedPassword;
$user->last_password_changed = $now;
$user->fill(request()->all())->save();
こんなコードを書きたい時は
$user->fill(request()->all());
->forcefill([
'password' => $hashedPassword,
'last_password_changed' => $now
]);
->save();
こうしたほうが良いってことですよね？
必ず fill を通す必要がある理由が前述の
「例えば更新なんかしちゃダメなprimaryKeyの値とかも変更可能なの」
「こういう実装方法って重大なセキュリティホールの要因になりえるので」
という理由だと思ってたんですが、forceFill 使っちゃうと id とか変更しちゃダメな値を更新しかねないという点でやはり一緒ではないですか？
この理由だと forceFill も使うべきではないと思ったんですが、実は forceFill を使うとこの問題を克服できるのでしょうか？
他の用途では使わないほうがいい気がする
laravelは入門程度だから実際に業務で使っている人の意見聞きたいな
理解する気が無い人なのかと思ったので諦めてしまいました、ごめんなさい
パスワードとかfillableに含めない項目って基本的に含めない方がいい理由があると思うんですね
その「含めない方がいい理由」ってのは独立した機能として切り出して通常の流れから切り離す必要があると思うんです
特にパスワードに関しては更新後にメール送ったり仮パスワード発行するとか周辺機能も多くなりがちなので
機能として切り出してコントローラではない所で更新した方が良いと考えています
書いていただいた処理の流れでパスワードを更新するのであれば
fillableに含めない事で得られる効果(複数代入で更新されない)の意味がなくなってしまっているように感じます
forceFillで更新したら一緒だよねって問題に関してはご指摘の通り一緒です
ですが、機能として切り出されていればテスト時に更新すべきでない項目を更新していることを見つけることができますし
責任範囲が明確になってメンテナンスコストが抑えられると考えています
例えばlaravelのパスワード更新はこの様にforceFillで更新しています
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Auth/SessionGuard.php#L662
こちらはメール認証でemail_verified_atカラムを更新しています
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Auth/MustVerifyEmail.php#L24
読み返してみたのですが
> コントローラではない所で更新
この表現は適切じゃなかったですね
> 独立した処理として更新
が適切かもしれません
マジで？それはドキュメントのどこに書いてあるの？
マニュアルにはないかもしれないけど
この辺じゃないかな？
https://twitter.com/taylorotwell/status/1395087054254526474?s=21
https://github.com/laravel/framework/pull/37363
https://twitter.com/5chan_nel (5ch newer account)
すでに上で出てるけど、こっちの方が分かりやすいかな。
https://laravel-news.com/disable-eloquent-lazy-loading-during-development
https://laravel.com/docs/8.x/eloquent-relationships#preventing-lazy-loading
速攻論破されて草 >>738-740の内容知らなかったのかな？
FW側で回避できるという証明にはならない
いや、別に論破とかどうでも良いんだが。N+1の実装したら例外出て便利になったっていう情報知らないぽいから教えてあげたかっただけ。
あとFW側で回避したいなら、modelのwithプロパティ使っとけば確実だと思うけどね。ただこれ使うと余計なテーブルアクセス増えてしまいがちだから、不要な時はwithoutとかのメソッド入れなきゃダメで、それはそれでだるい。
Laravel使っててモハメドの話聞いてないとかありえないぞ
https://youtu.be/213aEudaumk
エロなんたらがActiveRecord型だからっつう事か？
アホな事やってんなぁ…。
ActiveRecord型はJOINが表現しずらいから使わんのよね。
無駄な努力をご苦労さん。
特に初心者にとっては記述する動機になりづらく成長の阻害要因
JOINで書くよりN+1で書いたほうが表現がスマートなのが問題なんだよ
ここ数日初めてこのスレで勉強になった
生のSQLでjson使って書くって事？
そしたらLaravelでもハマる奴らも続出していたんだな
たしかにFWがうまくやってくれるもんだと思ってたらそこまで考えない
SQLを作るための仕組みっていうのを知ってたら中間出力であるSQLはどうなってるのか気になるんだろうけど
意識しなくて済むような仕組みだからね
DataMapper型でクエリビルディングして書くって事
正直、Railsで失敗してんのに敢えてActiveRecord型を選ぶとか、頭おかしいとしか思えん。
だからプライマリキーはidのオートインクリメントです、
復号プライマリキーは設定できません、みたいなトチ狂った設計になっちゃうんだよ。
10年以上、全く成長しないよな世間の奴らって。
753nobodyさん2021/06/21(月) 11:37:18.75ID:???
あとjoinガーて言ってる人、雑魚はinner joinとouter joinを使い分けられないという点に気づいていないと思う。
DaoもActiveRecordも同じ『JOINがたマトモに表現出来ません』問題で失敗してんのに、
なんで敢えてActiveRecord型選んじゃうっすか？ｗｗｗ
学習しましょうよ、せんぱーいｗ
747nobodyさん2021/06/21(月) 10:19:15.52ID:???
近頃のFWはだいたいがActiveRecord型だし、特に無駄な努力なんてしてないけどな？DataMapper型しか使ったことないアンチオートインクリメントおじさんは、いつまでLaravelスレで粘着するのかね？
そういえば前に、ActiveRecord自体知らなくて、1テーブル1モデルなんてありえねーとか言ってた恥ずかしい奴がいたな。
何言ってんだろうね、このバカは相変わらず。
じゃ、他のORMに比べて、他にどんなメリットがある？
お前、マジでActiveRecordしか知らないんじゃん。
ってか、『1テーブル1モデル』って、なんすか？ｗｗｗ
もしかして『1テーブル1クラス』の間違いっすか？ｗｗｗ
>>937
人の話聞いてんのかな？ ModelはDBにアクセスする物じゃねぇんだから、
Modelとテーブルが１対１なわけねーーーーーーーだらーーーーーーーーーー！
937nobodyさん2021/05/23(日) 18:01:50.48ID:???
他のテーブルとのjoin操作までModelに入れるのはなんか違う気がするんだけどその辺どうしてるの？
何いってんだこのノータリンは…。日本語読めないのか…orz
それを『1テーブル1モデルなんてありえねー』って読むのか、バカって。
「１つのモデルで取り扱うのが１テーブルだけだなんてあり得ない」って書いてあるんだぞ？
なんでテーブルが主語になってんだよ？
脳みそ腐りすぎだろ、かんべんしてくれよ。
というか、937が
「他のテーブルとのjoin操作までModelに入れるのは」
って言ってんだぞ、そっちをつっこめよ。
そのバカ、『Model=DBにアクセスする場所』って思ってるって事だぞ？
なわけねぇだろ。
お前らって、本当にプロのエンジニアなの？ 素人だろ？
はいはい、凄い凄い。
テンプレエンジンが独自Bladeです、の時点で『マジか！？』と思って避けてたけど、
Railsと同じ失敗するとか、２度めの『マジか！？』だな。
ほんと、学習しねぇよなぁ…。
> わざわざDataMapper型に触れておいたのにこれだもんなぁ。
聞かれた事に答えずに遁走っと。
尋問内容：
じゃ、他のORMに比べて、他にどんなメリットがある？
お前、マジでActiveRecordしか知らないんじゃん。
お前ら、マジで、いつまでおんなじ所ぐるぐる回ってんだよって話。
751nobodyさん2021/06/21(月) 11:30:35.35ID:???
ベテランRailsエンジニアたちがN＋1でハマってるのみて何をもがいているのか不明だった
そしたらLaravelでもハマる奴らも続出していたんだな
取って出しの簡単な物しか作ってないって事なんだよな。
業務システムみたいに復数テーブルと都合させて〜みたいな処理はやらない。
そういうのしかやった事ない奴がLaravelまんせーしてる。
まぁ、そういう簡単な用途ならいいんじゃねぇの？
“複数テーブル突合させて〜”。
DataMapperがとかActiveRecordがどうのとかそういうのは個人の趣味趣向だから好きにしてって思うんだけど
laravelで使う上で色々なライブラリやFW自体がeloquentを使う前提で作られてるのに
それを外してまで他の仕組み導入するメリットってあるのかな？
その証拠に規模や用途の話が全く出てきてないよね？
全てのプロジェクトに対してのベストプラクティスが一つならどっちがいいなんて議論にならないはずよね
これが不具合というわけでもないんだし
クエリビルダ知らんってのもどっから出てきたんだよって話しだし、
あったらなんだよ、それで解決すんのか？、って話しだし、
アホ過ぎて頭痛くなってくる。
こういう馬鹿って、来月あたりにN+1にどっ嵌って頭かかえてそうな馬鹿さがある。
> その証拠に規模や用途の話が全く出てきてないよね？
どこに？ 主語ちゃんと話そうぜ？
中規模以上のプロジェクトだとeloquent禁止して、クエリビルダで開発してたりする。まぁ、Laravel使わないのにこのスレに居座る構ってちゃんには関係無い話か。
禁止w
マジで、何やってんのあなた達w
チーム開発において、好き勝手な実装を認めるわけには行かないってのは理解できるかい？
お前、アーキテクチャ設計とかチーム内の規約とか作った経験無いでしょ？
どうしてそうなっちゃう？
論点ずれまくりだって事くらいは分かろうな？
わざわざ失敗したActiveRecordが実装されているFWを採用している時点で何も考えていないアホなのが丸わかり
実際の業務では複合主キーや複数テーブルなどの操作は当たり前だからな
それらをサポートしていないLaravelのようなFWを業務で使うことはない
マイグレーションでは複合主キーできるよね
ズレてるのはお前。そもそもLaravel使ったことないくせに、なぜこのスレに居るんだい？
おー、恒例の論点ずらしっすか。
じゃ、敢えて乗ってやると、
ちまたの皆さまがまんせーするLaravelとやらが、どれほど成長したのか見て差し上げようと思って覗いてみたら、
『まだそんな事やってたんすか！！！！』という驚きと共に、
まんせーし続ける皆様を観察して正気なのか確かめる為です。
こんな感じで宜しいでしょうか？
つまり構ってちゃんてことかwww
逆じゃない？アプリ中心ならクエリビルダ、DB中心ならEloquentだと思う
それともbigint知らないでintでオートインクリメントしてたのかな？
ActiveRecord採用すると、DBの設計がアプリケーションに引きづられるって昔から指摘されてるよ。構ってちゃんが指摘する通り、複合キーも使えずサロゲートキー前提の実装になるしね。
多分そいつは何も知らないだけやと思う
約900京まで扱える
世界の人口は78億人
どうやって枯渇したんだ？
オートインクリメント君はbigint枯渇させてからオートインクリメントは危険と思うようになったらしいですよ
速攻で否定されるアホw
あなたたち、一体何してるんすか？www
これがLaravelerの実態
2. 有限な値をプライマリキーにするのはおかしい
こう言ったのを、
Laravelerは頭がおかしすぎるので足して2で割ってしまい、
『bigintを枯渇させた』という、謎ワードを勝手に作り出して興奮している。
本当に頭悪過ぎ。だから2021年にもなってN+1問題みたいな下等な事でワイワイやっている。
成長というものがかけらも見られない下等な人種の集まり。
N+1問題って、『N isennizyuu 1 問題』だったんだ、
ちょーうけるwww
で？ 聞かれた事に答えないからもう一回聞くけど、
それ、併用できないんすか？www
マジでその質問いる？趣味でしか開発したことないの？チーム開発で規約作ったことないの？てか、「なぜ」についてもすでに回答しているよ。日本語読めないのかい？アンチオートインおじさんは。
オートイン→オートインクリメント
これがLaravelerの実態
っていう話と、DBのintが何ビットかっていう話がごっちゃになってないか？
あと、有限なキーがダメって話が出てるけど
有限ではないキーなんて存在するんだろうか？
あとDBにはintは実装されてるけど使う人なんていなくて
実際はDECIMAL(NUMERIC)を使うでしょ
DBでもint使うが？
補足すると、アンチオートイクリメントおじさんは、オートインクリメントだと有限な値を使うことになるからダメだってアホな主張をしてて、それで、は？bigintなら問題ないでしょて突っ込まれて、そのあと920京はunsignedだからプログラムで読めない！とか言って失笑を買ってた。
なんか、壊れたレコードみたいになってきたなｗ
で？ 聞かれた事に答えないからもう一回聞くけど、
それ、併用できないんすか？www
答えると、なんか都合悪いんスカ？ｗ
>PHPのintは64bit（64bit環境かつPHP7以降）
>っていう話と、DBのintが何ビットかっていう話がごっちゃになってないか？
うん、お前らがね。
>あとDBにはintは実装されてるけど使う人なんていなくて
>実際はDECIMAL(NUMERIC)を使うでしょ
また、謎の言葉を吐き出したしｗ
Laravelerって、ここまで頭おかしいんだｗ
すでに回答済みって書いてるから、一定の知性がある生物ならログ確認すると思うよ？それともお前にはそういった知性は期待できないので、もう一度回答したレス番を示してあげた方が良いってことかな？
>すでに回答済みって書いてるから
そういう問題じゃないって事すらわからないんだ。
よっぽど自分の頭の中だけで生きてる引きこもりなんだろうな。
で？ 聞かれた事に答えないからもう一回聞くけど、
それ、併用できないんすか？www
答えると、なんか都合悪いんスカ？ｗ
>あと、有限なキーがダメって話が出てるけど
>有限ではないキーなんて存在するんだろうか？
これについての返答、SQL書いてるからかなんなのか、ブロックされるな。
あのさ、VARCHAR(8)ですら、ユニーク数、幾つか計算できるか？ほぼ、出来ねぇんじゃねぇか？
『併用できないんすか？』って聞かれてるんだから出来るか出来ないか、答えりゃいいじゃん。
バカだよなぁ…。
会話にならねぇ。アンチオートイクリメントおじさんとの会話は俺には無理だわ。じゃーな。
・必要十分か不足する可能性はあるか
これは別の問題だと思うんだよね
サービスの要件として日本人を対象とした日本語のサービスであれば目安となるのは1億2000万
これをベースに再作成や複数ID、出生率などを勘案していけばいい
日本人を対象とした商用サービスで最大レベルのものといえば電話だと思うけど
電話番号は11桁
つまり、0〜9の値をとる11桁があれば日本人相手のサービスとしては十分なんだ
人類は有限であるからIDは無限である必要はない
おまえらがいきなり子づくりに目覚めて出生率が跳ね上がる見込みもない
システムの寿命、Laravelの寿命を考えると宇宙の歴史規模の余裕を持つ必要もない
つまり、11桁の数を持ち得る手法であれば必要十分なんだ
重複しないことをDBMSが保証してくれる上にパフォーマンスもよい
よく自動採番の欠点として例示されるのがマスタ画面で新規登録する際
登録時に採番した番号を表示できない、表示したらキャンセルした場合に欠番が出るなんて言うけど
エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ
ただ、データベースの常識として余計なデータは不要だという事
主キー足りえる列がすでにあるのにさらにID列を設ける
これはバッドだ
氏名＋電話番号で主キーとして足るのであれば新たにID列を増やすのはパフォーマンスを落とすだけの行為でしかない
（ただ実運用上で主キーを見抜くのは並大抵ではない。例示した氏名＋電話番号が通用する場面があったとしても特殊な例外だろう）
ID列を追加するという行為は無駄な領域を確保するという事
検索速度に寄与するわけでもない主キーを追加することによってHDDの余計な領域を確保してしまう
またサーチする際のシークエンス速度もその分劣化してしまう
IDなんてせいぜい8バイトかもしれない
8バイトが1億件あったとしても8億バイトだ
RAID6構成だとしてもたった16億バイト分の領域が無駄になるだけだ
しかし、それを詰めてほんの少しのパフォーマンスアップでももくろむのが我々技術者の使命ではないだろうか
最後になったが主キーの例示でまともな例を出せなかったことをお詫びしておく
連番だとIDで登録順がバレる、予測が簡単だから攻撃されやすいなどのデメリットがある
> 最後になったが主キーの例示でまともな例を出せなかったことをお詫びしておく
わろたｗ
おまえ、これ書きたかっただけだろ
そんな理由でも良いじゃない
またかよ。いつものキモいやつ
いや初めてなんだけど CodeIgniterと比べると遅い気がする
まともなエンジニアなら計測して検証した上で人に聞くんだよ
お前からは話題ループさせて喜ぶキモいやつの匂いしかしない
LaravelとCodeIgniterを比べて遅いだったらそれはDBが遅いんじゃなくてアプリが遅いんじゃないのか？
とりあえず出力されてるSQLをExplainして比べてみろよ
そもそもベンチマークとってんのか？
気がするじゃなくて具体的な数字で出せよ
例えば「巨乳入店しました」でEカップだったらがっかりするだろ？
でも「Eカップ入店しました」でEカップだったらOKなんだよ
そういうところがIT業界では大事なんだから覚えておけよ
それがおもしろいんだろ
プログラマの楽しみをちゃんと味わえよ？
DBから情報を取得する部分の速度を計ってみました。
CodeIgniterは約0.1秒、Laravelは約0.7秒でした
どちらの1秒以内なので誤差と考えていいですかね？
Laravelは単純にDBから情報取得するだけでも色々な処理が動作するので遅くなる
なぜ素人みたいな実装を推奨してるんだ？
やめたれｗ ここの連中素人で業務システムの構築経験とかないだろうから
あなたの言っていることは理解できない内容だと思うぞw
同じ内容を取得してその差が出てるんだったらさすがに計測ミスじゃないの？
DBへの接続と切断で50m秒ぐらいだろうからCIは残り50m秒で他の処理したってことだよね
同じくLaravelは650m秒
CIはそんなもんだと思うからLaravelはどこでそんなに時間かかってるか切り分けたほうがいいんじゃないか？
経験的に時間がかかるのはDBレスポンス、結果の受け取り、結果の出力の3か所
それぞれ計測すればネックになってる箇所がわかると思う
プロファイラなら関数レベルで処理時間が出てるのではないか？
CIのほうでトータル0.1秒で処理しきってるからおそらく大したデータ量ではないと思う
せいぜい数十から数百レコードの範囲かな
いくらなんでも単純なクエリで0.7秒もかかるほどLaravelもひどくないでしょ
Symfonyのソース読んでからLaravelのソース読んだんだけど断然Symfonyのが読みやすかったなぁ
Laravelって回りくどいというかなんというか
ちょっした処理を行うにもやたらとラッピングしたがるね(ラッピングすることによるメリットもあるとはいえ)
このバカ、15秒で返信してるしｗ
貼り付いてんのか。
で、聞かれたことに答えず遁走。
併用できるか出来ないか、答えたらよっぽど都合が悪い事があったんだろうなぁ。
バカって、分かりやすい。
もう、Laravelerって本当にバカだと思う。
auto_incrementなidが必須って、頭おかしいんだよ。
847nobodyさん2021/06/22(火) 16:52:02.28ID:???
DB側の実装でサイズが変わるint系を避けてnumericで桁数指定が常識だろう
なぜ素人みたいな実装を推奨してるんだ？
848nobodyさん2021/06/22(火) 17:03:20.73ID:???
>>847
やめたれｗ ここの連中素人で業務システムの構築経験とかないだろうから
あなたの言っていることは理解できない内容だと思うぞw
846nobodyさん2021/06/22(火) 15:54:38.18ID:???
オートインクリメント君がbigintを知らなかったのは笑えたな
ちょっと読んだだけでも『これ、なんでこんなめんどくさい事してんの？』ってなるよ？
851nobodyさん2021/06/22(火) 17:36:29.01ID:???
今日フレームワークがどういうつくりをしているのか気になって
Symfonyのソース読んでからLaravelのソース読んだんだけど断然Symfonyのが読みやすかったなぁ
Laravelって回りくどいというかなんというか
ちょっした処理を行うにもやたらとラッピングしたがるね(ラッピングすることによるメリットもあるとはいえ)
Laravelのコード読んでみると。
Laravelerって、本当に脳みそどうなってんの？
843nobodyさん2021/06/22(火) 14:53:52.44ID:???>>850
>>840
DBから情報を取得する部分の速度を計ってみました。
CodeIgniterは約0.1秒、Laravelは約0.7秒でした
どちらの1秒以内なので誤差と考えていいですかね？
844nobodyさん2021/06/22(火) 15:05:03.09ID:???
そのぐらいなら誤差と考えていいと思います
固定小数点数をAIに設定できるDBって何？
このバカ、何を言い出したの？ なんでauto_incrementの話を引っ張ってきたの？
頭大丈夫？
>せいぜい数十から数百レコードの範囲かな
数百レコードで0.1秒掛かるってだけで遅すぎるのに、
Laravelは同じ条件で0.7秒っすか！
あくびが出るっすね！
君はnumericの型をAI設定してるの？
>826nobodyさん2021/06/22(火) 09:55:34.70ID:???>>829
>シークエンスでオートなnumberingをするようなDBのデファインを使うのは優れた方法の1つ
>重複しないことをDBMSが保証してくれる上にパフォーマンスもよい
>よく自動採番の欠点として例示されるのがマスタ画面で新規登録する際
>登録時に採番した番号を表示できない、表示したらキャンセルした場合に欠番が出るなんて言うけど
>エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ
おまえさぁ、『エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ』って、マジで言ってる？
だーめだこりゃ。
お前さ、トランザクションと排他ロック知らないの？
避けられないわけねーだろ、素人かよ？
ってか、Laravelerが基本的に素人なんだけどさ。
>826nobodyさん2021/06/22(火) 09:55:34.70ID:???>>829
>シークエンスでオートなnumberingをするようなDBのデファインを使うのは優れた方法の1つ
>重複しないことをDBMSが保証してくれる上にパフォーマンスもよい
>よく自動採番の欠点として例示されるのがマスタ画面で新規登録する際
>登録時に採番した番号を表示できない、表示したらキャンセルした場合に欠番が出るなんて言うけど
>エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ
おまえさぁ、『エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ』って、マジで言ってる？
だーめだこりゃ。
お前さ、トランザクションと排他ロック知らないの？
避けられないわけねーだろ、素人かよ？
ってか、Laravelerが基本的に素人なんだけどさ。
idがauto_incrementなら、
登録失敗するリクエストを延々と発行し続けられる状況が発生すれば、
BIGINTも結構現実的な時間であっという間に枯渇するなｗ
だって、
『キャンセルした場合に欠番が出る』んだからｗｗｗ
AUTO INCREMENT BOMB 脆弱性と名付けよう。
トランザクションとか排他ロックとか知らなそうな気がする
知ってたらとてもじゃないけど提案できそうもない案を出してくるからねこのLaravel使い達は
828nobodyさん2021/06/22(火) 10:41:14.57ID:???
オートインクリメント君あまりの知識のなさに素人だということがバレちゃったね
それを主キーとして扱いましょうねって感じの設計になってるようだけど
本来基幹系システムの開発だとIDの設計が一つのタスクになるレベルで重要なことだったりするんだよ
だからお前らのように安易に大きい型でオートインクリメントを主キーにすればいいやって考えではダメ
そんなこと基幹システムでやったら運用時とか実際の要件とかを満たせなかったりデータベースの構造が破綻したりとかしてくるね
なんで会話が噛み合わないのかなぁとずっと疑問だったんだけど、それなんだよね。
やっと分かった。
多分、Laravelerって、本当に排他ロックを知らない。
楽観排他ロックも、悲観排他ロックも知らない。
トランザクションとは何なのか知らない。
複合プライマリキーは、FWで出来ない事になっているから要らないと思っている。
物を知らなすぎるんだよ、Laravelerは。
あり得ないことに否決されてクローズしたね Laravel使いどころかコミッター達もアホかもしれない
小数点でも扱う以外にそんなの使わんよw
馬鹿なの？w
やっぱ、基幹系作った事ある人とは話が合う。
Laravelerって、それが悪いとは言わないけど、取って出しのWEBアプリ作ってるだけの人たちでしょ。
そりゃ、まともなDB設計とか考えた事あるわけないわ。
それ自体は分野の違いだから悪いとは言わないけど、
その程度の奴が『オートインクリメント君あまりの知識のなさに素人だということがバレちゃったね』
とか、寝言、言う？ 普通。
頭が悪いにも程があるわ。
>馬鹿なの？w
いや、お前がｗ
そりゃ、エロなんたらの設計上、無理だったんだよ。別物になっちゃうから互換性が保てない。
もしかしてなんだけど、
もしかしてなんだけど、
numeric と decimal の違い、分かってない？
874nobodyさん2021/06/22(火) 18:30:31.92ID:???
ID:Sb0vhLl6が一番頭が硬そうw
870nobodyさん2021/06/22(火) 18:27:51.55ID:???
小数点でも扱う以外にそんなの使わんよw
馬鹿なの？w
複合主キーを採用することによりFWのメンテコストが増える側面は否定できないから、それによる恩恵を受ける人の割合が少なければ当然否決されるよ。
最近PHP8.1で導入が決まったFiberに関して、多くの人に恩恵のないものをメンテもしない人たちの投票によって採用するのはいかがなものか？ていう海外のブログ記事が話題になってたけど、それと根は同じ。
物を作るだけしか頭にないエンジニアは、「ぼくのかんがえたさいきょうのシステム」が果たしてどれだけ価値があり、それを維持するのにどれだけコストがかかるかをよく見落とすよね。それこそ頭が悪いと思うよ。
黙れ黙れ黙れ黙れえええええええええええええええええええええ
そういうエンタープライズ用途でLaravel使うなら、そのときはそれに見合ったアプローチにすればいいんじゃないか。
上でも書いたけど、アプリケーション中心の設計でクイックに作るならEloquent使ったほうが効率的だから自然とサロゲートキー使う。
長期的な運用を見据えた規模のあるシステムなら、データベース中心の設計になるだろうから、仮にLaravel使うにしてもクエリビルダのみにして、データベース側の設計に追従できるようにするてのが答えだと思うよ。
なんか、長々と御託を並べてるけど、複合主プライマリキーは、まともなシステムを作る上では、必須なの。
メンテコスト云々とか、関係ないよ。
本当に頭悪いなぁ…。
>クイックに作るならEloquent使ったほうが効率的だから自然とサロゲートキー使う。
本当に頭悪い？
だから、そのクイックに作るためのEloquentで、複合プライマリキーを普通に扱えるようにすればいいだけじゃん。
脳みその構造、どうなってんのかな？この人達って。
トランザクションと排他処理、
知らなかったんすか？
884nobodyさん2021/06/22(火) 18:58:54.30ID:???
ナチュラルキーガイジって仕事した事無さそう
885nobodyさん2021/06/22(火) 18:59:01.07ID:???
張り付いてるお前ら、今日平日だけど仕事してないの？
トランザクションと排他処理、
知らなかったんすか？
俺はフルリモートだから家で合間合間にスレ覗きながら仕事してるって感じ。
排他ロック知らなかったバカが必死
>ナチュラルキーガイジって仕事した事無さそう
排他ロック知らなかったら、マトモに仕事出来ないだろ？
頭大丈夫か？
Laravelって、排他ロックできましぇーん、
なんて事、無いよね？
なんか、方法、あるよね？
それだけはせめて聞かせて？
SELECT文を実行する間「共有ロック」をかけたい場合は、sharedLockメソッドをクエリに指定してください。
共有ロックはトランザクションがコミットされるまで、SELECTしている行が更新されることを防ぎます。
もしくはlockForUpdateメソッドが使えます。
占有ロックをかけることで、レコードを更新したりSELECTするために他の共有ロックが行われるのを防ぎます。
で、エロなんたらは？
へー、なら、こんなんあるわけないじゃんw
>>826
>826nobodyさん2021/06/22(火) 09:55:34.70ID:???>>829
>シークエンスでオートなnumberingをするようなDBのデファインを使うのは優れた方法の1つ
>重複しないことをDBMSが保証してくれる上にパフォーマンスもよい
>よく自動採番の欠点として例示されるのがマスタ画面で新規登録する際
>登録時に採番した番号を表示できない、表示したらキャンセルした場合に欠番が出るなんて言うけど
>エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ
技術的な反論を出来ていないのが笑えるｗ
あなたたち全員が挙動不審になったの、
ちょーうけるんんですけどw
本当に知らなかったんすねw
そんなんでよく今まで知ったかぶってましたねwww
トランザクションも排他処理も意識したことがないというのが実情だろうなｗ
お前ら「えっ？Laravelの内部で勝手にやってくれるんじゃないんですか？」
多分こうだろｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
DBの話はDBのスレでやってくれないかな？
業務アプリ作るうえでトランザクションや排他は重要な話だろ
自分しか使わない簡単なTodoアプリとかだったらトランザクションや排他なくても
動作するけど業務システムとかでは必須の話だよ
まあ敗北が確定してしまって反論もできないから必死に追い出そうとしてるんだろうけどｗ
そんなの相手するだけ無駄。他人は「俺スゲー」のための道具ではない
一部の値のみconfig/app.phpから取る方法を教えてください
「別のユーザーがマスタ画面を利用中なので終わるまでお待ちください」って表示させるつもりなの？
どこがレベル高いんだ？w
かなりレベルが低いとしか言えないのだが
>>915 : もしかしてだけど「マスタ画面で新規登録」を平行で稼働させないって言ってるの？「別のユーザーがマスタ画面を利用中なので終わるまでお待ちください」って表示させるつもりなの？
こいつら、マジで言ってるのかな？ 凄いな
Laravelerって本当に、マトモな連番発行の仕方を知らなかったんだ。
あのさ、『トランザクションと排他ロック』と言われて意味が分からないってのは、ITエンジニアとしての知識・知能欠如相当ヤバいんだよ？
「別のユーザーがマスタ画面を利用中なので終わるまでお待ちください」？？？？
頭おかしいんじゃないの？ Laravelerってこの程度のバカしか居ないって事が判明してしまった。
>かなりレベルが低いとしか言えないのだが
虚勢を張るのは大概にしといた方がいい。
ここ数十レスのやり取りで、あなたたちLaravelerのレベルの低さが十分過ぎる程露呈してしまったんだから。
Laravelerはauto_incrementでしか重複しないIDの生成の仕方を知らないって事がね。
だから、あなたたちがこれまで作ってきたシステムには、決して少なくない数のシステムに
AUTO INCREMENT BOMB脆弱性が存在する可能性が存在するという事が確定してしまった。
>「俺スゲー」目的の言動しかできない人
何いってんのかな？ この低脳。
俺はIT技術者としてアタリマエのことしか言ってないよ。
で、最初、あなたたちLaravelerは自分たちの無知に全く気づかずに俺の方が無知だとバカみたいな事を言っていて、
いざ、実態はあなた達のほうが無知極まりないという事が分かった途端、
今度は「俺スゲー目的だ」と言い出す。
あなたたちってさ、『恥』って概念、無いの？
小人って、凄いよね。
>傾聴力ゼロなので見放したのが現在。
傾聴力？ｗ
人の話を全く聞かなかったのは、あなた達でしょｗ
というか、途切れない連番IDの作り方くらい、学習しなさいよ。
おまえはオートインクリメントしたシーケンスを巻き戻せるって言ってるんだぞ？自分が何を言ってるのかわかってる？ちゃんと元コメのバカなコメみてる？
論点ズレてるぞ
平行実行可能なシステムで連番を付与するとき、先行して採番したユーザーがキャンセルしても歯抜けにならないかどうかの話だぞ
>「別のユーザーがマスタ画面を利用中なので終わるまでお待ちください」って表示させるつもりなの？
俺、『楽観排他』と『悲観排他』って、書いたよね？
マジで意味分からなかったんだ。凄いな。それでよく今までシステム作って来たね。
あなたの作ってきたシステムって、欠陥品だらけだったって事じゃん。
さて、問題です。
それを表示させないためには、どっちの排他処理が必要でしょうか？ｗ
本当に頭が悪かったんだね、Laravelerって。
>「別のユーザーがマスタ画面を利用中なので終わるまでお待ちください」って表示させるつもりなの？
どこで言ってる？ 幻影でも見えるのかな？ 幻聴でも聞こえるのかな？
ほんとうに、あたまが、悪いんだねｗ
そんな事、一言も言ってないよ。よく見返してみな？
>>921
>おまえはオートインクリメントしたシーケンスを巻き戻せるって言ってるんだぞ？
どこで言ってる？ 幻影でも見えるのかな？ 幻聴でも聞こえるのかな？
ほんとうに、あたまが、悪いんだねｗ
そんな事、一言も言ってないよ。よく見返してみな？
Laravelerって、日本語が読めないんだ。
だから、俺が>>862で
>おまえさぁ、『エントリー順にnumberingする以上、たとえ手作業でやっても避けられない問題だ』って、マジで言ってる？
>だーめだこりゃ。
>お前さ、トランザクションと排他ロック知らないの？
>避けられないわけねーだろ、素人かよ？
と言ったのを、バカで低脳なLaravelerは
『オートインクリメントしたシーケンスを巻き戻せるって言ってる』
と認識してしまうんだ。
なわけねぇだろ、脳みそ腐ってんのか？
>平行実行可能なシステムで連番を付与するとき、先行して採番したユーザーがキャンセルしても歯抜けにならないかどうかの話だぞ
そうだよ？ あたりまえじゃん。
で、Laravelerは、歯抜けにしない方法が“まーったく”分からないんだｗ
すげぇな。
今までそんな腐れシステムを量産してきていたのか。
ある意味、感動する。
AIB: AUTO INCREMENT BOMB脆弱性、埋め込みまくりじゃないっすかｗ
>論点ズレてるぞ
論点は全くズレてない。認識がズレてるのが、お ま え。
ユーザーBに採番２を付与
ユーザーAがキャンセル
ユーザーAは存在しない
ユーザーBは採番２を取得
これどうやって解決すんの？問題を理解できてなかったのか？
あのさぁ…。
あなた、IQ32くらいしか無いでしょ。
> 問題を理解できてなかったのか？
本物のバカなのかな？
相手するのも馬鹿らしいんだけどさ、ちょっと、ここに、所要時間書いてみ？
>ユーザーAに採番１を付与
>ユーザーBに採番２を付与
>ユーザーAがキャンセル
あなたさ、自分がどれほど頭が悪いことを自己主張しているのか、
本当に考えた方が良い。
もう一回行っとくけど、欠番しないシリアルを作るのは、何の問題もなく、可能です。
auto_incrementみたいな下等な実装に頼らなければね。
当たり前の事でしょ。
それもオラクルwとかしか使ったことが無いカスで設計したこと無さそうw
こういう奴は一人でモノが作れない
ジャニーズの嵐みたいな感じののコンサートで、
チケット重複発行とかやらかすんだよな。
チケット番号auto_incrementって訳にはいかないから、
自前で実装するじゃん。
でも、排他処理の事、全く知らないじゃん。
当然、重複するじゃん。
もう、地獄絵図しか見えない。
本当に、重複しない連番、生成出来ないの？
あなた、そんなんでよく『システム作ってる』って言えますね。
本当に、欠番しない連番、生成出来ないの？
こっちが正確な表現かな？
あなた、そんなんでよく『システム作ってる』って言えますね。
問題を正しく理解できてなかったんだね
ユーザーCに採番1を付与なんていう間抜けな提案でもしてみるか？
それとも採番確定後に再採番でもしてみるか？
シーケンシャルなnumberingにするには確定後に採番するしか問題は解決しないんだよ
他の方法があったら提案してみろよ
ちなみにこの件は自動採番に依存してる部分はないぞ
実際のコードで見たい
1,2,3,4,5と番号が並んでいます
3番のユーザーが削除されました
1,2,4,5という並びになりました
番号が順番にならんでないじゃないか！けしからん！！
という話です
自分を持ち上げる(俺スゲー)
他人をけなす(俺スゲー)
何度も言うけど、
欠番しない連番を付与するのは、
当たり前の事として、
可能です。
方法は、トランザクションと排他処理を正しく行うだけの事です。
あなた、本物の、バカでしょ？
あほじゃないかな？
>シーケンシャルなnumberingにするには確定後に採番するしか問題は解決しないんだよ
>他の方法があったら提案してみろよ
ごめーん、本当に何言ってるのかわからないんだけど、
要約すると、
あなたには、『欠番しない連番を生成する能力が有りません』って、力説してるのね？
それでいいのね？
ちょっと、なんでもいいからあなたのID教えてくれる？
その程度の能力しか無いバカのIDが知りたい。
本当に下等過ぎるんだって事、自覚したほうが良いよ？ あなた。
>トランザクションと排他処理するってことは後続ユーザーが番号確定できないよ
>あほじゃないかな？
ここまでバカなのか…。
さっきも書いたんだけどさ、
『楽観排他』と『悲観排他』の違いくらい、ぐぐりなよ。
チンパンジーなの？ あなた
ユーザーAは1番、ユーザーBは2番
この状態からユーザーBをどうやって1番に変更するんだ？
すでに画面には2番と表示されているから動的に1番してはいけない
ロックやトランザクションの問題じゃないんだけどどこでそういう理解になったの？
>あほじゃないかな？
うん、あなたが、『あほ』
ぐぐる事も出来ない。
というか、流石に2021年にもなって、『楽観排他』と『悲観排他』を知らないバカが居るとは思ってもみなかった。
>ロックやトランザクションの問題じゃないんだけどどこでそういう理解になったの？
だから、『楽観排他』と『悲観排他』について、調べてからしゃべりなよ、チンパンジー君。
まず話を進めようか
ユーザーAとユーザーBの画面にはそれぞれユーザーA=1、ユーザーB=2という数字が表示されてる
ここまでは理解できてるか？
もう言い訳は済んだか？
マジで、お前が、程度が低すぎるんだって事くらい、いい加減に理解しろ、サル。
こいつ、マジでチンパンジーだろ。
948nobodyさん2021/06/23(水) 11:38:56.42ID:???
>>944
まず話を進めようか
ユーザーAとユーザーBの画面にはそれぞれユーザーA=1、ユーザーB=2という数字が表示されてる
ここまでは理解できてるか？
どこの世界に、新規登録に於いて、最初に裁判するバカシステムがあるんだよ。
こいつ、マジでチンパンジーだろ。
Larabelerって、本当にこんなバカしか居ないんだな。
948nobodyさん2021/06/23(水) 11:38:56.42ID:???
>>944
まず話を進めようか
ユーザーAとユーザーBの画面にはそれぞれユーザーA=1、ユーザーB=2という数字が表示されてる
どこの世界に、新規登録に於いて、最初に採番するバカシステムがあるんだよ。
こいつ、マジでチンパンジーだろ。
Larabelerって、本当にこんなバカしか居ないんだな。
948nobodyさん2021/06/23(水) 11:38:56.42ID:???
>>944
まず話を進めようか
ユーザーAとユーザーBの画面にはそれぞれユーザーA=1、ユーザーB=2という数字が表示されてる
思い込みで仕様を勘違いするのは初心者にありがちなミスだ
精進しろよ
新規登録で、そんなシステムあるわけねーだろ、ヴァカ！
バカっていうほうがバカなんです〜、ばーかばーか
Laravelerって、こんなレベルなんすね。
955nobodyさん2021/06/23(水) 11:44:28.36ID:???
>>953
思い込みで仕様を勘違いするのは初心者にありがちなミスだ
精進しろよ
957nobodyさん2021/06/23(水) 11:44:58.08ID:???
>>956
バカっていうほうがバカなんです〜、ばーかばーか
これがLaravelerの実力か。
Laravelerは、バカしか居ない、という結論が出てしまった。
>文字ベースで書いてるからややこしいんだよ
>実際のコードで見たい
んー、あのさ、
マジで、『楽観排他』と『悲観排他』について勉強しなよ。
コードが見たい？
こんなん、システム開発者としては、常識っていうか基本のキなの。
この程度の事しらないでシステム作るからダブルブッキングしてしまいましたーみたいな
下等な事故が起きるんだよ。
マジで、勉強しなさい。
そして連番を求めてくる
たった1つの優れたやり方は「現在、他のユーザーが登録中です」と表示することなんだ
そしてアプリ的な排他ロックのキーを外し忘れる不具合（しばしばメンテで発生する）が発生して
保守運用チームが気を聞かせて「1人しか同時に登録できなかったので何人でも同時に登録できるようにしておきました」
とドヤ顔で客に報告する
便利だわー、さすがだわーと褒められますますドヤ顔で真っ赤になる
その数時間後に客から「IDが飛ぶんです。不具合です。すぐ直してください」と緊急メンテになり青くなる
それがおまえらが選んだ職業なんだよ
オレの人生はロックなんだよ
>新規登録画面（確定画面ではなく入力前）でID表示を強制してくる事業者は少なくない
ねーよ、ヴァカ
何長文書いて事実捏造してんだ、引きこもり！
>そしてアプリ的な排他ロックのキーを外し忘れる
排他ロックに“キー”なんてねーよ！
妄想で語るな、キチガイ！
マジで脳みそ腐ってるんだろうな…。
962nobodyさん2021/06/23(水) 11:54:18.82ID:???>>964>>965
新規登録画面（確定画面ではなく入力前）でID表示を強制してくる事業者は少なくない
そして連番を求めてくる
たった1つの優れたやり方は「現在、他のユーザーが登録中です」と表示することなんだ
そしてアプリ的な排他ロックのキーを外し忘れる不具合（しばしばメンテで発生する）が発生して
保守運用チームが気を聞かせて「1人しか同時に登録できなかったので何人でも同時に登録できるようにしておきました」
とドヤ顔で客に報告する
便利だわー、さすがだわーと褒められますますドヤ顔で真っ赤になる
その数時間後に客から「IDが飛ぶんです。不具合です。すぐ直してください」と緊急メンテになり青くなる
また説明を見落としてるじゃん
成長ないな
サーバのディレクトリに「lock」っていうディレクトリを作っておくんだよ
ディレクトリ作成に成功したらロック取得、失敗したら他のユーザーがロック中なので退場
また賢くなったな。精進しろよ
lockディレクトリ！
あまりにも下等な表現が出てきてビックリっす。
これがLaravelerなんすねw ちょーウケるんですけどw
だめ実装を久しぶりに見たw
コロナワクチンの予約システムも予約番号の重複とかやらかしてましたね
ユーザーAは新規登録中にお昼ご飯にいきました
ユーザーBは「ユーザーAがロックなので登録できません」という表示を見ることになる
「ふーん、あいつロックなんだ・・・」
ユーザーBは複雑な気分で会議に行ってしまいました
ユーザーAは昼食から戻ってきましたがどうしてもわからない項目があります
「Bさんに聞かないとわからないな」
登録画面を最小化して別の仕事をすることにしました
会議室の合間にユーザーBは新規登録が出来ないか何度も画面を出しますがいずれにしても
「ユーザーAがロックなので登録できません」
の表示が変わりません
ユーザーBは新規登録が出来るまで席に戻る必要はないなとさらに別の仕事に行ってしまいました
これがデッドロックという現象です
うかつにロックを使うとデッドロックになってしまうというお話でした
ディレクトリ作成成功後にサーバ再起動とか発生したらアウトでは？
再起動したらクリアされるRAM領域で行っているなら大丈夫だけど
HDD上だとディレクトリ残りっぱなしになってデッドロックになるぞ
まあそもそも組み込みの世界じゃあるまいし排他をディレクトリあるなしでやるなよ
DB等の操作は楽観排他や悲観排他使えよ
ID:+cgzqi1Qに対して反論するならもっとまともな実装で反論しろよｗｗｗｗｗ
さすがにその実装はやばいｗ
郵便局のお問い合わせ番号は端末ごとに1000件程度プリ発行しておいてそこから採番する
仕様の確認
・チケットの席は有限
・追加販売はあるがまとめて数千席単位でせいぜい1度か2度の追加
・席はチケット販売会社ごとに割り当てがある
・チケット番号は販売会社ごとに独立している
・席番号は販売会社が違っても会場で決められた番号を使う
・チケット1枚につき1〜5席まで購入できる
・チケット番号は必ずしも連番で発行する必要はない
・チケット番号は十分に余裕のある桁数であるとする
購入の流れ
1.ユーザーは自宅PC、スマホ、もしくは専用端末で購買操作を行う
2.欲しい席を入力する（席番号にロックをかける）
3.欲しい席を全て入力し終わったら支払い方法、クレジットカード番号等を入力する
4.オーソリが通らないなど支払い不可であれば席番号ロックを解除して購入フローを終わる
5.支払いフローが終了すればチケットを発行する。このときチケット番号は端末ごとにプリ発行されている中から取得する
6.プリ発行されている番号が足りなくなればセンターに問い合わせて追加発行をしてもらう
逆にいうと再起動に強いlockだと言える
まさか、2021年にもなってロックファイル人力生成して排他する実装を
『力説』するほどの低知能が存在するとは、流石に夢にも思ってなかった。
>>973とか、『情報交換がしたい』とか言ってるけど、
こんなバカ排他情報交換して何するつもりなんだろ？
もはやそれ、テロに近いだろ。
ってのは、周知していったほうが良さそうだな、社会全体のために。
で？ じゃあ実際に欠番せずダブルブッキングしないIDをどうやって発行するか、
あなた >>984 は当然言えるんだよね？
プリーズ。
【PHP】Laravel【フレームワーク】 Part.7
https://mevius.5ch.net/test/read.cgi/tech/1624431485
【PHP】Laravel【フレームワーク】 Part.7
https://mevius.5ch.net/test/read.cgi/tech/1624431485
【PHP】Laravel【フレームワーク】 Part.7
https://mevius.5ch.net/test/read.cgi/tech/1624431485
なんで「わからないので教えてください。」って言えないの？
それができるなら零細には居ないし
auto_incrementにdecimal使えるのって何のRDBなんだろ？
RDBから自作でもしてんのかな
排他制御に関して言えば技術的にかなり困難な問題だから聞ける人が居ない
まず会社では俺が一番の先輩だし
Laravelでは欠番しないような処理を書くことが公式で非推奨扱いだぞ
一般的にはとても信じられないことだけど公式で非推奨っていっちゃうあたり
Laravelがおかしいことがわかる
主キーの欠番によって挙がる問題を教えて
そもそも主キーに欠番が出るだけで不都合起きる実装の問題では？
どう考えても実装か設計に問題があるだろ
お前いつもつまらないので、そろそろこのスレから居なくなってどうぞ。アンチオートインクリメントおじさんと同レベルに無価値。
Laravelを使ってauto_incrementに欠番を出さないようにするにはどうしたらできますか？
例えばユーザーテーブルに新しく挿入してidが100のユーザーが作れますがそのユーザーを消してもう一度挿入するとidが100じゃなくて101になってしまって困ってます
【PHP】Laravel【フレームワーク】 Part.7
https://mevius.5ch.net/test/read.cgi/tech/1624431485/
新しいスレッドを立ててください。
life time: 28日 20時間 36分 29秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 岸田総理「誰ひとり取り残さない社会」実現へ [煮卵★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で ★2 [少考さん★]
- “消えない広告” ×マークが押せません!? 「ダークパターン」世界で問題に | NHK [少考さん★]
- 【世帯年収2000万円以上の富裕層】「よく身に着ける洋服のブランド」…ダントツ1位は「ユニクロ」 [ネギうどん★]
- 【俳優】令和の沢尻エリカ事件か！番宣出演の若葉竜也に苦言殺到「態度悪すぎ」「朝から不快」 [ネギうどん★]
- トライク(三輪自動車)が大型貨物に追突、男性死亡 男児意識不明 ヘルメットなし [蚤の市★]
- NYM @ LAD ★4
- AFC U23アジアカップ カタール2024★8
- AFC U23アジアカップ カタール2024★9
- NYM @ LAD ★2
- NYM @ LAD ★2
- 【フジテレビ】2024 FORMULA 1【NEXT】Lap270
- 昼になったし旦那のチンポしばいてくる
- 昼から酔っ払ってるんだが質問ある？
- すまん炎刀・銃って刀なの？
- 昼飯書いて消えろ [874629454]
- 鳥って可愛いよな。 飼いたいからおすすめの品種を教えてくれ🐦🐓 [225652761]
- バイトもろくにしたことないから初任給が嬉しすぎて変になってる