По поводу кэширования mysql

Вид для печати

19.03.2017, 18:25
danya9877

По поводу кэширования mysql

Речь идет о r40/r41.
На сколько я понял, речь идет совершенно не об Mysql-кэшировании (сохранении результата запроса для быстрого ответа при повторном запросе). Тут уже фича павна.
Понятно, что при запросе виде tquery возвращается кэш (что такое non-threated query в случае использования mysql_query, если мне, допустим, не нужно возвращать кэш?)
Понятно, что при возвращении кэша из tquery он передается в указанную в параметрах функцию. Что такое тип "r (reference(ссылка))". Я так понимаю, кэш очищается автоматически при выходе из функции и нет необходимости использовать cache_delete().

Также, допустим, как в Wiki, я хочу использовать в массиве игрока кэш (вместо pSkin использовать Cache:pSkin). Есть ли профит делать это для данных, которые я не записываю обратно и не изменяю? Например, закешировать однажды reg-IP игрока и при подгружении из мода загружать его в кэш-переменную и держать там всегда (при отключении делать cache_delete()).

Буду рад любым высказываниям на основе опыта/знаний.
20.03.2017, 00:25
DeimoS
Очень сложно из всего написанного выделить хоть какой-то конкретный вопрос, но я попробую...

Цитата:

Сообщение от danya9877

Речь идет о r40/r41.
На сколько я понял, речь идет совершенно не об Mysql-кэшировании (сохранении результата запроса для быстрого ответа при повторном запросе). Тут уже фича павна.

Именно. Только не Pawn, а SA-MP. Точнее, плагина.
Кэшем являются данные, возвращённые в результате обработки MySQL запроса, с которыми можно работать на стороне SA-MP сервера. Кэш возвращают лишь три вида запросов: SELECT, SHOW и DESCRIBE. SHOW и DESCRIBE в SA-MP практически не найдёшь применения.

Цитата:

Сообщение от danya9877

Понятно, что при запросе виде tquery возвращается кэш

mysql_query так же может возвращать кэш. Отличие mysql_tquery от mysql_query в том, что первая отправляет обработку запроса в отдельный поток, в результате чего сервер может продолжать выполнять другие действия, пока MySQL не вернёт результат. А вторая обрабатывает всё в одном запросе, заставляя сервер подвисать, пока запрос не будет получен.

Цитата:

Сообщение от danya9877

Что такое тип "r (reference(ссылка))".

Возможность указывать в качестве передаваемого параметра массив, результат которого будет перезаписан при изменении переданного значения.
Криво объяснил... В общем, будет то же самое:

PHP код:

main() { new string[] = "test"; print(string);//Выведет "test" SomeFunc(string, sizeof(string)); print(string);//Выведет "tttt" } stock SomeFunc(string[], len) { format(strong, len, "tttt"); return 1; }

Цитата:

Сообщение от danya9877

Я так понимаю, кэш очищается автоматически при выходе из функции и нет необходимости использовать cache_delete().

Да, если ты не сохранил кэш с помощью cache_save.

Цитата:

Сообщение от danya9877

Также, допустим, как в Wiki, я хочу использовать в массиве игрока кэш (вместо pSkin использовать Cache:pSkin). Есть ли профит делать это для данных, которые я не записываю обратно и не изменяю? Например, закешировать однажды reg-IP игрока и при подгружении из мода загружать его в кэш-переменную и держать там всегда (при отключении делать cache_delete()).

Ты не совсем правильно понял пример в wiki.
Там при входе на сервер происходит запрос в базу данных с выборкой всей информации о игроке. После этого в массив загружается исключительно пароль (для дальнейшей сверки с тем, что вводит игрок) и ничего более, а сам кэш сохраняется и в массив "Player[playerid][Data]" записывается ID кэша.
Далее, если игрок вводит верный пароль, происходит обращение к записанному кэшу по его ID и последующая загрузка данных их кэша (точно такими же функциями, как и, например, в mysql_tquery) и кэш удаляется. Если игрок вышел и кэш всё ещё существует (например, он отказался от ввода пароля и вышел) - так же удаление.
Сделано это для того, чтоб не посылать повторный запрос в базу данных для загрузки аккаунта в случае, если игрок ввёл верный пароль.

То бишь, обычно регистрации пишутся по следующей схеме:
1. Игрок подключается к серверу
2. Сервер посылает запрос в базу данных на поиск аккаунта с ником игрока
3. Если аккаунт не найден - регистрация. Если найден - загрузка пароля и авторизация
4. После успешной авторизации посылается запрос на загрузку аккаунта
А в случае с сохранённым кэшем она будет выглядеть так:
1. Игрок подключается к серверу
2. Сервер посылает запрос в базу данных на поиск аккаунта с ником
3. Если аккаунт найден - загрузка пароля, сохранение кэша и авторизация
4. После успешной авторизации продолжается работа с сохранённым кэшем, из которого загружается аккаунт
Вот и всё.
20.03.2017, 01:30
danya9877

И все-таки, по поводу последнего.
Я имел ввиду что я в самом начале когда подгружаются все данные, какие-то я не записываю в переменные (как Reg-IP), а оставляю в кэше пока игрок не выйдет с сервера. Или так лучше не делать?)
20.03.2017, 11:34
DeimoS

