|
Notes |
|
|
(0011944)
|
|
zed
|
|
01-07-2013 17:11
|
|
|
Не представляется возможным. Если генерировать исключение, то при просмотре будет отображаться желаемый текст, но при загрузке, к примеру, или при экспорте, будет вылетать рабочий поток с ошибкой. |
|
|
|
|
|
А как же работает это при, скажем, неожиданном контент типе и т. п.? |
|
|
|
(0011946)
|
|
zed
|
|
01-07-2013 17:22
|
|
|
Так и работает - останавливает рабочий поток. |
|
|
|
|
Не могу спорить, так как языками не владею. Но что-то подсознательно говорит мне, что так сделать можно. Ибо такое сообщение - реакция на некое событие в процессе обработки одного тайла.
Если невыполнимо, можно закрыть. |
|
|
|
|
|
Может проще отказаться от проверки содержимого тайла и просто всегда сохранять? |
|
|
|
(0011967)
|
|
zed
|
|
01-07-2013 21:03
|
|
>Ибо такое сообщение - реакция на некое событие в процессе обработки одного тайла.
В текущей реализации тайлохранилищ нет никакой возможности как-то осмысленно отреагировать на некое событие. Единственный путь - выбросить исключение, но это путь именно для ошибок, а не для сообщений.
Где-то был по-моему тикет, про создание глобального логера, вот можно поставить в зависимость от его реализации. |
|
|
|
(0011968)
|
|
zed
|
|
01-07-2013 21:20
|
|
>Может проще отказаться от проверки содержимого тайла и просто всегда сохранять?
И во всех случаях терять изначальную версию тайла? |
|
|
|
|
Почему сразу терять изначальную версию?
Наверное имеется в виду убрать проверку, что с таким же точно хэшем где-то есть другой тайл в другой версии. Тогда тайлы в описанной ситуации будут сохраняться.
>останавливает рабочий поток
Возможно я не очень понимаю, что понимается под остановкой рабочего потока, или место в коде другое, но ведь если прилетит HTTP 404, то в логе закачки будет написано, что нет тайла, но скачка не перейдёт в паузу, а будет шпарить дальше.
А тут автор вообще пишет "на поле тайла сообщать" - то есть разговор идёт за скачку по одному тайлу (типа Insert+LClick). Тут вообще кажется проблем никаких. Хотя может я чего-то и не втыкаю. |
|
|
|
(0011972)
|
|
zed
|
|
01-07-2013 21:43
|
|
>Тогда тайлы в описанной ситуации будут сохраняться.
Будут. И будет 100500 дублей одного и того же тайла, под разными версиями.
>или место в коде другое
Именно, что место другое. HTTP 404 пишет качалка, а не хранилище. И хранилище никак не знает кто его дёрнул: или качалка по ПКМ, или поток из конвертера кэша или ещё кто. |
|
|
|
|
>будет 100500 дублей одного и того же тайла, под разными версиями
Это же если версии менять, тогда будет дублирование.
А если нет - просто поверх перепишется.
Да и куча версий тайла видна по ПКМ, вроде как даже если ССЗБ - вычистить всегда можно.
>поток из конвертера кэша
А, ну да, он вылетит. |
|
|
|
(0011976)
|
|
zed
|
|
01-07-2013 22:30
|
|
>Это же если версии менять, тогда будет дублирование.
Ну так а смысл писать тайл с тем же самым содержимым под той же самой версией? Если же содержимое тайла отличается, а версия нет, то тайл перезапишется без вопросов. |
|
|
|
|
|
Я за то что бы хранилище сохраняло тайл по ключу без всякой самодеятельности с проверкой копий. Если хочется, можно сделать дедупликацию прозрачную для пользователя, но сохранять то что дают нужно обязательно. А проверку по содержимому среди других версий нужно перенести на уровень качалки. |
|
|
|
(0011979)
|
|
zed
|
|
02-07-2013 08:08
|
|
>проверку по содержимому среди других версий нужно перенести на уровень качалки
Не выгодно - см. 0001750 И в SACS уже кстати vasketsov пропихнул флаг перезаписи тайла, аналогично можно пропихнуть и условие равенства crc. |
|
|
|
|
>Не выгодно
Ну в 99% случаев скачивание в разы медленнее любой записи в тайлохранилище, так что ИМХО скорость в этом случае не критична.
А при копировании из других источников, юзер скорее всего знает что делает, ну или сам себе злобный буратино. |
|
|
|
(0011982)
|
|
zed
|
|
02-07-2013 08:40
|
|
|
Убойная логика: оно и так медленно работает, так давай его ещё затормозим. Ведь чтобы проверить crc тайла по твоей схеме, ты наверняка попросишь у хранилища список тайлов всех версий вместе с телом и начнёшь самостоятельно сравнивать что получили и что скачали. И в итоге, твоя проверка может занять больше времени, чем загрузка тайла по сети. А в Беркли, проверка сделана без считывания тайлов из кэша. |
|
|
|
|
> Ведь чтобы проверить crc тайла по твоей схеме, ты наверняка попросишь у хранилища список тайлов всех версий вместе с телом и начнёшь самостоятельно сравнивать что получили и что скачали.
Это повод добавить в тайлохранилище возможность выдачи информации о тайле с CRC, а не делать поведение тайлохранилища загадочным, когда оно что хочет то и сохраняет. |
|
|
|
(0011984)
|
|
zed
|
|
02-07-2013 09:06
|
|
|
Меня устраивает вариант как есть. Если в САС вдруг появятся методы или интерфейсы завязанные на проверку CRC тайлов при их записи в кэш, я с радостью введу их поддержку в Беркли. Пока что там такого нету, а соваться в архитектурные изменения я зарёкся, то имеем, что имеем. |
|
|
|
|
|
Не хочешь трогать архитектуру - тогда соблюдай ту что есть. Если тайлохранилище не может или не хочет сохранять тайл - пусть выбрасывает ексепшен. |
|
|
|
|
>проверку по содержимому среди других версий нужно перенести на уровень качалки
Ты верно пошутил? Это ж бред полнейший. Доступ к хранилищу возможен не просто из нескольких потоков, а даже из других приложений и компов. Отдельная процедура получения списка хэшей вне транзакции сохранения тайла, чтобы потом по ней принимать решения, с блокировкой хранилища или без - это худшее решение из всех возможных.
>не делать поведение тайлохранилища загадочным
Это верно. Но не через анус же.
Более чем достаточно проверять хэш внутри транзакции сохранения тайла, тем более что там вся информация и так есть, для СУБД например обработка существования тайла вообще тривиальная: достаточно свалить из процедуры при перехватываемой ошибке первичного ключа. Ну и понятное дело SaveTile становится функцией: True - сохранили, False - не сохранили без ошибок, Raise - ошибка.
>аналогично можно пропихнуть и условие равенства crc
Ну в общем-то это было бы логично, чтобы снаружи передавать признак необходимости проверки. Потому что исключительно сохранятель тайла знает, насколько доверенным является источник. Миграция версионного кэша в версионный беркли - пример крайне доверенного источника, когда не надо проверять CRC, иначе будет тупо потеря данных (ведь порядок обхода версий в источнике не регламентирован). Скачка качалкой - пример недоверенного источника, где по умолчанию логично такое проверять, тем более что номера версий на простых картосервисах типа бинга, гугла и яндекса только увеличиваются. |
|
|
|
|
|
Убедил. Флаг будет оптимальным решением. |
|
|
|
(0011988)
|
|
zed
|
|
02-07-2013 11:15
|
|
>Флаг будет оптимальным решением.
Угу, внезапно. Так что будем ждать, пока в SaveTile появятся флаги и продолжим. |
|