View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001997 | SAS.Планета | Хотелка / Feature request | public | 01-07-2013 10:05 | 22-11-2013 22:21 |
| Reporter | Papazol | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | ||
| Platform | Windows | OS | XP | OS Version | Professional SP3 |
| Product Version | 131111 | ||||
| Target Version | 45xxxx | ||||
| Summary | 0001997: Версионный кэш: выдавать сообщение о наличии дублирующегося тайла | ||||
| Description | При скачивании тайла, копия которого присутствует в кэше, визуально не происходит ничего. И непонятно, то ли ответ ещё не пришёл, то ли тайл дублирующийся. Помогло бы на поле тайла сообщать, что, мол, такой тайл существует в версии такой-то, поэтому он сохранён не будет. | ||||
| Tags | No tags attached. | ||||
|
|
Не представляется возможным. Если генерировать исключение, то при просмотре будет отображаться желаемый текст, но при загрузке, к примеру, или при экспорте, будет вылетать рабочий поток с ошибкой. |
|
|
А как же работает это при, скажем, неожиданном контент типе и т. п.? |
|
|
Так и работает - останавливает рабочий поток. |
|
|
Не могу спорить, так как языками не владею. Но что-то подсознательно говорит мне, что так сделать можно. Ибо такое сообщение - реакция на некое событие в процессе обработки одного тайла. Если невыполнимо, можно закрыть. |
|
|
Может проще отказаться от проверки содержимого тайла и просто всегда сохранять? |
|
|
>Ибо такое сообщение - реакция на некое событие в процессе обработки одного тайла. В текущей реализации тайлохранилищ нет никакой возможности как-то осмысленно отреагировать на некое событие. Единственный путь - выбросить исключение, но это путь именно для ошибок, а не для сообщений. Где-то был по-моему тикет, про создание глобального логера, вот можно поставить в зависимость от его реализации. |
|
|
>Может проще отказаться от проверки содержимого тайла и просто всегда сохранять? И во всех случаях терять изначальную версию тайла? |
|
|
Почему сразу терять изначальную версию? Наверное имеется в виду убрать проверку, что с таким же точно хэшем где-то есть другой тайл в другой версии. Тогда тайлы в описанной ситуации будут сохраняться. >останавливает рабочий поток Возможно я не очень понимаю, что понимается под остановкой рабочего потока, или место в коде другое, но ведь если прилетит HTTP 404, то в логе закачки будет написано, что нет тайла, но скачка не перейдёт в паузу, а будет шпарить дальше. А тут автор вообще пишет "на поле тайла сообщать" - то есть разговор идёт за скачку по одному тайлу (типа Insert+LClick). Тут вообще кажется проблем никаких. Хотя может я чего-то и не втыкаю. |
|
|
>Тогда тайлы в описанной ситуации будут сохраняться. Будут. И будет 100500 дублей одного и того же тайла, под разными версиями. >или место в коде другое Именно, что место другое. HTTP 404 пишет качалка, а не хранилище. И хранилище никак не знает кто его дёрнул: или качалка по ПКМ, или поток из конвертера кэша или ещё кто. |
|
|
>будет 100500 дублей одного и того же тайла, под разными версиями Это же если версии менять, тогда будет дублирование. А если нет - просто поверх перепишется. Да и куча версий тайла видна по ПКМ, вроде как даже если ССЗБ - вычистить всегда можно. >поток из конвертера кэша А, ну да, он вылетит. |
|
|
>Это же если версии менять, тогда будет дублирование. Ну так а смысл писать тайл с тем же самым содержимым под той же самой версией? Если же содержимое тайла отличается, а версия нет, то тайл перезапишется без вопросов. |
|
|
Я за то что бы хранилище сохраняло тайл по ключу без всякой самодеятельности с проверкой копий. Если хочется, можно сделать дедупликацию прозрачную для пользователя, но сохранять то что дают нужно обязательно. А проверку по содержимому среди других версий нужно перенести на уровень качалки. |
|
|
>проверку по содержимому среди других версий нужно перенести на уровень качалки Не выгодно - см. 0001750 И в SACS уже кстати vasketsov пропихнул флаг перезаписи тайла, аналогично можно пропихнуть и условие равенства crc. |
|
|
>Не выгодно Ну в 99% случаев скачивание в разы медленнее любой записи в тайлохранилище, так что ИМХО скорость в этом случае не критична. А при копировании из других источников, юзер скорее всего знает что делает, ну или сам себе злобный буратино. |
|
|
Убойная логика: оно и так медленно работает, так давай его ещё затормозим. Ведь чтобы проверить crc тайла по твоей схеме, ты наверняка попросишь у хранилища список тайлов всех версий вместе с телом и начнёшь самостоятельно сравнивать что получили и что скачали. И в итоге, твоя проверка может занять больше времени, чем загрузка тайла по сети. А в Беркли, проверка сделана без считывания тайлов из кэша. |
|
|
> Ведь чтобы проверить crc тайла по твоей схеме, ты наверняка попросишь у хранилища список тайлов всех версий вместе с телом и начнёшь самостоятельно сравнивать что получили и что скачали. Это повод добавить в тайлохранилище возможность выдачи информации о тайле с CRC, а не делать поведение тайлохранилища загадочным, когда оно что хочет то и сохраняет. |
|
|
Меня устраивает вариант как есть. Если в САС вдруг появятся методы или интерфейсы завязанные на проверку CRC тайлов при их записи в кэш, я с радостью введу их поддержку в Беркли. Пока что там такого нету, а соваться в архитектурные изменения я зарёкся, то имеем, что имеем. |
|
|
Не хочешь трогать архитектуру - тогда соблюдай ту что есть. Если тайлохранилище не может или не хочет сохранять тайл - пусть выбрасывает ексепшен. |
|
|
>проверку по содержимому среди других версий нужно перенести на уровень качалки Ты верно пошутил? Это ж бред полнейший. Доступ к хранилищу возможен не просто из нескольких потоков, а даже из других приложений и компов. Отдельная процедура получения списка хэшей вне транзакции сохранения тайла, чтобы потом по ней принимать решения, с блокировкой хранилища или без - это худшее решение из всех возможных. >не делать поведение тайлохранилища загадочным Это верно. Но не через анус же. Более чем достаточно проверять хэш внутри транзакции сохранения тайла, тем более что там вся информация и так есть, для СУБД например обработка существования тайла вообще тривиальная: достаточно свалить из процедуры при перехватываемой ошибке первичного ключа. Ну и понятное дело SaveTile становится функцией: True - сохранили, False - не сохранили без ошибок, Raise - ошибка. >аналогично можно пропихнуть и условие равенства crc Ну в общем-то это было бы логично, чтобы снаружи передавать признак необходимости проверки. Потому что исключительно сохранятель тайла знает, насколько доверенным является источник. Миграция версионного кэша в версионный беркли - пример крайне доверенного источника, когда не надо проверять CRC, иначе будет тупо потеря данных (ведь порядок обхода версий в источнике не регламентирован). Скачка качалкой - пример недоверенного источника, где по умолчанию логично такое проверять, тем более что номера версий на простых картосервисах типа бинга, гугла и яндекса только увеличиваются. |
|
|
Убедил. Флаг будет оптимальным решением. |
|
|
>Флаг будет оптимальным решением. Угу, внезапно. Так что будем ждать, пока в SaveTile появятся флаги и продолжим. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 01-07-2013 10:05 | Papazol | New Issue | |
| 01-07-2013 17:11 | zed | Note Added: 0011944 | |
| 01-07-2013 17:21 | Papazol | Note Added: 0011945 | |
| 01-07-2013 17:22 | zed | Note Added: 0011946 | |
| 01-07-2013 20:49 | Papazol | Note Added: 0011964 | |
| 01-07-2013 21:00 | vdemidov | Note Added: 0011966 | |
| 01-07-2013 21:03 | zed | Note Added: 0011967 | |
| 01-07-2013 21:18 | zed | Relationship added | related to 0000971 |
| 01-07-2013 21:18 | zed | Relationship added | related to 0001159 |
| 01-07-2013 21:20 | zed | Note Added: 0011968 | |
| 01-07-2013 21:38 | vasketsov | Note Added: 0011971 | |
| 01-07-2013 21:43 | zed | Note Added: 0011972 | |
| 01-07-2013 22:09 | vasketsov | Note Added: 0011975 | |
| 01-07-2013 22:30 | zed | Note Added: 0011976 | |
| 02-07-2013 06:06 | vdemidov | Note Added: 0011977 | |
| 02-07-2013 08:08 | zed | Note Added: 0011979 | |
| 02-07-2013 08:20 | vdemidov | Note Added: 0011980 | |
| 02-07-2013 08:40 | zed | Note Added: 0011982 | |
| 02-07-2013 08:53 | vdemidov | Note Added: 0011983 | |
| 02-07-2013 09:06 | zed | Note Added: 0011984 | |
| 02-07-2013 09:32 | vdemidov | Note Added: 0011985 | |
| 02-07-2013 09:38 | vasketsov | Note Added: 0011986 | |
| 02-07-2013 09:53 | vdemidov | Note Added: 0011987 | |
| 02-07-2013 11:15 | zed | Note Added: 0011988 | |
| 02-07-2013 11:21 | zed | Relationship added | child of 0001750 |
| 02-07-2013 11:21 | zed | Status | new => confirmed |
| 02-07-2013 11:22 | zed | Target Version | => 45xxxx |
| 02-07-2013 11:25 | zed | Relationship replaced | parent of 0001750 |
| 22-11-2013 22:21 | vdemidov | Product Version | .Nightly => 131111 |
| 08-08-2025 13:24 | zed | Category | Хотелка => Хотелка / Feature request |