0001997: Версионный кэш: выдавать сообщение о наличии дублирующегося тайла

Notes
(0011944) zed (manager) 01-07-2013 17:11	Не представляется возможным. Если генерировать исключение, то при просмотре будет отображаться желаемый текст, но при загрузке, к примеру, или при экспорте, будет вылетать рабочий поток с ошибкой.

(0011945) Papazol (reporter) 01-07-2013 17:21	А как же работает это при, скажем, неожиданном контент типе и т. п.?

(0011946) zed (manager) 01-07-2013 17:22	Так и работает - останавливает рабочий поток.

(0011964) Papazol (reporter) 01-07-2013 20:49	Не могу спорить, так как языками не владею. Но что-то подсознательно говорит мне, что так сделать можно. Ибо такое сообщение - реакция на некое событие в процессе обработки одного тайла. Если невыполнимо, можно закрыть.

(0011966) vdemidov (manager) 01-07-2013 21:00	Может проще отказаться от проверки содержимого тайла и просто всегда сохранять?

(0011967) zed (manager) 01-07-2013 21:03	>Ибо такое сообщение - реакция на некое событие в процессе обработки одного тайла. В текущей реализации тайлохранилищ нет никакой возможности как-то осмысленно отреагировать на некое событие. Единственный путь - выбросить исключение, но это путь именно для ошибок, а не для сообщений. Где-то был по-моему тикет, про создание глобального логера, вот можно поставить в зависимость от его реализации.

(0011968) zed (manager) 01-07-2013 21:20	>Может проще отказаться от проверки содержимого тайла и просто всегда сохранять? И во всех случаях терять изначальную версию тайла?

(0011971) vasketsov (manager) 01-07-2013 21:38	Почему сразу терять изначальную версию? Наверное имеется в виду убрать проверку, что с таким же точно хэшем где-то есть другой тайл в другой версии. Тогда тайлы в описанной ситуации будут сохраняться. >останавливает рабочий поток Возможно я не очень понимаю, что понимается под остановкой рабочего потока, или место в коде другое, но ведь если прилетит HTTP 404, то в логе закачки будет написано, что нет тайла, но скачка не перейдёт в паузу, а будет шпарить дальше. А тут автор вообще пишет "на поле тайла сообщать" - то есть разговор идёт за скачку по одному тайлу (типа Insert+LClick). Тут вообще кажется проблем никаких. Хотя может я чего-то и не втыкаю.

(0011972) zed (manager) 01-07-2013 21:43	>Тогда тайлы в описанной ситуации будут сохраняться. Будут. И будет 100500 дублей одного и того же тайла, под разными версиями. >или место в коде другое Именно, что место другое. HTTP 404 пишет качалка, а не хранилище. И хранилище никак не знает кто его дёрнул: или качалка по ПКМ, или поток из конвертера кэша или ещё кто.

(0011975) vasketsov (manager) 01-07-2013 22:09	>будет 100500 дублей одного и того же тайла, под разными версиями Это же если версии менять, тогда будет дублирование. А если нет - просто поверх перепишется. Да и куча версий тайла видна по ПКМ, вроде как даже если ССЗБ - вычистить всегда можно. >поток из конвертера кэша А, ну да, он вылетит.

(0011976) zed (manager) 01-07-2013 22:30	>Это же если версии менять, тогда будет дублирование. Ну так а смысл писать тайл с тем же самым содержимым под той же самой версией? Если же содержимое тайла отличается, а версия нет, то тайл перезапишется без вопросов.

(0011977) vdemidov (manager) 02-07-2013 06:06	Я за то что бы хранилище сохраняло тайл по ключу без всякой самодеятельности с проверкой копий. Если хочется, можно сделать дедупликацию прозрачную для пользователя, но сохранять то что дают нужно обязательно. А проверку по содержимому среди других версий нужно перенести на уровень качалки.

(0011979) zed (manager) 02-07-2013 08:08	>проверку по содержимому среди других версий нужно перенести на уровень качалки Не выгодно - см. 0001750 И в SACS уже кстати vasketsov пропихнул флаг перезаписи тайла, аналогично можно пропихнуть и условие равенства crc.

