Репозиторий fct-search переименован в svodd

[audetv]

Произведен перенос репозитория fct-search на новый аккаунт организации terratensor.
Репозиторий fct-search переименован в svodd.
Технические работы по переносу успешно завершены.
Спасибо.

[iprst]

Благодарность!
Поздравляю коллектив с организацией.

[iprst]

После переноса сколько времени должно пройти для обновления системы и подхвата страниц в парсер? Комментарий #441088 что-то уже час с лишним не появляется в большой своддной теме и поисковик его не видит.

[audetv]

Сразу должно было заработать, что-то не запустилось, сейчас буду проверять что.

[audetv]

Сейчас работает fct-parser так же перенёс, чтобы все сборки были из одного репозитория (ghcr.io/terratensor), сервер не мог скачать сборку парсера и парсер просто не работал. Я его собирался перенести, но позже, но из за этого и не заработало, так как конфигурацию я сразу исправлял с расчетом, что все будет в одном репозитории.

[iprst]

Роджер (с)
Всё работает!

[audetv]

Как думаете, есть ли смысл перенести остальные issue связанные с концепцией из svodd?
Я перенес пару тем в cohesion #4 , #5
или обратно их вернуть? не знаю даже. надо подумать как лучше сделать.

[iprst]

С парсером наверное придётся балансировать, поскольку понятно что есть задачи здоровой разработки окружений, но параллельно есть мелкие задачи в духе «быстро обработать несколько тысяч файлов с известным параметром»: исходные файлы нет смысла хранить, они занимают кучу места, а после вывода нужной информации в csv их можно хотя бы сжать Ultra LZMA2 и забыть — у меня все библиотеки под которые вы делали bse-parser занимают 2% оригинального места после архивирования. Два, Карл! (с)

На текущий момент это где-то 600 МБ вместо изначальных 30 Гб
В csv побольше, сейчас 2,12 Гб, но зато csv можно сразу забрасывать в базу.

[audetv]

Как видим, ищем «Александр III», русского императора, однако конструкция с римской цифрой, то бишь тремя латинскими I, обрабатывается из рук вон: ищем императора, а подсветка подсвечивает всех Александр и Александров, в том числе авторов комментариев ))

Надо из обычного режима поиска убрать поиск по имени автора, т.е. по идее поиск должен искать только в тексте, в параграфах, а остальное надо подключать фильтрами по необходимости. Как это уже оформить, чтобы без проблем мог пользоваться пользователь другой вопрос. Я имею ввиду, что при запросе поисковом указывается в структуре запроса(технической json) только поле text(paragraph) и не производить поиск в других полях без явного на то указания. Ещё когда аватар делали, тогда уже эта ситуация с пользователями мне не нравилась. Например, даже если просто поставить галочку в настройках поиска: искать по пользователям, уже будет другая выдача, галочку подобную, как концептуальный поиск. Но ее нажимать надо) Я думаю мы к пользователям еще раз придем, когда начнем подключать другие источники. мы же хотим объединять это в один поиск независимо от источника. Вот когда с толстыми книгами начнем, как сделаю фронтенд отдельный, просто для понимания и потестировать, и дальше посмотрим, как соединит это и возможно начнёт выявлятся система и пользователей определим куда-нибудь.

[iprst]

Надо из обычного режима поиска убрать поиск по имени автора, т.е. по идее поиск должен искать только в тексте, в параграфах, а остальное надо подключать фильтрами по необходимости. Как это уже оформить, чтобы без проблем мог пользоваться пользователь другой вопрос. Я имею ввиду, что при запросе поисковом указывается в структуре запроса(технической json) только поле text(paragraph) и не производить поиск в других полях без явного на то указания. Ещё когда аватар делали, тогда уже эта ситуация с пользователями мне не нравилась.

Да. Меня тоже посещали мысли на эту тему. Что сейчас круто — текстовый поиск реализуется одновременно с аватарой, то есть можно найти такой-то текст такого-автора, это очень полезно. Нужно сохранить это поведение, выведя поиск и подсветку из поля «автор», и по этому полю искать уже специальным образом, который сейчас задаётся сценарием «аватара в строке».

[audetv]

С парсером наверное придётся балансировать

Да, по сути они различаются на те которые постоянно будут парсить контент онлайн: ФКТ, различные сайты и т.д. и те, которые используем пару раз в процессе подготовки материалов. Вторые как раз можно объединить в один репозиторий и пусть лежат по разным папкам. в каждой можно сделать readme со ссылкой на issue историю появления, зачем парсер, и пусть лежат в архиве.
По идее, ко вторым можно отнести и парсер для толстых книг, он по сути так же нужен один раз и потом будет лежать в архиве.

[iprst]

Да, логично. Парсер для обновляемых отслеживаемых сайтов веб2.0 это одно направление, парсер для типовых статичных материалов (книг, страниц) это другое направление.