Проблема кэширования OPER'ой

Gas

может по одной?
У тебя 2 проблеммы
1. Не перезагружается страница ява-скриптом (к php не имеет никакого отношения)

Может там JS отключен? тогда afaik никак ты её не перезагрузишь.
попробуй может opener.location.href='URL?random_value'

2. Если страница не перезагрузилась, а чел. кликает по ссылке то в базе опять счётчик увеличивается или чё-то подобное.

Так сделай простой sql запрос, который скажет тебе открывал member ссылку сегодня или нет.
Или у тебя с этим проблеммы?
 

mmm

Guest
Этих проблем нет.

1. Страница перегружается ява-скриптом.

2. Gas - проверяется, был ли переход по конкретной ссылке конкретного пользователя в данный день.
запрос:
$query = "SELECT * FROM ssylka WHERE (member_id = '$login') AND (ssyl_id = $row[ssyl_id]) AND (click_date = now())";
(это я уже писал).

Если бы все решалось так просто...
 

Gas

может по одной?
1. Тогда насчёт кеширования или тебе поможет поиск по этому формуму/гуглу. Или просто забудь если это какой-то единственный билд оперы. :)

2.
Просто я не могу понять, почему даже при повторном появлении данной ссылки (закэшировалась - и фиг с ней) происходит обращение к базе, где уже явно указано, что ссылка нажата, но все равно учитывается нажатие ссылки.
какое-то противоречие с
Этих проблем нет.
Ну нет, так нет.
 

mmm

Guest
1. Вот-вот, придется забыть... Хотя я думал, что м.б. хоть кто-то сталкивался с подобным...

2. Виноват, коряво написал...
Смысл в том, что по структуре скрипта: нажата ссылка - в БД добавляется запись о том, что этот пользователь сегодня нажал эту ссылку, и увеличивается количество нажатий.
Если он опять нажимает (даже при кэшировании) - количество остается неизменным (т.к. совпадают логин-дата-ссылка).
Но при какой-то OPER'е количество нажатий увеличивается.
Я прогонял версии до 7-ой - все работает замечательно, но у кого-то...

-~{}~ 22.11.04 19:27:

Кажется все... OPER'а отрабатывает.

Поставил при запросе к базе данных полное соответствие (т.е., не "=", а "like").
 

Gas

может по одной?
Ты бы поделился запросом до и после.
Но всё таки как уж очень не верится что дело в опере.
 

mmm

Guest
Gas, действительно не в опере, просто у того пользователя стояла именно она.

По поводу запроса:
было
$query = "SELECT * FROM ssylka WHERE (member_id = '$login') AND (ssyl_id = $row[ssyl_id]) AND (click_date = now())";

стало
$query = "SELECT * FROM ssylka WHERE (member_id LIKE '$login') AND (ssyl_id LIKE $row[ssyl_id]) AND (click_date = now())";

а то при вводе логина у этого пользователя получалось следующее: login%20 и MySQL считал, что login=login%20...
 

mmm

Guest
1. По первому пункту что-то я недопонял...
2. trim уже поставил
в каком смысле недекодированные?
 

netklon

Новичок
mmm обрабатывать надо данные в РНР перед посылкой запроса к БД.
Если ssyl_id у тебя уникальный идентификатор ссылки, то проверять надо бы все-таки =, а не LIKE.
 

mmm

Guest
netklon - данные, ест-сно, обрабатываются :)
А со вторым погорячился, виноват, уже после написания здесь поправил (получилось по принципу - ночью все кошки серы). Оставил только "member_id LIKE ..."
 

netklon

Новичок
а что member_id у тебя тоже неуникально? вообще зачем вводить идентификаторы, если проверять на похожесть (LIKE), а не на идентичность (=)
а по первому пункту человек хотел тебе сказать, что надо перед запросом в БД, обрабатывать и сам запрос, чего у тебя не наблюдается
 

mmm

Guest
Уникальный, но дело в том, что MySQL прожевывало пробелы в конце, поэтому и пришлось ставить like... временно, чтобы отсечь старые запросы (т.к. с trim'ом пришлось бы писать достаточно громоздкие конструкции на несколько страниц,). Сегодня уже вернул к "=" - все запросы почистились, а trim поставил в начало.

По первому пункту теперь понятно, просто не выкладывал здесь.
 

Balancer

Guest
По сабжу - чтобы Опера не кешировала страницу, проще всего использовать её с каким-нибудь параметром. Хоть просто знак вопроса в конце приписать.
 
Сверху