>>Если запрос это питоновская функция, которая возвращает питоновский set...
Сама по себе "питоновская функция" не вызывает особых возражений. В конце концов плюсов в ней гораздо больше, чем минусов.
Трудности проистекают из формы передаваемых ей аргументов и то что из порядка их записи в-общем не следует порядка их исполнения.
В строке например: hasDomain=groupby==check(label=icontains("capacity") check, насколько я понимаю, исполняется "сначала", а groupby имеет эффект "потом".
А если у аргумента имеется модификатор out, то он исполнится в финале, вне зависимости от того, где расположен.
И такие незначительные-по-отдельности нарушения порядка имеют вредный кумулятивный эффект, когда запросы приходится читать глазами. "проверено на кошках".
>> 4. Сомневаюсь по поводу "неминуемого расширения".
Наверняка же рано или поздно будут реализованы вещи типа type != part2.Classification или использования regex наподобие icontains.
В движке используется оптимизацию поиска по индексу. Ну не будем же мы на каждый hasClassifier=uri1 гонять full scan. Как в имплементациях SQL, план запроса не является тупым соответствием последовательности условий.
Для пользовательской оптимизации плана запроса доступен check. Правила такие: 1. Внутренний find сработает только один раз перед обработкой внешнего find/check, но на полном графе (с возможным использованием индекса). 2. Внутренний check сработает столько раз, сколько надо будет отфильтровать прошедшие по другим критериям сущности, проверка, без индекса, но каждый раз именно для одной сущности-кандидата.
Над проектом сейчас работают профессионалы. Когда можно - дописывают, когда не дописывается - переписывают ещё лучше. Всё будет ок.
Comments 3
Reply
Сама по себе "питоновская функция" не вызывает особых возражений. В конце концов плюсов в ней гораздо больше, чем минусов.
Трудности проистекают из формы передаваемых ей аргументов и то что из порядка их записи в-общем не следует порядка их исполнения.
В строке например:
hasDomain=groupby==check(label=icontains("capacity")
check, насколько я понимаю, исполняется "сначала", а groupby имеет эффект "потом".
А если у аргумента имеется модификатор out, то он исполнится в финале, вне зависимости от того, где расположен.
И такие незначительные-по-отдельности нарушения порядка имеют вредный кумулятивный эффект, когда запросы приходится читать глазами. "проверено на кошках".
>> 4. Сомневаюсь по поводу "неминуемого расширения".
Наверняка же рано или поздно будут реализованы вещи типа type != part2.Classification
или использования regex наподобие icontains.
Reply
Для пользовательской оптимизации плана запроса доступен check. Правила такие:
1. Внутренний find сработает только один раз перед обработкой внешнего find/check, но на полном графе (с возможным использованием индекса).
2. Внутренний check сработает столько раз, сколько надо будет отфильтровать прошедшие по другим критериям сущности, проверка, без индекса, но каждый раз именно для одной сущности-кандидата.
Над проектом сейчас работают профессионалы. Когда можно - дописывают, когда не дописывается - переписывают ещё лучше. Всё будет ок.
Reply
Leave a comment