Вообщем читать материал по ссылкам так и не научились...
Еще раз повторю:
1. использовать один for по имеющейся у Вас в данный момент структуре
2. хранить в формате
Наверное глупо рассчитывать, что кто-то напишет подобный код (хотя предполагаю, что там строчек немного будет.
Насчет *.xls файлов незнаю, а так Вы абсолютно правы, открыл файл, считал адрес, curl'ом перешел по адресу, в результате получил весь html страницы, а далее выдираем из него то что необходимо, записываем в файл. (Добавление)
ах да, не заметил что вопрос о возможности
хм, а по другому никак, ведь при вставке в БД(с учетом препарированного запроса), данный хэш и вставляется как строка, без всякого экранирования. А как иначе?
Вот именно как строка, а у Вас он воспринимается как код на php, покажите исходники.
Verifies that the given hash matches the given password.
Note that password_hash() returns the algorithm, cost and salt as part of the returned hash. Therefore, all information that's needed to verify the hash is included in it. This allows the verify function to verify the hash without needing separate storage for the salt or algorithm information.
в ответе выше, я говорил, что в password_hash, я cost вообще не ставил.
Так какого хэ password_verify так медленно работает?
==============
стало понятно, тот хэш был создан при косте 20, поэтому он и проверяет так долго.
Вроде действительно понятно что при проверке он будет хешировать так же как был захеширован хеш с которым идет сравнение.
arimanecro пишет:
Но тут ещё такая хрень появилась, пароль зашифрованный при помощи password_hash(), содержащий точку, например:
В Си, например, в функцию можно было указатель на переменную указать, куда, например кода запишется. Такая практика есть в пхп или как ошибки отлавливаются правильнее всего?
Можно и так, но если у Вас не будет ошибки то переменную все равно передавать придется, можно хоть тип у возвращаемого значения смотреть и возвращать массив или код ошибки, как было сказано выше, дело ваше, зависит от конкретных ситуаций. (Добавление)
freelsd пишет:
Понял, наверное с исключениями и буду работать. Но еще интересно как это раньше решалось, когд исключений в РНР не было?
Вариантов много и нет одного на все случаи жизни(если мне не изменяет память в автозагрузчике и вовсе по стандарту запрещено кидать исключения)
В общем, у меня есть функция, которая возвращает массив, а при неудаче false. Как мне еще возвращать при надобности код ошибки, в случае неудачи функции?
Возвращайте всегда массив, в случаи неудачи возвращайте что-нибудь подобное:
Так и ответьте: требуется изменить default-time-zone в конфиге mysql.
Вопрос уже поднимался, на что был получен ответ описанный выше: должно все работать средствами php или редактированием структуры БД без изменения настроек сервера, и решение не должно сильно увеличивать нагрузку на сервер при большом количестве запросов(что подразумевается под большим количеством запросов уже уточнял, речь о тысячах запросов в секунду).
Так что в данной ситуации решения кроме как каждый раз при установлении соединения посылать запрос SET time_zone = +00:00, я пока не нашел. Надеюсь это не сильно скажется на производительности.
Так же есть идеи поковырять постоянные соединения и попробовать реализовать отправку запроса только при установлении нового соединения, но как определить устанавливает mysqli новое соединение или использует уже существующее пока не сообразил.
или другой вариант: костыльно прочитать файлик с tz(если конечно это возможно) и установить tz в php согласно системной и надеяться что mysql тоже использует системную tz(что в принципе возможно проверить опять-таки дополнительным запросом к БД)
upd. ах да, еще одно требование: решение должно работать на любом сервере и не важно какую tz он использует.
Ну ну. Аж целых два rps в пике? Или, невероятно, даже наплывами до 10?
Ну зачем так сразу, иногда до 1000 в пиках доходит. Эт совсем не мое, меня лишь попросили поправить сие хозяйство скинув исходники, доступа к настройкам сервера нет и не будет, должно все работать средствами php...
И все же, как лучше поступить? в php без костылей системную tz не получить, как и время в текущей tz, следовательно получаем в UTC. по MySQL вариантам 1 - не нравится тем что похож на извращение хранить не верное время, 2 - не нравится тем что необходим для каждого запроса, а 3ий - необходим для каждого соединения.
Собственно немного поясню почему меня так волнует лишний запрос при каждом соединении с БД: сервис высоконагруженный и если можно обойтись без лишнего запроса к БД или решить данную проблему как-то иначе - был бы рад услышать данные советы.
Спасибо, но в ходе раскопок возникли различные варианты решения:
1. задать значение поля по умолчанию как UTC_TIMESTAMP;
2. Как я понял хранит он все равно в UTC а при запросе конвертирует в соответствии с сессионной tz поэтому мы можем конвертировать сами во запросе: SELECT CONVERT_TZ(created_at, @@session.time_zone, '+00:00');
3. поменять сессионную tz запросом $mysqli->query("SET time_zone = +00:00");
Возможно существуют и другие(при отсутствии прав на изменение конфигов mysql и задание глобальной tz) поэтому вопрос как будет лучше?
Благодарю, теперь наконец все встало на свои места)
andrewkard пишет:
в котором находится сервер. Если это известно, то далее дело техники.
Речь как раз о неизвестном, в данный момент нет никакого сервера(есть свой локальный для разработки), и в какой tz будет реальный - понятия не имею.
Мелкий пишет:
Угу, так и запишем, раньше работали в рамках только одной таймзоны.
Вы абсолютно правы, тк работать в UTC намного проще и в большинстве случаев достаточно)
Мелкий пишет:
Так и базе скажите, в какой вы таймзоне хотите воспринимать время. В mysql системная переменная time_zone.
Получается тоже не хорошо, но похоже так и придется. Не хорошо потому что если нет доступа к конфигурации mysql придется при каждом соединении отправлять запрос на установку данной переменной(или я ошибаюсь?) так же возникает вопрос: любой ли пользователь может это сделать(нужны ли дополнительные права)?
Благодарю, получается после каждого соединения с БД(в случаи невозможности изменения конфига) отправлять запрос SET time_zone = timezone или есть возможность задать это на этапе соединения используя mysqli(пока бегло пробежался не нашел, пойду еще почитаю)?
ЗЫ: Какое счастье что триггеров с датой нет и не предвидится
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 114
