Спасибо за статью!
Подскажите, я правильно понимаю, что пункт «Как превратить карту дорог OpenStreetMap в дорожную сеть для роутинга» содержит только теоретические выкладки и готового решения (набора sql) нет?
В репозитории, как я вижу, уже готовый дамп таблицы лежит. А вот как его получить для кастомной выгрузки OSM — не очень понятно. Задача не выглядит тривиальной.
Спасибо за статьи!
Будьте добры, ткните еще раз в объяснение такого факта:
чем реже можно позволить себе контрольные точки, тем лучше — это сокращает накладные расходы
логика, схожая с автовакуумом, здесь судя по всему не применима, когда лучше чаще на большие таблицы натравливать автовакуум, чтобы в один момент обрабатывать меньшее кол-во страниц.
В любом случае грязные страницы в буферном кэше должны попасть на диск. Только при увеличении checkpoint_timeout'a кол-во этих страниц будет больше на каждый чекпоинт. Или нет?
Что я упускаю? О каких именно накладных расходах речь?
Спасибо
Фильтры использовались для постобработки GPS треков (там еще были свои хитрые фильтры для выявления участков «дрифта» — когда приемник неподвижен, а координаты гуляют).
а каким образом дрифты определяли?
в наличии только координаты или еще показания других датчиков как-то учитывали?
В общем, если не затруднит — поподробнее можете рассказать?
Если я правильно понял, вы предлагаете вместе с токеном хранить некую информацию об устройстве запросившем токен (хотя бы IP-адрес) и разрешать пользоваться этим токеном только с этого же устройства?
в таком случае, Боб даже украв рефреш токен не сможет им воспользоваться вообще ни разу. Мне нравится)
Вряд ли это то, что изначально подразумевалось в вашем посте, но в итоге даже лучше получилось. Если я, конечно, опять чего-то не напутал)
В любом случае, еще раз благодарю)
А как же тогда быть Алисе, если она желает пользоваться ресурсом на двух и более устройствах параллельно? т.е. вообще исключив Боба получим ситуацию когда Алиса получив доступ к ресурсу на одном устройстве разлогинивается на всех других?
Есть какая-то вещь, которая, видимо, очевидна для вас и не доступна для меня(
После логина Алисы у обоих товарищей (и у Алисы и у Боба) есть два разных, но валидных рефреш-токена. В этом случае они теперь никак не зависят друг от друга, и могут рефрешить свои токены любое кол-во раз.
На всякий случай еще уточню, как я вижу инвалидацию рефреш-токена: в момент использования рефреш-токена он становится невалидным (добавляем его в черный список, чтобы никто не смог им больше воспользоваться), а клиенту генерим и отдаем свежую пару токенов.
В вашей схеме, я полагаю, рефреш-токен Боба должен становиться невалидным после того как Алиса воспользуется своим рефреш-токеном, но это верно только тогда, когда у обоих один и тот же токен
Алиса попробует сделать рефреш — эта операция не пройдет, потому что по её рефреш-токену рефреш сделал Боб, тогда Алисе придется по новой логиниться — до этого момента все понятно, все логично. Но сам логин не подразумевает инвалидацию других рефреш-токенов для пользователя Алиса, иначе бы вполне валидный кейс логина на разных устройствах, приводил бы к сбросу авторизаций на всех устройствах. Если бы при логине сбрасывались все доступные рефреш-токены Алисы тогда было бы понятно как токены Боба превращаются в овощ типа тыква, но, повторюсь, это не выглядит разумным решением
И да — спасибо за ответ)
В таком случае следующее использование refresh токена превратит токены Боба в то, что изображено справа).
я чего-то упускаю в этом моменте. Боб заполучил рефреш-токен и воспользовался им — значит получил новые аксесс- и рефреш- токены. После этого Алиса будет вынуждена ввести еще раз логин и пароль (т.к. её рефреш токеном воспользовался Боб) и после этого получит свою пару токенов. И теперь и Боб и Алиса имеют валидные рефреш токены, как будто Алиса залогинилась на разных девайсах, т.е. Боб может спокойно продолжать рефрешить аксесс токен. Что я понимаю не так?
Огорчило, что такие позорные статьи висят на хабре, на тему «самый извращенный способ заменить display_errors=0 в php.ini»
Хотелось бы получить ссылку на вопрос с тостера, чтобы понять контекст вопроса + больше аргументов.
В статье нет призыва использовать собаку или игнорировать ошибки.
да, конечно зависит. если подавляемая ошибка не входит в класс ошибок определенных в set_error_handler(), то функция не будет вызвана.
здесь я хотел заострить внимание на том, что собака не работает как «выключатель» нашего обработчика и этот момент надо учитывать
нет) хотя соглашусь, что похоже.
на самом деле, хотел сделать небольшой обзор механизма обработки ошибок в кохане (с демонстрацией своего мини-модуля), а как начал копать — не смог остановиться и вот результат ))
хотя от первоначальной идеи не отказываюсь — думаю все же написать обзор, как логическое продолжение этой статьи
Подскажите, я правильно понимаю, что пункт «Как превратить карту дорог OpenStreetMap в дорожную сеть для роутинга» содержит только теоретические выкладки и готового решения (набора sql) нет?
В репозитории, как я вижу, уже готовый дамп таблицы лежит. А вот как его получить для кастомной выгрузки OSM — не очень понятно. Задача не выглядит тривиальной.
Будьте добры, ткните еще раз в объяснение такого факта:
логика, схожая с автовакуумом, здесь судя по всему не применима, когда лучше чаще на большие таблицы натравливать автовакуум, чтобы в один момент обрабатывать меньшее кол-во страниц.
В любом случае грязные страницы в буферном кэше должны попасть на диск. Только при увеличении checkpoint_timeout'a кол-во этих страниц будет больше на каждый чекпоинт. Или нет?
Что я упускаю? О каких именно накладных расходах речь?
Спасибо
а каким образом дрифты определяли?
в наличии только координаты или еще показания других датчиков как-то учитывали?
В общем, если не затруднит — поподробнее можете рассказать?
можно этот момент пояснить?
Каким образом язык не позволяет группировать функциональность?
в таком случае, Боб даже украв рефреш токен не сможет им воспользоваться вообще ни разу. Мне нравится)
Вряд ли это то, что изначально подразумевалось в вашем посте, но в итоге даже лучше получилось. Если я, конечно, опять чего-то не напутал)
В любом случае, еще раз благодарю)
После логина Алисы у обоих товарищей (и у Алисы и у Боба) есть два разных, но валидных рефреш-токена. В этом случае они теперь никак не зависят друг от друга, и могут рефрешить свои токены любое кол-во раз.
На всякий случай еще уточню, как я вижу инвалидацию рефреш-токена: в момент использования рефреш-токена он становится невалидным (добавляем его в черный список, чтобы никто не смог им больше воспользоваться), а клиенту генерим и отдаем свежую пару токенов.
В вашей схеме, я полагаю, рефреш-токен Боба должен становиться невалидным после того как Алиса воспользуется своим рефреш-токеном, но это верно только тогда, когда у обоих один и тот же токен
И да — спасибо за ответ)
я чего-то упускаю в этом моменте. Боб заполучил рефреш-токен и воспользовался им — значит получил новые аксесс- и рефреш- токены. После этого Алиса будет вынуждена ввести еще раз логин и пароль (т.к. её рефреш токеном воспользовался Боб) и после этого получит свою пару токенов. И теперь и Боб и Алиса имеют валидные рефреш токены, как будто Алиса залогинилась на разных девайсах, т.е. Боб может спокойно продолжать рефрешить аксесс токен. Что я понимаю не так?
В таком случае клиент должен будет сходить на сервер за каждой фоткой, чтобы отрендерить, например, галерею.
Вариант вернуть сразу, что-то вроде:
не true REST way?
Хотелось бы получить ссылку на вопрос с тостера, чтобы понять контекст вопроса + больше аргументов.
В статье нет призыва использовать собаку или игнорировать ошибки.
Спасибо!
здесь я хотел заострить внимание на том, что собака не работает как «выключатель» нашего обработчика и этот момент надо учитывать
на самом деле, хотел сделать небольшой обзор механизма обработки ошибок в кохане (с демонстрацией своего мини-модуля), а как начал копать — не смог остановиться и вот результат ))
хотя от первоначальной идеи не отказываюсь — думаю все же написать обзор, как логическое продолжение этой статьи