ZAN
Март 17, 2016 11:50:25
Добрый день всем.
Возможно, кто-то уже читал про этот небольшой проектик на хабре
https://habrahabr.ru/post/263821/. В любом случае, кому-то эта библиотека оказаться весьма полезной.
Страница проекта на гитхабе -
https://github.com/Nepherhotep/django-orm-sugarДля ленивых - библиотека добавляет синтаксического сахара (по сути - питоновского синтаксиса) при создании запросов через джанговскую ORM. Используя ее, вместо underscored синтаксиса
>>> SomeModel.objects.filter(user__profile__common_bucket__seq_count__gte=7)
можно использовать питоновские операторы сравнения
>>> SomeModel.objects.filter(Q.user.profile.common_bucket.seq_count >= 7)
В примере выше оператор сравнения просто возвращает Q объект, который дальше применяется в фильтре:
>>> Q.user.age < 7
Q(user__age__lt=7)
При этом старый способ инициализации Q объектов также работает, так что существующий код не сломается:
>>> Q(user__age__lt=7)
Q(user__age__lt=7)
Из нового - добавил поддержку сравнения элементов по индексу и слайсы (для тех, кто использует постгресовские ArrayField и JSONField):
>>> Q.data.owner.other_pets[0].name='Fishy'
Q(data__owner__other_pets__0__name='Fishy')
>>> Q.tags[0] == 'thoughts'
Q(tags__0='thoughts')
>>> Q.tags[0:2].contains(['thoughts'])
Q(tags__0_2__contains=['thoughts'])
Полное описание возможностей смотрите на гитхабе.
ayb
Март 17, 2016 12:22:30
Сколько сахара в говно не добавляй - лучше оно от этого не станет.
JOHN_16
Март 17, 2016 14:12:09
ayb
4kpt_IV
Отставить холиварные высказывания в данном топике.
:)
ayb
Март 17, 2016 18:00:54
Ну так а в чем смысл библиотеки ? Зачем она нужна. Кто ей будет пользоваться ? Какой профит от ее использования ?
ZAN
Март 17, 2016 18:19:15
ayb для дальнейшей с вами дискуссии не самое было удачное начало
JOHN_16
Март 17, 2016 19:43:31
ayb
смысл понятен - многих банально раздражает система нижних подчеркиваний, тут же библиотека приводит к привычному виду тривиальные действия.
Вот кто это будет пользовать - вот тут согласен. Возможно это разработчикам Django показать надо =)
ayb
Март 17, 2016 20:25:45
ZAN
для дальнейшей с вами дискуссии не самое было удачное начало
Нет, простите, это форум и я могу высказывать свое мнение. Мое мнение отличается от Вашего ? Ну ничего страшного, так бывает.
JOHN_16
смысл понятен - многих банально раздражает система нижних подчеркиваний
Проводились какие-то исследования ? Я как раз думаю наоборот - многим просто пофиг на эти подчеркивания. Это из примерно из той же оперы как и получение значения ключа в словаре через точку ( как атрибут ). Ну вроде бы прикольно, некоторые так даже делают, но смысла в этом никакого нет.
Итого : ТС написал библиотеку, которая по факту - не улучшает производительность ( по факту даже немножко её снижает, но это можно опустить ) и не улучшает читаемость ( но это субъективное мнение ). При этом отказывается ответить на вполне нормальные вопросы.
ZAN
Март 17, 2016 20:32:35
JOHN_16
У подхода с подчеркиваниями есть следующие проблемы:
главная проблема - нарушение принципа DRY. Если делается сложный запрос, то из-за того, что параметр передается, как keyword, его нельзя использовать заново (к примеру, если нужно сортировать по тому же полю). Проблема вторая - легко ошибиться с количеством подчеркиваний, особенно, если внутри самих полей есть подчеркивания. Третья проблема концептуальная - если я хочу отфильтровать поля, сравнивая со значением, то зачем использовать lookup expression “eq”, “gt” и т.д., если в питоне есть операторы? Ведь код - это своего рода история, если я хочу описать “больше или равно”, то в питоне есть для этого оператор “>=”, и по идее не нужно запоминать, какой lookup expression придумали разработчики джанги - “ge” или все-таки “gte”. Особенно это заметно для последних нововведений - сравнение, используя индексы или срезы - Q(tags__0_3__contains=) выглядит не очень презентабельно. Ни подсветка синтаксиса, ни мой внутренний парсер питона не умеет определять такие конструкции сходу, что усложняет чтение кода.
Касательно того, кто это будет использовать - да кто угодно, кто согласен с моими аргументами.
На счет разработчиков джанги - да, я обсуждал это в группе. Там захотели более общий подход, а не просто конвертация запроса в Q объект. Дело в том, что в джанге идет уход от кейвордов к созданию объектов, определяющих SQL запрос (примеры - относительно новый Expression API, Prefetch объекты и т.д.). Для внедрения полноценного синтаксиса от Django ORM Sugar, нужно реализовать поддержку методом filter специального класса (один из вариантов - класса, поддерживающего Expression API). Тогда бы вместо filter(username='Вася'), можно будет передать спец объект filter(Exact('username', ‘Вася’)). Вся хитрость в том, что такие объекты можно будет легко генерировать динамически подобно тому, как это сделано в Django ORM Sugar. Разница, возможно, не такая уж и большая, однако такой подход сделает Django ORM:
1. Более гибким - можно будет делать запросы, для каких вообще не существует соответствующих lookup expressions
2. Более простым, т.к. уже на данный момент код, разбирающий keywords на поля и lookup expression довольно сложен.
У меня была попытка сделать пул реквест, но никак не получалось решить один очень хитрый тест кейс, связанный с .exclude() вызовом, если в нем фильтруются ForeignKey. В принципе, может я его и доработаю когда-нибудь, но сейчас руки до этого не доходят.
