元スレ【PHP】Laravel【フレームワーク】 Part.7

php覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

101 = :

>>98
>>99
この手の制御で代表的なソフトにgitがあるけどロックしてないでしょ？

102 = :

>>96

ぷっw

103 = :

>>101

ぷっw

104 = :

>>101
gitの場合だとコンフリクトが発生してマージしてコンフリクトを解消しないと
リモートリポジトリにコミットできないようロックが発生するけど？

105 = :

>>100

ヤバい、こいつら、間違いなく言いそうな気がしてきた。
危険が危ないシステム量産してそう。
だって、排他処理知らない連中だから。

106 = :

なんか、Laravelerが頭悪過ぎて、本当に笑えなくなって顔が引きつってきた。
ここまで頭が悪い連中だったんだ、って。

107 = :

>>90がgitだとすると10:05の処理の時点で
「お前ユーザBの編集結果取り込んでないだろ？」って怒られてプッシュが中断するぞ
どのファイルを編集したかにもよるけど同じファイルを編集していたのだったら
プルするとコンフリクトが発生してマージを解消する作業に入ることになる
これはgitがちゃんと排他してるからそういう処理ができているんだよ

108 = :

>>100
これは叙述トリックだよ
「JavaScript使ってクライアント側で入力チェックしているので」が前提だとしたら
「サーバ側では入力チェックは行いません！！」は正しい

しかしだよ、君らは「JavaScript使ってクライアント側で入力チェックしているので」が必ずしも行われる保証はないと言い出す
だったら話の順番がおかしい

「サーバ側では入力チェックを行う」
そして付け足しとしてUIカイゼンの為、もしくはサーバ負荷軽減の為にクライアント側でも入力チェックを行う

まるでクライアントで必ずしもチェックしているかのように書いておいて
「チェックするとはいってませーん」って子供かよ

一般的な開かれたWEBシステムであるという前提であればPHP側が本体であり
Javascript側はただのターミナルであり端末でありクライアントだ
それはスマホかもしれないしジョイボールかもしれない
何がつながってるかわからないがUIカイゼンのための何かがつながれているだろう
UIのためのアプリケーションであって業務の一部ではないのだ

逆に仕様として要件としてブラウザ、OSや設定まですべて固定された環境ではどうだろうか？
外部から遮断され必ずJavascriptでチェックされる環境
もしそうであればPHP側でチェックなどは不要でせいぜいassertで落ちればよいのだ

109 = :

>>90
そのケースだと排他制御以前に最初に取得したデータと、登録直前に再取得したデータのハッシュ値突合させて登録キャンセルするんじゃない？お前はどのタイミングでロックしようとしてんの？

110 = :

>>104
それは端末側の制御であってサーバ側のロックではない
フォースコミットできるのである点からみても自明だ

111 = :

>>106
decimal知らん方が頭悪いと思うぞ。反省しろカス。

112 = :

>>90って要するにgitの事だと思うけど
コンフリクト解決してくれってメッセージ出すだけであって
特にロックはしてないはず
ロックしちゃったら他のユーザーがコミットできないじゃん？

113 = :

>>106
安心しろ
誰もLaravelの機能は使ってない

114 = :

>>112
いやコミットはローカルリポジトリに対しての操作だからどの状況もできるでしょ
リモートリポジトリのプッシュ操作ではじかれるはず

115 = :

>>109
> お前はどのタイミングでロックしようとしてんの？

『教えてください』がねぇなぁ。

お前さ、排他処理知らないからそんな事きいてんじゃん。
馬鹿なんだから、他人に知識をもらうときは、
頭を、さげないと。な？

116 = :

>>110
通常のgitであればその通りだけど
githubだとロック機能はあるよ

117 = :

>>115
教えてくださいお願いします。はい。ではどうぞ。

118 = :

だーみだこりゃ。
一生排他処理なんか理解できるわけねぇわ。


112nobodyさん2021/06/23(水) 23:03:19.65ID:???>>114
>>90って要するにgitの事だと思うけど
コンフリクト解決してくれってメッセージ出すだけであって
特にロックはしてないはず
ロックしちゃったら他のユーザーがコミットできないじゃん？

119 = :

>>117

頭、下げてないじゃん。サル君。

120 = :

>>90のケースだとユーザAがデータを取得した時点でディレクトリを作成するべき
そしてユーザBがデータ取得しようとしたらすでにディレクトリがあるから
「現在、ユーザAが編集中です。保存作業は行えませんがread onlyでファイルを開きますか？」って聞かれる

ユーザBがデータ登録しようとしたときには「read onlyで開いています。保存できません」って表示される
ユーザAがデータ登録したら無事に「保存しました」ってなる

つまり、ディレクトリを作成したら無事にユーザAの編集後のデータは登録される

121 = :

>>108
じゃあUIがあるならロックは使用しないという>>94の意見は正解ということなの？

122 = :

>>119
答えられないのかな？てか、なんでお前は取得時と登録時のデータ突合の処理書いてないの？バカなの？排他制御以前の問題でしょ。

123 = :

こうして今日も、馬鹿システムが作成されるのであった。


120nobodyさん2021/06/23(水) 23:10:03.82ID:???
>>90のケースだとユーザAがデータを取得した時点でディレクトリを作成するべき

124 = :

>>120
この案が一番正攻法な気がしてきた

