缓存控制搞乱了 mysqli->affected_rows
我有一个网页（我们称之为 A.html）。 A.html 有一些 javascript，使用简单的 document.location="B.php" 将页面切换到动态 php 页面（我们称之为 B.php）。 B.php 根据它看到的 cookie 运行 mysql 查询，并根据 mysqli->affected_rows 变量返回结果。然而，每次页面切换时 mysqli->affected_rows 等于 0，即使 mysql 表确实按照预期的方式发生了变化。有趣的是，当我使用 URL 栏直接访问 B.php（或刷新页面）时，mysqli->affected_rows 为 1，就像它应该的那样。
查看wireshark，两个 GET 请求之间的唯一区别是第二个（非 JavaScript）请求有一行 Cache-Control: max-age=0。有谁知道为什么这会影响任何事情，以及是否有办法解决这个问题？
编辑：继承人的代码
$req = $mysqli->prepare('update users set sts=NOW() where i=? and sid=? and sip=? and NOW()-sts <= '.$authentication_timeout.';');
if ($mysqli->error) {
log_mysql_error($mysqli);
die('Unexpected error:'.$mysqli->error);
}
$req->bind_param('sss',$uid,$sid,$_SERVER['REMOTE_ADDR']);
$req->execute();
print $mysqli->affected_rows;
$req->close();
I have one webpage (lets call it A.html). A.html has some javascript which switches the page to a dynamic php page (lets call it B.php), using a simple document.location="B.php". B.php runs a mysql query based on the cookies it sees, and returns a result based on the mysqli->affected_rows variable. However, everytime the page switches over mysqli->affected_rows is equal to 0, even though the mysql table does get changed the way it's supposed to. Interestingly, when I go straight to B.php using the url bar (or refresh the page) then mysqli->affected_rows is 1, like it's supposed to be.
Looking at wireshark, the only difference between the two GET requests is that the second (non-javascript) one has a line with Cache-Control: max-age=0. Does anyone know why this would affect anything, and if there's a way I can fix this?
EDIT: Heres' the code
$req = $mysqli->prepare('update users set sts=NOW() where i=? and sid=? and sip=? and NOW()-sts <= '.$authentication_timeout.';');
if ($mysqli->error) {
log_mysql_error($mysqli);
die('Unexpected error:'.$mysqli->error);
}
$req->bind_param('sss',$uid,$sid,$_SERVER['REMOTE_ADDR']);
$req->execute();
print $mysqli->affected_rows;
$req->close();
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果确实是缓存使您的啤酒变质，那么我想这样做
可以解决问题。您可以检查并验证是否是这样吗？
If it's indeed the cache souring your brew, then I guess doing
will solve the problem. Can you check and verify if that's it?
您没有显示任何代码，所以我只能猜测，但是
affected_rows()将在更新时返回 NULL，而不会更改表中的任何内容。因此，据推测，如果您重新加载页面，即使之前的页面已完成更新，第二次加载也会显示0。You're not showing any code so I can only guess, but
affected_rows()will return NULL on an update that doesn't change anything in the table. So presumably, if you reload your page, the second load will show0even if the update ran through on the page before.根本不是缓存的问题。出现问题的原因是在这种特殊情况下，同一行在执行此代码之前被更新，并且没有足够的时间延迟使 NOW() 有所不同。因此，虽然行匹配，但数据没有更改，因此 $mysqli->affected_rows 仍然等于零。 $mysqli->info 显示“匹配的行：1，更改的行：0”。
Wasn't an issue with the cache at all. The problem arises because in this particular case the same row is being updated just before this code is executed, and there isn't enough time delay for NOW() to be different. So while the row matches, there isn't a change in the data so $mysqli->affected_rows is still equal to zero. $mysqli->info shows that "Rows matched: 1, Rows changed: 0".