T
почему migrate —fake может не работать?
создал дата-миграцию, применил, теперь хочу заново дата-миграцию запустить.
делаю так
manage.py migrate —fake appname 0008
manage.py migrate
в ответ получаю : No migrations to apply.
Size: a a a
2019 August 24
DT
потому что 008 уже применена
DT
—fake не вносит изменения в базу
но помечает миграцию как примененую
но помечает миграцию как примененую
A
или просто пересоздай дб с utf8
Нее, не пересгхдаеь с utf8. На локали ругается. сейчас буду пробовать локали настраивать
A
Спасибо
T
—fake не вносит изменения в базу
но помечает миграцию как примененую
но помечает миграцию как примененую
а, понял. нужно указать предыдущую миграцию, и тогда удалит запись, о том, что 0008 применена
DT
а, понял. нужно указать предыдущую миграцию, и тогда удалит запись, о том, что 0008 применена
да
НС
Всем привет. Такой вопрос что за формат времени вот так хранится 2019-05-19T00:00:00+00:00 что мне гуглить и какой field использовать для хранения этого значения в postgresql ?
AT
Всем привет. Такой вопрос что за формат времени вот так хранится 2019-05-19T00:00:00+00:00 что мне гуглить и какой field использовать для хранения этого значения в postgresql ?
AT
у тебя сервис на rest-api ?
AT
если да, то сериалайзер сам все конвертирует как надо
EC
Тут так всё выглядит, будто тебе нужен ещё один уровень абстракции. Скажем, модель Actor, которая может размещать посты и от которой наследуют это свойство User и Group.
не понял можно подробнее плз
НС
у тебя сервис на rest-api ?
У провайдера вроде rest
AT
щито, какой еще провайдер
AT
Тут так всё выглядит, будто тебе нужен ещё один уровень абстракции. Скажем, модель Actor, которая может размещать посты и от которой наследуют это свойство User и Group.
причем тут "уровень абстракции", если ты описываешь декомпозицию...
ББ
причем тут "уровень абстракции", если ты описываешь декомпозицию...
У человека две модели, для юзера и для группы, имеющие одну и ту же способность — быть авторами поста. Я предлагаю их объединить под эгидой единого более общего актора. Кажется, абстракция налицо.
EC
У человека две модели, для юзера и для группы, имеющие одну и ту же способность — быть авторами поста. Я предлагаю их объединить под эгидой единого более общего актора. Кажется, абстракция налицо.
ну это да это я допустим создам абстрактный класс и от него унаследуюсь двумя моделями , но разве можно ФК на абстрактный класс писать ?
💊
ну это да это я допустим создам абстрактный класс и от него унаследуюсь двумя моделями , но разве можно ФК на абстрактный класс писать ?
я бы в модели просто 2 форейнкей сделал с нулл, и для удобства можно геттер сделать author - который подтягивает модель из непустого ключа
ББ
ну это да это я допустим создам абстрактный класс и от него унаследуюсь двумя моделями , но разве можно ФК на абстрактный класс писать ?
Низя. Можно зато пронумеровать всех акторов и по АйДи методом вытаскивать. Короче, все варианты костылированные, один GenericForeignKey дефолтный, да и тот не оч.
mc
Низя. Можно зато пронумеровать всех акторов и по АйДи методом вытаскивать. Короче, все варианты костылированные, один GenericForeignKey дефолтный, да и тот не оч.
почему не оч? вполне годный вариант, по-моему