Цитата:

Сообщение от danya9877

И все-таки, по поводу последнего.
Я имел ввиду что я в самом начале когда подгружаются все данные, какие-то я не записываю в переменные (как Reg-IP), а оставляю в кэше пока игрок не выйдет с сервера. Или так лучше не делать?)

Ну либо ты раз их выгружаешь из кэша и всё (обычная реализация), либо ты каждый раз вынужден переключаться на кэш игрока, извлекать из него данные в переменную и только потом её использовать (твой вариант). Сам как думаешь? :)
25.03.2017, 14:33
123
Цитата:
Сообщение от DeimoS

Ты не совсем правильно понял пример в wiki.
Там при входе на сервер происходит запрос в базу данных с выборкой всей информации о игроке. После этого в массив загружается исключительно пароль (для дальнейшей сверки с тем, что вводит игрок) и ничего более, а сам кэш сохраняется и в массив "Player[playerid][Data]" записывается ID кэша.
Далее, если игрок вводит верный пароль, происходит обращение к записанному кэшу по его ID и последующая загрузка данных их кэша (точно такими же функциями, как и, например, в mysql_tquery) и кэш удаляется. Если игрок вышел и кэш всё ещё существует (например, он отказался от ввода пароля и вышел) - так же удаление.
Сделано это для того, чтоб не посылать повторный запрос в базу данных для загрузки аккаунта в случае, если игрок ввёл верный пароль.

То бишь, обычно регистрации пишутся по следующей схеме:

Игрок подключается к серверу
Сервер посылает запрос в базу данных на поиск аккаунта с ником игрока
Если аккаунт не найден - регистрация. Если найден - загрузка пароля и авторизация
После успешной авторизации посылается запрос на загрузку аккаунта

А в случае с сохранённым кэшем она будет выглядеть так:

Игрок подключается к серверу
Сервер посылает запрос в базу данных на поиск аккаунта с ником
Если аккаунт найден - загрузка пароля, сохранение кэша и авторизация
После успешной авторизации продолжается работа с сохранённым кэшем, из которого загружается аккаунт

Вот и всё.
Ну и как оно, лучше будет реализовать авторизацию именно таким образом?
25.03.2017, 14:42
DeimoS

Цитата:

Сообщение от 123

Ну и как оно, лучше будет реализовать авторизацию именно таким образом?

Логично, что с сохранением кэша, ибо всего 1 запрос отправляется. Но это не значит, что "обычный" вариант неприемлем.
25.03.2017, 14:45
123

Цитата:

Сообщение от DeimoS

Логично, что с сохранением кэша, ибо всего 1 запрос отправляется. Но это не значит, что "обычный" вариант неприемлем.

А после авторизации игрока, кэш следует удалять? И перед удалением, нужно использовать cache_unset_active ?
25.03.2017, 14:57
DeimoS

Цитата:

Сообщение от 123

А после авторизации игрока, кэш следует удалять?

Да. И после отключения игрока от сервера, проверяя то, существует ли кэш (cache_is_valid)

Цитата:

Сообщение от 123

И перед удалением, нужно использовать cache_unset_active ?

Нет. Ты же удаляешь его по ID. А cache_unset_active нужна для того, чтоб функции работы с кэшем, типа cache_get_field_content_int (все, в которых нет параметра, указывающего на ID кэша), понимали с каким кэшем идёт работа

- - - Добавлено - - -

В общем, скачай отсюда исходники плагина, найди там папку "example_scripts" и в ней будет скрипт "login_system-cache.pwn". Самый наглядный пример из всех, что есть
26.03.2017, 22:10
_lizard

Цитата:

Сообщение от DeimoS

В общем, скачай отсюда исходники плагина, найди там папку "example_scripts" и в ней будет скрипт "login_system-cache.pwn". Самый наглядный пример из всех, что есть

Ради интереса заглянул я в эти примеры скриптов и увидел там это:

PHP код:

mysql_format(g_SQL, query, sizeof query, "SELECT * FROM `players` WHERE `username` = '%e' LIMIT 1", Player[playerid][Name]);

Разве mysql_format() не защищает от инъекций без спецификатора '%e'?
26.03.2017, 22:23
DeimoS

Цитата:

Сообщение от _lizard

Ради интереса заглянул я в эти примеры скриптов и увидел там это:

PHP код:

mysql_format(g_SQL, query, sizeof query, "SELECT * FROM `players` WHERE `username` = '%e' LIMIT 1", Player[playerid][Name]);

Разве mysql_format() не защищает от инъекций без спецификатора '%e'?

Эмм, нет. С чего ты взял?
Наоборот, спецификатор "%e" есть только в mysql_format. Для того эта функция, тащемта, и сделана (не считая возможности пользовательские привилегии изменять, что никто не делает особо).