125 = 31 :

>>122

頭、下げてないじゃん。サル君。

馬鹿なサルは、バナナも貰えないよ？w

126 = :

>>122
一般的なアップデートの処理は、編集前に取得したデータをハッシュで保存しておいて、select for updateで更新直前に再度データ取得してハッシュ値突合させておき、不一致なら中断、一致なら更新だよね。

127 = :

解説しよう！！>>120の方法は設立当初のAmazonがガチで行っていた手法である
さすがに今はこの実装廃止していると信じたいがな

128 = :

>>125
>>126に書いた通りだぞ。お前は更新処理まともに実装したことない初心者でしょ。送信前の突合処理漏れてるとか致命的だぞ。

129 = :

ユーザAとユーザBのどっちを助けるかという思想によって仕様が変わる
>>90のケースだったらExcelなら10:04のデータ登録でコケる
そして10:05の情報消失は発生しない

130 = :

こうして今日も、馬鹿システムが作成されるのであった。
Laravelerにシステム開発を依頼してはいけない。


124nobodyさん2021/06/23(水) 23:13:42.65ID:???
>>120
この案が一番正攻法な気がしてきた

131 = :

>>128ってさ、会話の流れが全くわからない発達障害かなんか？
ちょーウケるw

132 = :

>>129
Wordだと逆に10:05の処理のほうでコケるぜ

133 = 31 :

>>128
>送信前の突合処理漏れてるとか致命的だぞ。

その、致命的なことをやらかしてるのがここのLaraveler共で、
俺がそのおかしさを例示したのが、
アホのお前が槍玉に挙げている事だ、
ばーーーーーーーーか！

134 = :

>>131
もはや技術的な会話も無理そうだな、お前。今日はもう寝ろ。明日、decimalの件また尋ねるからその時はちゃんと答えろよカス。

135 = :

>>133
他責にすんなよ。みっともないやつ。

136 = :

>>121
ロック中にUI待ちが発生するのはさすがにまずい

137 = :

同じマイクロソフトなのに排他制御が異なるっていうのはおもしろいな

138 = :

ヤバいよヤバいよー、Laravelerの知能、マジでヤバいよー。

139 = :

排他制御！とかドヤっておいて、まともに更新処理も書けないアンチオートインクリメントおじさんマジやべーな。

140 = :

馬鹿なLaraveler、何とか事実を捻じ曲げようと必死w


135nobodyさん2021/06/23(水) 23:21:37.54ID:???
>>133
他責にすんなよ。みっともないやつ。

141 = :

>>137
マイクロソフトだからしょうがないｗ

142 = :

Laraveler猿がウキーウキーいってるしw


139nobodyさん2021/06/23(水) 23:23:40.00ID:???
排他制御！とかドヤっておいて、まともに更新処理も書けないアンチオートインクリメントおじさんマジやべーな。

143 = :

>>140
>>90書いたのでアンチオートインクリメントおじさんだよね？違うの？

145 = :

ちなみにイミュータブルデータモデルだと、>>90みたいなケースは、排他制御なんかせずにどっちも受け入れて、あとでユーザーにAとBの更新どっちを採用するか選ばせたりする。

146 = :

Laraveler、涙目になりながらも事実を捻じ曲げようと抵抗w


143nobodyさん2021/06/23(水) 23:26:16.55ID:???
>>140
>>90書いたのでアンチオートインクリメントおじさんだよね？違うの？

147 = :

アンチオートインクリメントおじさん、イキってるわりに、decimal知らないし、>>90みたいな間抜けな処理書くし、技術力低い説濃厚だなぁ。ガッカリだわ。

148 = :

>>147
馬鹿なLaravelerて表現使ってるの、今んとこアンチオートインクリメントおじさんだけだと思ってるんだが違うのか？

90 名前:馬鹿なLaravelerが理解できない事 [sage] :2021/06/23(水) 22:25:46.19 ID:???
10:00 ユーザAデータ取得
10:00 ユーザBデータ取得
10:01 ユーザAデータ編集
10:03 ユーザBデータ編集
10:04 ユーザBデータ登録
10:05 ユーザAデータ登録　← ユーザBの編集情報消失！！！！！

149 = :

んで？ 馬鹿なLaravelerは、
90の場合、どこをどのようにロックすべきか分かったの？

UPDATEでN+1問題が発生すると思ってしまうのがLaravelerだからなぁ…。

多分、一生理解できないだろうなぁ。

150 = :

>>90の処理をLaravelで書くとどういうソースになるの？

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ

類似してるかもしれないスレッド

• 【PHP】Laravel【フレームワーク】 Part.5 (568) - [98%] - 2021/5/1 22:00
• 【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.6 (745) - [98%] - 2021/6/21 6:30
• 【PHP】Laravel【フレームワーク】 Part.12 (314) - [96%] - 2023/1/30 18:45
• 【PHP】Laravel【フレームワーク】 Part.2 (917) - [96%] - 2019/9/10 9:15
• 【PHP】Laravel【フレームワーク】 Part.3 (983) - [96%] - 2021/2/12 4:00
• 【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.10 (446) - [96%] - 2022/6/6 19:30
• 【PHP】Laravel【フレームワーク】 (887) - [84%] - 2019/4/23 21:00
• 【PHP】フレームワーク Akelos (129) - [56%] - 2019/5/9 7:46