(0011980) vdemidov (manager) 02-07-2013 08:20	>Не выгодно Ну в 99% случаев скачивание в разы медленнее любой записи в тайлохранилище, так что ИМХО скорость в этом случае не критична. А при копировании из других источников, юзер скорее всего знает что делает, ну или сам себе злобный буратино.

(0011982) zed (manager) 02-07-2013 08:40	Убойная логика: оно и так медленно работает, так давай его ещё затормозим. Ведь чтобы проверить crc тайла по твоей схеме, ты наверняка попросишь у хранилища список тайлов всех версий вместе с телом и начнёшь самостоятельно сравнивать что получили и что скачали. И в итоге, твоя проверка может занять больше времени, чем загрузка тайла по сети. А в Беркли, проверка сделана без считывания тайлов из кэша.

(0011983) vdemidov (manager) 02-07-2013 08:53	> Ведь чтобы проверить crc тайла по твоей схеме, ты наверняка попросишь у хранилища список тайлов всех версий вместе с телом и начнёшь самостоятельно сравнивать что получили и что скачали. Это повод добавить в тайлохранилище возможность выдачи информации о тайле с CRC, а не делать поведение тайлохранилища загадочным, когда оно что хочет то и сохраняет.

(0011984) zed (manager) 02-07-2013 09:06	Меня устраивает вариант как есть. Если в САС вдруг появятся методы или интерфейсы завязанные на проверку CRC тайлов при их записи в кэш, я с радостью введу их поддержку в Беркли. Пока что там такого нету, а соваться в архитектурные изменения я зарёкся, то имеем, что имеем.

(0011985) vdemidov (manager) 02-07-2013 09:32	Не хочешь трогать архитектуру - тогда соблюдай ту что есть. Если тайлохранилище не может или не хочет сохранять тайл - пусть выбрасывает ексепшен.

(0011986) vasketsov (manager) 02-07-2013 09:38	>проверку по содержимому среди других версий нужно перенести на уровень качалки Ты верно пошутил? Это ж бред полнейший. Доступ к хранилищу возможен не просто из нескольких потоков, а даже из других приложений и компов. Отдельная процедура получения списка хэшей вне транзакции сохранения тайла, чтобы потом по ней принимать решения, с блокировкой хранилища или без - это худшее решение из всех возможных. >не делать поведение тайлохранилища загадочным Это верно. Но не через анус же. Более чем достаточно проверять хэш внутри транзакции сохранения тайла, тем более что там вся информация и так есть, для СУБД например обработка существования тайла вообще тривиальная: достаточно свалить из процедуры при перехватываемой ошибке первичного ключа. Ну и понятное дело SaveTile становится функцией: True - сохранили, False - не сохранили без ошибок, Raise - ошибка. >аналогично можно пропихнуть и условие равенства crc Ну в общем-то это было бы логично, чтобы снаружи передавать признак необходимости проверки. Потому что исключительно сохранятель тайла знает, насколько доверенным является источник. Миграция версионного кэша в версионный беркли - пример крайне доверенного источника, когда не надо проверять CRC, иначе будет тупо потеря данных (ведь порядок обхода версий в источнике не регламентирован). Скачка качалкой - пример недоверенного источника, где по умолчанию логично такое проверять, тем более что номера версий на простых картосервисах типа бинга, гугла и яндекса только увеличиваются.

(0011987) vdemidov (manager) 02-07-2013 09:53	Убедил. Флаг будет оптимальным решением.

(0011988) zed (manager) 02-07-2013 11:15	>Флаг будет оптимальным решением. Угу, внезапно. Так что будем ждать, пока в SaveTile появятся флаги и продолжим.

Users who viewed this issue
User List	Anonymous (2995x)
Total Views	2995
Last View	21-11-2024 09:53

Issue History
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	=> 40xxxx
02-07-2013 11:25	zed	Relationship replaced	parent of 0001750
22-11-2013 22:21	vdemidov	Product Version	.Nightly => 131111

SASGIS