Open pavel-pimenov opened 9 years ago
pavel-pimenov
commented
9 years ago From zzzxzzzy...@gmail.com on April 19, 2014 11:51:11
если счётчик теряется - то вовсе не из-за необходимости привязки к TTH, а из-за особой занятости разработчиков :)))
(не разработчик флая)
pavel-pimenov
commented
9 years ago From Pavel.Pimenov@gmail.com on April 19, 2014 13:05:34
и причем тут занятость. у меня вообще сейчас отпуск. данное изменение требует коррекции модели хранения в базе. это предложение уже когда-то обсуждалось у него есть побочный эффект - если файл находится в разных каталогах и он одинаковый то счетчик накручивается сразу на все каталоги если качается рекурсивно весь каталог
это может сказаться на тех каталогах где шарят DVD или BR диски скачка одного фильма поднимет счетчик на других фильмах.
хотя может этим стоит пренебречь.
Status: Accepted
pavel-pimenov
commented
9 years ago From wOxxOm on April 19, 2014 13:13:23
хм, действительно... может быть а) сделать опцию для полного исключения подсчета мелких файлов? б) опцию для исключения подсчета по списку файловых масок? в) считать файлы-дубликаты в кол-ве более заданного числа (например 2) по именам?
pavel-pimenov
commented
9 years ago From entry....@gmail.com on April 20, 2014 05:22:41
мне тут подпиской прилетают issues, поэтому также заодно прокомментирую ранее обсуждаемую проблему
Существующие особенности из-за не нормализованных сущностей выбранного решения
Эта проблема обсуждалась с Павлом, но судя повсему попыток подкорректировть логику небыло, да и смысла наверное для проекта флая особого нет... я к примеру, подобный счетчик использую для статистики востребованности за период (т.е. позднее все обнуляется)
По сути нужно было
Что касается предмета коллизий, и проблемы дубликатов, которые я тогда рассматривал (и судя повсему тоже подвижек не было)... В моем треккере остались заметки при рассматривании существующего решения. Пускай тут будет, т.к. я вряд ли буду еще выделять на это время (ссылку дать не могу, т.к. там private):
12.01.2014 TTH bug
В коде есть несколько подозрительных участков:
void CFlylinkDBManager::updateFileInfo( ... update fly_file set size=?,stamp=?,tth_id=?,stamp_share=? where name=? and dic_path=?;
Но он вроде бы всегда только сбрасывает значения size, stamp и прочие на -1, а потом происходит вызов CFlylinkDBManager::addFile А вот тут интересно следующие:
const __int64 l_tth_id = get_tth_id(p_tt.getRoot(), true); в котором select id from fly_hash where tth=?; и insert into fly_hash (tth) values(?)
а далее
insert or replace into fly_hash_block (tth_id,file_size,tiger_tree,block_size) values(?,?,?,?)
После чего в addFile:
insert or replace into fly_file (tth_id,dic_path,name,size,stamp,stamp_share,bitrate,ftype,media_x,media_y,media_video,media_audio) values(?,?,?,?,?,?,?,?,?,?,?,?);
Код трудно прослеживается, т.к. здесь обновление и добавление совмещенные (insert or replace)!
код get_tth_id тоже не безопасен В общем следует логировать эти участки и разделить операции на отдельные единицы:
// Синхронизациия потока
try{
//update
}
catch(Exception&){
//insert
}
Кроме того, следует также рассматривать проблемы:
SELECT (MAX(size) == MIN(size)) AS eq, MAX(size), MIN(size), tth_id, COUNT(_) FROM fly_file GROUP BY tth_id HAVING COUNT(_) > 1 AND eq <> 1
Поэтому может быть проблема с flyserver в процессе формирования запроса/передачи/или агрегирования результатов
В общем на заметку всем :) воздержитесь от совмещения логики! код становится трудно управляемым... а отлаживать через 3тьи руки становится слишком долгим занятием Лучше вообще склоняться, в зависимости от задачи, к таким паттернам как composite, faсade, решения с DI (типа IoC контейнеров), ну или strategy, command ... и т.п. тогда и логику менять будет не так уж и долго
у меня все :)
From wOxxOm on April 14, 2014 09:31:59
Если считать количество скачиваний, показываемое в окне своего списка файлов, по TTH, а не по имени файла, то можно будет перемещать файл между папками или переименовывать файл/папку, не теряя счетчика скачиваний.
Original issue: http://code.google.com/p/flylinkdc/issues/detail?id=1462