DT
при создании тикета
руками создавай запись в АпдейтТикет и Файл
руками создавай запись в АпдейтТикет и Файл
при создании тикета
руками создавай запись в АпдейтТикет и Файл
Size: a a a
2019 February 06
p
в def validate(self, data) в сериализаторе норм будет?
DT
я бы в update или create сериализатора или въюхи сделал
p
или save в модели
p
ок поковыряем , спасибо
DT
в save модели не будет доступа request
NK
@alxndrP будет жить. Поприветствуем!
NK
@asdfg628 будет жить. Поприветствуем!
СГ
че-т я запутался. Вот у меня есть класс для постов, класс для прикрепления к постам, при этом прикрепления могут быть разные - видео, фото - для каждого типа прикрепленных объектов - тоже свой класс.
При этом я хочу чтобы список прикреплений был у меня в общей таблице, без разделения по типам объектов. А в классе для каждого типа объекта делаю поле ссылающееся через ForeignKey на прикрепление-"оболочку" из общей таблицы. Т.е. это поле будет одинаковым для каждого типа, но храниться оно должно в таблицах, разделенным по типам. Так вот как это поле прописать не в каждой модели типа объекта, а только единожды, в модели "оболочки"?
При этом я хочу чтобы список прикреплений был у меня в общей таблице, без разделения по типам объектов. А в классе для каждого типа объекта делаю поле ссылающееся через ForeignKey на прикрепление-"оболочку" из общей таблицы. Т.е. это поле будет одинаковым для каждого типа, но храниться оно должно в таблицах, разделенным по типам. Так вот как это поле прописать не в каждой модели типа объекта, а только единожды, в модели "оболочки"?
DT
че-т я запутался. Вот у меня есть класс для постов, класс для прикрепления к постам, при этом прикрепления могут быть разные - видео, фото - для каждого типа прикрепленных объектов - тоже свой класс.
При этом я хочу чтобы список прикреплений был у меня в общей таблице, без разделения по типам объектов. А в классе для каждого типа объекта делаю поле ссылающееся через ForeignKey на прикрепление-"оболочку" из общей таблицы. Т.е. это поле будет одинаковым для каждого типа, но храниться оно должно в таблицах, разделенным по типам. Так вот как это поле прописать не в каждой модели типа объекта, а только единожды, в модели "оболочки"?
При этом я хочу чтобы список прикреплений был у меня в общей таблице, без разделения по типам объектов. А в классе для каждого типа объекта делаю поле ссылающееся через ForeignKey на прикрепление-"оболочку" из общей таблицы. Т.е. это поле будет одинаковым для каждого типа, но храниться оно должно в таблицах, разделенным по типам. Так вот как это поле прописать не в каждой модели типа объекта, а только единожды, в модели "оболочки"?
создай класс Attachment
от него сделай PhotoAttachment(Attachment)
это породит связь o2o между ними
и ты сможешь получать список всех атачей к посту
от него сделай PhotoAttachment(Attachment)
это породит связь o2o между ними
и ты сможешь получать список всех атачей к посту
СГ
создай класс Attachment
от него сделай PhotoAttachment(Attachment)
это породит связь o2o между ними
и ты сможешь получать список всех атачей к посту
от него сделай PhotoAttachment(Attachment)
это породит связь o2o между ними
и ты сможешь получать список всех атачей к посту
т.е. также я сделаю VideoAttachment(Atachment), и запрос Attachment.objects.all() выдаст queryset сформированный сразу из двух таблиц?
DT
не совсем
он сделает запро из Attachment
но из нее моешь обращаться
к полям из VideoAttachment
он сделает запро из Attachment
но из нее моешь обращаться
к полям из VideoAttachment
DT
как к своим
NK
@robox будет жить. Поприветствуем!
AD
Ребята, подскажите пожалуйста, как быть с миграциями, если для views используются forms, которые в свою очередь используют models?
на миграции выдает ошибку relation такой-то doesn't exist
я думал, это я накосячил, но почитал - люди часто сталкиваются с проблемой, судя по всему
одни чекают makemigrations, migrate в sys.argv, другие комментят все кроме моделей, но это все напоминает лютые костыли
на миграции выдает ошибку relation такой-то doesn't exist
я думал, это я накосячил, но почитал - люди часто сталкиваются с проблемой, судя по всему
одни чекают makemigrations, migrate в sys.argv, другие комментят все кроме моделей, но это все напоминает лютые костыли
DT
ни формы ни въюхи не влияют на миграции,
если только в них нет синтаксических ошибок
если только в них нет синтаксических ошибок
СГ
не совсем
он сделает запро из Attachment
но из нее моешь обращаться
к полям из VideoAttachment
он сделает запро из Attachment
но из нее моешь обращаться
к полям из VideoAttachment
а класс Atachment надо Abstract делать?
DT
проблема в relation значит у тебя конфликт имен
DT
а класс Atachment надо Abstract делать?
нет
MK
Пишу бекенд на DRF. Как обнаруживать проблему с лишними запросами в базу? Раньше юзал django debug toolbar. Он норм, но в drf не очень подходит.
Знаю, есть еще пара пакетов. Один в заголовках отдает эту инфу, другой через плагин к хрому работает. Это варианты, но не особо удобные.
Может есть какое-то решение получше?
Знаю, есть еще пара пакетов. Один в заголовках отдает эту инфу, другой через плагин к хрому работает. Это варианты, но не особо удобные.
Может есть какое-то решение получше?