【PHP】Laravel【フレームワーク】 Part.5
■ このスレッドは過去ログ倉庫に格納されています
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
※前スレ
【PHP】Laravel【フレームワーク】 Part.4
https://medaka.5ch.net/test/read.cgi/php/1613209188/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured 俺「ああ…すごく気持ちいいよ、富美男」
富美男が俺のものを、そのごわごわとした手で優しく包み込む。
程良い締め付けと心地良い温もりで、思わず口元が緩んでしまう。
梅沢富美男「バカ野郎が……こういうのはどうだ？チロチロ…」
俺「うぁ…くっ…！！」
富美男が悪戯に亀頭の先端をチロチロと弄ぶ。屈強そうな外見には似つかわしくない、丁寧で繊細な舌使い。
あまりの気持ち良さに、射精感がぐぐぐっと高まるのを感じる。
梅沢富美男「…可愛い顔しやがるじゃあねえかこの野郎…そろそろ仕上げだ。ジュルジュル…ゴプッ！グポポ…ジュルジュルルル！グッポ！ブブブ…！」
俺「ひぁああ…！富美男！富美男ぉお！ぐっ…！！」
富美男が俺の股下で激しく上下する。俺のものはてらてらと光沢を帯び、上下運動を繰り返す度に富美男の唾液と俺の精液が混じり合った、ひどく性的な粘液が滴り落ちる。
限界までいきり立った俺のものは、欲望の全てを富美男の口内に解き放つ。
俺「ああはあっ…！！はあっ！はあ…はあっはあ……！富美男…富美男良かったよ…」
梅沢富美男「…ゴクンッ！……はあっはあっ…てめぇこの野郎！こんなにも一杯出しやがってバカ野郎…腹ん中パンパンじゃねえか…！！…まだ出したりねえよな？」
俺「…富美男には全てお見通しか。敵わないよ、お前には…」
梅沢富美男「当然だバカ野郎…ここからが本当の夢芝居だ」
俺と富美男は、夜が明けるまで、何度もなんどもお互いを求め合った。 .envコミット荒らし君もこれで大人しくなるだろう ・.envをコミットする
・node_modulesをコミットする
・vendorをコミットする
・package-lock.jsonをコミットしない
・composer.lockをコミットしない
・認証にユーザIDを利用したいのでemailカラムにユーザIDを入れる←NEW
・認証にユーザIDを利用したいのでvendor直下のファイルを修正する←NEW 俺も昔学習途中の時はvender弄るのやったけど継承すればApp配下の書き換えで済むってのは流石に学習した >>7
ユーザーIDは普通やろ
これで発狂している奴は無能 >>11
頭が悪い奴は例外を認められないんだよなw ワッチョイがあると平和になると思ってる奴ってバカじゃね？単に長いIDってだけで荒らしは気にしないか変えてくるぞ >>10
何でusername関数のオーバーライドやらないの？ >>12
例外を作るお前に問題がある。クライアントに提案する力がなく思考停止でコード書いてるだけじゃん。 この低レベルのスレでIPなんて出したら会社の回線で書き込んでる奴とか出そうで怖いからやめろw >>15
それあくまでデフォルトのauth使うからでしょ？
そんなのそもそも使わんしw
>>16
例外とは言ったけど別に例外ですらないよねw
あ、バカには分からんか >>18
emailフィールドに、emailじゃない識別子を登録するんだよね？それこそただの馬鹿じゃん。 >>19
なぜ？
わざわざカラム名変える方がバカやんw デフォルトのauthを使わんなら使わんなりの作り方はあるがそういうヤツに限ってパスワードとか平文でDB持ってる場合が多いよな >>21
君はそういう場所で働いてるんだな…哀れな環境だ この時間に固定回線で書き込みってテレワークならいいが会社の回線で書いてるヤツ居るならマジでアホだろ >>22
旧式authをreactで完全にspa化にしたのを使ってるがjetstreamベースから組み直そうかちょい迷ってる Webprogはスレ立てコマンドが効かないからだろ >>20
なぜ？て質問する時点で終わってるよな。emailてフィールドはemailを扱うためにそういう名前になっている。
お前は単にアプリの都合をDBに押し付けているだけ。
フィールドと値の属性が一致しないって前提になってしまうと、そのDBはもはやデータベースではなくダストボックスだよ。情報を整理して記録してないのだから。 >>20
DB設計をレビューする時に200%誰かから突っ込まれると思うけど、そういうときどうするの？
（200%ってのはレビュー者が2人いた場合にそれぞれ100%って意味ね）
その言葉をそのまま返して設計を押し通すのか、もしくは内心はバカにしつつ「はい、そうですね」と従うのか？ いやレビュー者2名いて指摘する確率が100%なら
最低1名以上のレビュー者に指摘される確率は100%だぞ 200%にはならない >>30
100%でも200%でも良いんだけど、君は>>20と同じ人？
同じ人なら気になるから答えてほしい。 2人いるから100%+100%=200%とか面白すぎるだろ 当然。海外ではPHP8を使ったLaravel8のTIPSも出てきてるね。 クライアントがPHP7に上げてくれないから未だにPHP5で苦労してる 5系って対応してるLaravelバージョンいくつだよ… laravelがphp8に対応してるのと関連ライブラリがphp8に対応してるかは別だけどな
php7.4から8.0へよ後方互換無い変更はあんま無いから普通にphp8使って問題になるケースはほぼ無いだろうけど お前ら.envの話はどうした？
そのために立てたスレだろちゃんとやれよ 前スレで結論出てると思うが君がまた続けたいなら好きにすれば良い laravel-vite出たのか
ネタじゃなくlaravel-mixは使う理由が無くなるな 別にLaravel-Mix使う人をディスるつもりは無いんだけど、公式に「webpackより設定が容易ですが80%くらいの用途しか満たせません」って書いてある時点であえて選ぶ理由は無いよね。
いくらwebpackの設定が簡単になるといってもvueやreactの公式テンプレでも事は足りるし、viteの以前から使う理由が無い。しかもwebpackのバージョン古いし。
といっても俺はLaravel-Mixを使ったことないから、80%の用途ってのが具体的に何が問題になるかは分からないんだけど。
ちなみに、Laravel-MixってバックエンドにLaravelを使う必要ないんだよね。
Laravel-viteもそうだけど、独立して使えるのになんで名前にLaravelってつけたんだろ。 結構ゴリゴリSPAで使ってるけどその20%にぶち当たった事は今のところないな おい過疎ってるぞ、スレ立てたやつは責任持って話題出せよ SESSION_LIFETIMEってlast_activityからの時間ですよね？
例えば120分の設定だった場合、ログインから60分の時点でページ遷移するとそこから120分非アクティブでセッション破棄されてログアウトされる
これをログインからの時間にすることはできますか
120分の設定でログインから60分の時点でページ遷移してもそこから60分(ログインから120分)非アクティブでセッション破棄されてログアウトされる
というようにしたいです 間違えた
120分の設定でログインから60分の時点でページ遷移してもそこから60分(ログインから120分)でセッション破棄されてログアウトされる
です
非アクティブかどうかは関係なし ワッチョイとか中途半端なことしないでIPまで表示するスレたてろや無能！ 一年前のスレなのか
viteが正式採用された今、感慨深いね 退会を論理削除で対応するusersテーブルって、どう設計するのがいいのかね？
mailアドレスをユニークにしちゃうと
・再登録時に削除フラグの削除で登録させると過去のリレーションが生き返る
・リレーションを復活させない仕様にすると、ユニーク制限で弾かれる
リレーションは復活させない仕様にしようと思っていて、少し調べると create_at と複合ユニークで設計する方法がいくつか出てきた
ただ、それならユニーク制限を外してしまったほうが良いような
みんなどうしてる？ 苦肉の策で削除フラグを0か0以外かにして
削除フラグとIDでユニークにしたりとかしてたな
フラグを立てる時はそのメアドの削除フラグの最大値+1で立てればいいし > 削除フラグの最大値+1
これなんか良さげだねぇ（たしかに苦肉の策だけど）
これ元に設計はじめてみる
ありがとう フラグってのはbool型を意味するのに、そこに1より大きい値を設定する時点で設計として破綻している
一般的に論理削除フラグと主キーの組み合わせでユニークチェックする場合、論理削除フラグにはnullを設定する
なぜならnullはDB上全てユニークな値と認識されるからね
本当に論理削除が必要なのかはちゃんと詰めていくべきだけど、
必要ならLaravelが標準で提供している論理削除の仕組みに乗るほうが良い
特にフラグに1より大きい値を与えて複合ユニークを実現しようと考えるスキルの低い人間にはね >>59
>>60
ふたりとも言ってることがよくわからないですが、コメントありがとうございました deleted_atとemailの複合ユニークで設計してみようかと思います
実績でもっと良い方法があれば引き続き教えて下さい 退会会員テーブルを作るのはどうなの？
会員テーブルは状態（停止｜有効｜退会）カラムを用意して。
会員が退会申請したら、状態を「退会」にして
退会会員テーブルに会員IDと退会日時を追加する。
そして「退会申請後○日後に会員データを削除する」
としたら、個人情報保護の観点でも問題がないし
復活させたい会員は復活できる。
mailアドレスをユニークにしても、
リレーションは復活しない（関連データを1から追加する）ようにもできる >>63
ググった中に提案いただいた設計の議論がありました
soudai.はてなぶろぐ.com/entry/2018/05/01/204442
少し冗長な気もしますが、ブクマ見ると結構似た設計にされている方がいるようですね
もう少し調べてみます
ありがとうございます >>64
見てきたけどこれじゃないよ。さすがに冗長すぎる
俺の提案は単に「退会用のテーブルを作って、退会時の情報を記録しましょう」だから。
とりあえず色んなやり方があるから、納得行くのを選択して試すといい 例えば、黒田努のRuby on Rails 6 実践ガイドでは、論理削除を採用していない。
単に削除しているだけ
customer = Customer.find( params[:id] )
customer.destroy!
論理削除は、広範囲に他の検索条件にも影響が及ぶ。
それが難しい。
日時のバッチ処理もしないといけない
うかつに論理削除をするなと書いてある、DB の本もある >>65
違いましたか。失礼
この記事、マサカリ（？）がそこそこ飛んできていて、その中のいくつかを、提案いただいた内容と勝手に結びつけてしまいました
納得行くものはなかなかないですねぇ
困った笑 >>66
せっかくのRDBなので物理削除したくなるのはわかりますが、今どき「退会即物理削除」は無理だと思います
今回は論理削除は必須条件なので、もし条件に合う設計案があれば教えて下さい 論理削除は、広範囲に他の検索条件にも影響が及ぶ。
それが難しい
普通に削除して、別の削除済み用のテーブルへ追加しておけば？
そうすれば、他の検索条件には影響が及ばない 「検索条件 AND 削除フラグがFalse」とか、
すべての検索条件において、一々削除フラグを考慮するのが面倒
こういうシステムは保守できない > 普通に削除して、別の削除済み用のテーブルへ追加しておけば？
こちらができるのであれば、論理削除の影響範囲は洗い出せた状態なのであまり分離するメリットは無いように思います
> すべての検索条件において、一々削除フラグを考慮するのが面倒
Laravelだとデフォルトがそういう仕組みになっています
仕組み自体はそれほど難しいものではないのでRailsでも実装されてそうですけど >>70
Laravelなら自動でその処理をやってくれる
ただし、クエリビルダ使う場合は自分で条件に気を付ける必要があるぞ 例えば、Rails では単一テーブル継承という機能がある
顧客が自宅と勤務先を持つ場合に、
自宅と勤務先の列は、大体同じものであるため、
自宅と勤務先を、住所という同じテーブルから派生させて、
Railsが裏側で、自宅と勤務先を切り替える機能
自宅 < 住所
勤務先 < 住所
type=自宅とか、type=勤務先などの検索条件を、SQLに入れなくて良い >>70
削除フラグじゃないけど、俺はそうしてるわ
会員の有効・無効とか、記事の表示・非表示とか。
別テーブルにして有効か調べてから
データ抽出するよりも明らかにパフォーマンスは良い
>>73
WordPressでもその設計だけど、アンチパターンだよな
といいつつ、同じ設計を採用する場合も多々あるけどw >>73
コメントの趣旨がわからなかったのですが、どこで単一テーブル継承を使用すると良いということだったのでしょうか？
あとそれはLaravelで実装できるものなのでしょうか？ >>74
有効・無効/表示・非表示をそれぞれ別テーブルに充てているということでしょうか？
あまり大規模な構築はやっていないので、冗長に思えます。
パフォーマンスに言及されていますが、どの部分（あるいはどの程度）でパフォーマンスに差が出ます？
ぜひ教えて下さい。指標の参考がほしいです >>75
Rails にも、単一テーブル継承といって、
フラグをRailsが裏側で、切り替えてくれる機能があるというだけの話
削除フラグとは関係ないけど >>77
> 仕組み自体はそれほど難しいものではないのでRailsでも実装されてそうですけど
こちらに対してのコメントだったのですね
理解できました
＊スレチな話題に誘導してしまい申し訳ありませんでした
回答、ありがとうございます >>78
ソフトデリートのdeleted_atとmailの複合ユニークだとダメですね
DBとしては重複登録できてしまう
>>57 の退会回数とmailの複合ユニークがDBとしては正なんですかね
（0がアクティブってのが嫌なんですよねぇ）
もう少し悩んでみます 上でnullはユニークとして扱われるって説明をしているのに、よく分からないの一言で終わってるやつ、一生エンジニアとして半人前のままで終わりそう ソフトデリートって論理削除？
そんなのバッドノウハウとして知れ渡っていてもうオワコンだろ、バグの基になるからやめた方がいいぞ >>59
これ見た感じ削除したものを復元する前提で考えるあたりマジでバッドノウハウだな ソフトデリートは世界一の堅牢な業務システムでも採用されてるからバッドノウハウじゃねえよ >>82
SQLアンチパターンをちゃんと読もうな
どんなものにでもそれが必要なケースは必ずある
問題は、論理削除のように使うことで副作用を生み出してしまう設計を、
他に手段がある中でも思考停止で使ってしまうことにある >>81
そこは理解できました
頂いたコメントのおかげで、deleted_atとmailの複合ユニークを NULLS NOT DISTINCT のオプション設定できればイケそうと判断しましたが、調査調査の結果、MySQLだとダメっぽいのであきらめました。PostgreSQLならイケたかもしれません
理解できなかったのは
> フラグってのはbool型を意味する
> 一般的に論理削除フラグと主キーの組み合わせでユニークチェックする場合、論理削除フラグにはnullを設定する
boolなのにnullをフラグとして利用する前提？？？
かなり混乱して未だに理解できません
今は判定用のカラムを作る方向を模索しています
https://yaba-blog.com/laravel-softdelete-unique/
https://qiita.com/taruhachi/items/bb78d92efa67b6936201
良い案があればご教示ください >>86
56だわ...なぜ63なんてかいたんだろ... 句点Rubyおじの居場所をこっちにも作ってあげてくださいw まずは連番問題からだな
問題だと思っているのruby爺だけだがｗ 今でも未定義変数のまま利用するというケースが無かったし
厳密にエラーになるならそれはそれで良いかと思う
typoとかで分からなかったりする場合もあるだろうから歓迎かと ■ このスレッドは過去ログ倉庫に格納されています
