МП
select_related('u__c')
Size: a a a
2019 July 18
А
так в том и дело, куда этот select_related присобачить?
МП
Сам не оптимизировал так, где-то middleware нужно копать
МП
которая вытягивает юзера при реквесте
МП
Ее переопределять на кастомную
МП
там select_realted
А
при ForeignKey, я бы запросил b = B.objects.filter().select_related("c")
а тут у меня b не запрашивается. а сразу есть, это же OneToOne, т.е. сразу дергается request.user.b
а тут у меня b не запрашивается. а сразу есть, это же OneToOne, т.е. сразу дергается request.user.b
МП
Все там вытягивается, ищи где тянется юзер при реквесте, пиши миддлваре. Потом кидай сюда как решил в итоге
А
да я вот и думаю, оставить ForeignKey или переписывать под OneToOne, стоит ли вообще с таким гемором
МП
Не стоит
А
похоже на то, просто думал, вдруг для OneToOne тоже есть возможность при первом взятии как-то указывать select_related
S
@dantyan а ты с mptt работал?
DT
S
да
сейчас вопрос тогда сформулирую)
S
подскажите пожалуйста, как корректнее работать с Model.objects.get, если значение для поиска может быть некорректным? только через Model.objects.filter?
А
подскажите пожалуйста, как корректнее работать с Model.objects.get, если значение для поиска может быть некорректным? только через Model.objects.filter?
в каком смысле некорректным?
V
подскажите пожалуйста, как корректнее работать с Model.objects.get, если значение для поиска может быть некорректным? только через Model.objects.filter?
Model.objects.filter(lookupvalue__iexact='')
S
в каком смысле некорректным?
ну, несуществующее например
А
по мне так filter с проверкой на None лучше, get с try - огромные накладные на обработку исключения
S
по мне так filter с проверкой на None лучше, get с try - огромные накладные на обработку исключения
вот я тоже так думаю