В данном случае — да. Не возможно (или неоправданно сложно) протестировать поведение, которое не воспроизводится локально или на тестовом окружении. В целом и разработка таких систем затрудняется той-же причиной. Помню, как работая над внутренним приложением одного из крупнейших российских банков — приходилось переносить системный блок в другую часть здания, чтобы попасть в нужную подсеть и получить нужный ответ от сервиса.
Вероятно, можно будет подумать и над решением этой проблемы, в дальнейшем…
Всё верно, данный подход не совместим с идеей TDD. Про поддержку я уже думаю, вероятно функционал будет расширен и можно будет обновить тесты прямо из CLI, если добавились новые поля в стор, или поменялись результаты селекторов.
Касательно экзотических кейсов, вы имеете в виду, что сложно в браузере воспроизвести такой кейс?
Да, предложенный мной метод — безусловно не идеален (идеальных методов вообще не бывает). На счет анализа коллакаций (если я правильно понимаю значение этой фразы) — я задумывался над этой темой (и даже нашел логическое и техническое решение) — но не стал нагружать индекс еще одним полем (некий номер слова от начала строки). В общем при разбиении строки на слова — мы получаем массив, и по большому счету, индекс каждого элемента этого массива = номер слова в предложении, и можно проверять при поиске, если в каком либо материале найденные по запросу слова стоят близко друг к другу (как в изначальном запросе пользователя) — увеличивать релевантность данного материала.
Этот подход более нагруженный (в индексе будут храниться дубликаты слов + дополнительные проверки при поиске + суммирование весов слов не при индексации, а при поиске).
За идеи — спасибо большое, возьму на заметку, о некоторых вещах — даже не задумывался. Но на постгресс переходить пока не думал, да и проект у меня не под поиск заточен, основное для меня — комьюнити…
Да, в индексе хранятся все уникальные слова по каждой странице. Вес каждого слова считается не только от частоты использования, но и от места его расположения (слово в заголовке получит бОльший вес, чем слово из комментария к материалу). Что касается объемов базы — от размера сайта конечно зависит, в теории может и до миллионов вырасти, но если построить индексы, как предлагается — проблем быть не должно…
А будет ли третья часть? С нетерпением жду!
Помню, как работая над внутренним приложением одного из крупнейших российских банков — приходилось переносить системный блок в другую часть здания, чтобы попасть в нужную подсеть и получить нужный ответ от сервиса.
Вероятно, можно будет подумать и над решением этой проблемы, в дальнейшем…
Касательно экзотических кейсов, вы имеете в виду, что сложно в браузере воспроизвести такой кейс?
Этот подход более нагруженный (в индексе будут храниться дубликаты слов + дополнительные проверки при поиске + суммирование весов слов не при индексации, а при поиске).
За идеи — спасибо большое, возьму на заметку, о некоторых вещах — даже не задумывался. Но на постгресс переходить пока не думал, да и проект у меня не под поиск заточен, основное для меня — комьюнити…