Какую выбрать хеш-функцию для именования запросов?
День добрый.
Есть у меня чудесный класс в PHP для работе с параметризованными подготовленными запросами Postgre
по типу pgdb::getAll('query_name', 'query_text', $paramsArray);
Имя запроса оно конечно полезно местами, но сейчас веду довольно толстый и жирный проект с кучей динамических запросов и имена довольно сильно мешают местами. Отсюда пришло решение заменить (если не указано) имя запроса не хеш от текста запроса.
Посоветуйте что именно использовать? длинна запроса от простого 'select 1 from table' до монстров на 5 страниц а4
Вячеслав Успенский: Везунчик :-) Коллизии возможны когда длина сообщения больше длины результата хэш-функции, соответственно у вас они возможны практически всегда :-)
vilgeforce: Действительно. Просто где то попадалась статья на тему выбора кеш функций для больших текстов, найти не смог решил вопрос задать. Но в зоде переписки подумалось, что вероятно просто обработать такой случай и забыть.
Вячеслав Успенский: если бы я встретил коллизию мд5, да еще и такую наглядную, я бы бегал с ней как с писаной торбой, показывая всем встречным и поперечным. но сначала я бы, конечно, убедился, что это коллизии, а не мои влажные фантазии, как это бывает у большинства похапе разработчиков, которым суровая логика которых подсказывает, что переводы строк у них съела база данных.
FanatPHP: коллизии md5 я уже встречал не раз и не два, кроме того для тех же паролей md5 рекомендуется вообще никогда не использовать, зачем с ней носиться и кому именно стоить показывать я не знаю. Собственно как бы вы поступили мне не очень интересно. Далее по тексту идет совсем непонятный бред.
Давайте подумаем: все отлажено и работает, но при вводе нового типа именования запроса, видим ошибочку, которая намекает что количество параметров переданных и в запросе страсть как не сходится, да еще в таком запросе, где сам текст и количество параметров динамические. Отсюда делаем вывод, имя запроса соответствует неверному телу запроса, конец исследования, следующая задача.
Вячеслав Успенский: забавная аргументация с "кроме того". Хотя коллизии к паролям не имеют ни малейшего отношения. Ну да ладно, раз не можешь предъявить запросы, то будем считать что тебе померещилось. Тут много таких бегает - их послушать, так и формальная логика не работает.
Ты очень нервничаешь. попей водички. Подумай - были ли подобные проблемы у кого-то, кроме тебя. Если ни у кого не было - возможно, их вообще нет, а делать надо по-другому.
FanatPHP: я не нервничаю, я удивляюсь к чему тебе тут столько оффтопа. Я задал вопрос - получил идеи - чудно. И тут фанат, оказался единственный кто во 1 сразу же начал текст с "ТЫ" и сразу же начал с разоблачения)
FanatPHP: проблемы может и были но быстрое гугление ничего не дало. Да и Posgre сложноват для большей части похапешников и слабопопулярен. Большая часть не заморачивалась оберткой над стандартными функциями итд итп.
ЗЫ коли вы такой умный можно увидеть кусок кода как вы работаете с postgre?
Анатолий K: точно, про crc32 забыл, попробую комбинацию, замерю производительность и решу. Нет не для сбора, хочу отказаться от назначения имен запросам, очень много запросов формируется динамически.
Непонятно, зачем тебе имя запроса.
Я так понимаю, что для повторного запуска уже подготовленного запроса?
И много таких запросов у тебя на приложение?
Их, по сути, вообще не должно быть, а для тех единиц, что могут встретиться - овчинка не стоит выделки.
И кроме того синтаксис php ф-ий для работы с posgre подразумевал использование имени, посему я его оставил. Удобно на самом деле, потом отслеживать чего куда кого.
не понял. pgsql не чистит за собой соединение? То есть все транзакции, переменные - вот это вот всё, чем пугал Аверин в своем докладе - оно у вас там цветет и пахнет? Тогда вопрос снимается. На фоне остального проблема с именем уже не столь актуальна
FanatPHP: незнаю чем там кто там пугал, не сталкивался нисчем страшным. Все подготовленные запросы, если их принудительно не закрывать, живут в пределах соединения. Если использовать постоянное соединение, то можно добиться вечноживущих подготовленных запросов. В принципе оптимизатор postgre штука очень умная, но все же для частых запросов я предпочитаю сэкономить ресурсы.
Забавные вещи говорит, стоит часть послушать, однако вы невнимательно слушали докладчика: он говорит о проблемах если вы используете персистентные соединения где попало и ничего против не имеет использования их там, где они изначально задуманы.
Например он часто вспоминает MySQL, но большая часть проблем не имеет места быть при работе с php mysqli и он об этом упоминает(кстати предыдущее расширание уже года два как не рекомендуется к использованию). Остальные подводные камни имхо самособойразумеются и должны быть понятны при реализации логики.
ЦА лекции имхо в основном новички (относительно конечно). С таким же кстати успехом можно попугать людей сессиями, ибо 95% "программеров" про session_commit даже не в курсе и не догадывается о возможных проблемах.
Ну так вот в mysqli проблемы КАК РАЗ потому отсутствуют, что в ней реализован механизм очистки соединения. Которого в пг нет. Так что ты или крестик сними, или трусики надень: или мы не имеем описанных проблем, или используем препареды между вызовами.
FanatPHP: там нет прочих проблем что он описывает. Забирать данные это само собой разумеется. Тут уж либо мозгами шевели либо класс-обертку пиши либо не пользуйся.
ЗЫ чего там про препареды между вызовами? какими вызовами?
Между вызовами РНР. mysqli между вызовами чистит соединение, убирая из него всё, в том числе и препареды. pg, судя по всему - нет. прочие проблемы там есть. И дело не только в том, чтобы "забирать данные"
FanatPHP: не использовал но осуждаю?)
У mysqli тоже есть персистентные соединения и их никто ничем не чистит, в обычном режиме соединение просто автоматом закрывается при завершении процесса. Но в mysqli при обычной топорной архитектуре никто обычно не заморачивается постоянными соединениями, pg же на каждое соединение стартует отдельный процесс, посему тут интересней.
Все якобы "проблемы" есть лишь особенности работы с такими вещами, не можете с ними справиться - не лезьте.
Ты сейчас выставляешь себя дураком. Споря с человеком, который таки использовал постоянные соединения в mysqli и даже специально пробовал использовать препареды между соединениями, ты, в свою очередь, выдаешь совершенно голословные утверждения. и к кому должна относиться твоя реплика "не использовал но осуждаю"? давай ты сначала поищешь хоть какое-то подтверждение собственным фантазиям, и результате убедишься, что mysqli вычищает из персистентного соединения весь тот мусор, который bg оставляет как есть, а потом мы продолжим. а то как-то нехорошо - ты кидаешь мне предъявы ровно за то, чем страдаешь сам. А попутно подумай - почему mysqli это все-таки делает.
FanatPHP: "не использовал но осуждаю" это про postgre.
Mysqli вычищает только если не стоит директива MYSQLI_NO_CHANGE_USER_ON_PCONNECT. Как раз чтобы "кодеры" не включали мозг.
ЗЫ я чето так и не увидел в ветке выше фрагмент "правильного" кода использования pg.
ЗЫЗЫ я бы сказал сударь что дураком скорей ты себя выставляешь втыкая свое мнение (не ответ) по всему тостеру, жуть кошмарная. Ну ничего, я думаю это пройдет когда будешь искать решение проблемы, а в ответ будешь получать сплошняком такие ответы. За сим пожалуй откланяюсь, не вижу смысла кормить агрессивных троллей.
молодец, теперь ты убедился, что чистит. Хоть и надуваешь при этом щёки, как будто не писал только что прямо противоположное :) еперь можешь попробовать почитать аргументацию - почему это делается. И если ты еще маленько сдуешь ЧСВ, и повнимательнее посмотришь презентацию - то, возможно, идея экономить на спичках, растягивая препареды между вызовами, покажется тебе не такой уж заманчивой.
FanatPHP: чистит там не php а сам Mysqli вызывая change_user и отключить это поведение как я тебе показал не проблема. Тем более, что штука весьма медленная и не всегда нужнная.
Если ты сильно сдуешь свое ЧСВ и подумаешь что бывают не только сделанные как попало сайтики с нагрузкой 50чел/сутки то поймешь что бывают иные мнения. И уж подготовку запроса я бы не назвал экономией на спичках.
блин, ты так акцентируешь, как-будто я писал что-то другое :) Вот мои слова: "в mysqli ... реализован механизм очистки соединения" - нигде я не писал, что РНР чистит. Штука относительно медленная, да. Но если посмотреть на место работы того же Аверина, то там КАК РАЗ будет не "сайтик с нагрузкой 50чел/сутки". а место, где очень считают деньги на сервера. И если там решили, что целостность данных дороже - то, видимо, не без оснований.
FanatPHP: а он и не говорит не используйте никогда, у него каждые 2 минуты звучит фраза "должны обрабатывать". Не использовать p: не есть панацея, выше я объяснил почему для pg. Кроме всего есть такая штука pgbouncer, тот вообще соединения в пределах пула не кладет. Впринципе понятно почему такая паника по поводу Mysql: порог вхождения низкий и люди с отключенными мозгами используют направо и налево, но база это либо нишевая, либо нафиг не нужная.
ну, в общем, ты получил от меня массу полезной (про постоянные соединения) и просто информации (про mysqli), но в такой форме, которая не позволяет твоему ЧСВ высказать что-то вроде благодарности. Я, в общем не в обиде. На том и порешим :)
Простой