Планы на следующие версии xa-tags
После тестирования в боевых условиях на большой базе решил отметить версию как 0.3 и двигаться дальше.
Что всплыло в процессе использования:
Про схему БД. Опять.
На сей раз вопрос решён окончательно. Разобрал исходники gelbooru, посмотрел схему бд.
Так вот, ребята тоже используют MATCH, полнотекстовые индексы и зверское кэширование результатов поиска.
Ещё раз погонял тесты - не стоит оно того. Трёхэтажные запросы, индексы и сервисные данные втрое превышающие полезную нагрузку, читать глазами - забудьте.
Надо будет дополнить данными, сделаю так:
id | ... | tags | <- исходная таблица
|-> ...
`->| ... | data | <- N'ая таблица
И все связи - по этому единственному ключу.
Рекурсия для основных операций
Добавил рекурсию ко всем основным операциям в режиме tool'а. В "dumb"-вариации заработало прям сразу с полпинка, аж сам в шоке.
В "smart" пришлось посидеть над багами, и я подозреваю, что выловил ещё не всё. Также, пришлось предварительно посидеть над рефакторингом функций, но это мелочи.
Кроме того, я ускорил некоторые операции, например случаи, когда из набора тегов ничего не удаляется, т.к. указанного тега нет, и базу обновлять не нужно.
Что приятно удивило -- "dumb"-версия работает очень быстро, обход двух тысяч файлов и добавление к ним одного тега - около двух сотых секунды. Ожидал где-то порядка 0.04-0.10 c. Удаление не до пустого набора - ~0.02с.
"smart"-версия уже помедленнее, порядка двух-трёх секунд. Но там не включены транзакции в базе, поэтому это нормально и ожидаемо.
Выделение библиотеки
Задался вопросом "как вынести часть кода в плагин"? После беглой пробежки по форумам и гуглу уяснил следующие способы (для чистого си):
Алгоритм обновления базы xa-tags
Тридцать лет и три года Илья Муромец лежал на печи.
Такого бодуна Русь ещё не знала...
Вобщем, по части обновления бд не придумал ничего лучше, чем последовательно выбирать записи из базы с путями ниже определённой директории и сверять наличие на фс.