MA
if obj.level == 2:типа такого
return ('foo', 'bar')
return super().get_fields()
fields = super().get_fields()
fields["foo"] = foo
return fields
Так не работает?
Size: a a a
2019 August 08
Так не работает?
DT
То есть если у меня в моделях у модели поста контент сделан в виде models.TextField - он все равно будет работать?
после смены да
когда поменяешь код
посмотри какая будет миграция
когда поменяешь код
посмотри какая будет миграция
DT
если не разберешься покажешь
VA
после смены да
когда поменяешь код
посмотри какая будет миграция
когда поменяешь код
посмотри какая будет миграция
Окей :)
S
после смены да
когда поменяешь код
посмотри какая будет миграция
когда поменяешь код
посмотри какая будет миграция
ты с логами cpython profiler работал?
VA
Спасибо!
DT
там есть вероятность что миграции вообще не будет
DT
ты с логами cpython profiler работал?
нет
VA
там есть вероятность что миграции вообще не будет
Ну если я оставлю текстовое поле - то не будет. Оно ж там и так есть.
А если вместо него вкорячу РичТекстФилд - то может быть.
Если я тебя верно понял.
А если вместо него вкорячу РичТекстФилд - то может быть.
Если я тебя верно понял.
TD
Ну там не обычное текстовое поле. А своё.
Тобишь базу перелопатить надо.
Тобишь базу перелопатить надо.
1. Поле из ckeditor, скорее всего, надстройка над обычным текстовым. Т.е. даже если класс поля поменять, базу миграция трогать не будет.
2. Насколько я помню, там была возможность переопределить поле в форме, не трогая модель - если так уж не хочется этого делать.
2. Насколько я помню, там была возможность переопределить поле в форме, не трогая модель - если так уж не хочется этого делать.
VA
1. Поле из ckeditor, скорее всего, надстройка над обычным текстовым. Т.е. даже если класс поля поменять, базу миграция трогать не будет.
2. Насколько я помню, там была возможность переопределить поле в форме, не трогая модель - если так уж не хочется этого делать.
2. Насколько я помню, там была возможность переопределить поле в форме, не трогая модель - если так уж не хочется этого делать.
Мне не сложно даже базу пересоздать. Просто если этого можно избежать - так и хочется )
DT
Ну если я оставлю текстовое поле - то не будет. Оно ж там и так есть.
А если вместо него вкорячу РичТекстФилд - то может быть.
Если я тебя верно понял.
А если вместо него вкорячу РичТекстФилд - то может быть.
Если я тебя верно понял.
в том то и дело
когда поменяешь content на ReachField
то миграции может не быть вообще
когда поменяешь content на ReachField
то миграции может не быть вообще
VA
в том то и дело
когда поменяешь content на ReachField
то миграции может не быть вообще
когда поменяешь content на ReachField
то миграции может не быть вообще
Понял тебя) попробую
RA
Всем привет) у нас ситуация где нужно создать 4 типа users, для каждого юзера есть отдельные атрибуты (1 тип юзера админский, даем доступ к админ панели с ограниченным доступом к модели) Какую архитектуру нужно использовать??? Я думаю нужно переписать AbstractUser и добавить атрибут «тип», потом использовать профиль. Как вам идея?
KA
fields = super().get_fields()
fields["foo"] = foo
return fields
Так не работает?
спасибо, но как достучаться до obj в методе get_field_names()?
KA
нашел спасибо)
DT
Всем привет) у нас ситуация где нужно создать 4 типа users, для каждого юзера есть отдельные атрибуты (1 тип юзера админский, даем доступ к админ панели с ограниченным доступом к модели) Какую архитектуру нужно использовать??? Я думаю нужно переписать AbstractUser и добавить атрибут «тип», потом использовать профиль. Как вам идея?
Отличие между типами только в одном поле?
RA
Отличие между типами только в одном поле?
Нет, 4-5
DT
Тогда возможно имеет смысл делать одну модель для пользователя и по одной модели на роль с связью o2o к пользователю
RA
Одну модель для пользователя тогда нужно создать как AbstractUser чтоб добавить атрибут type и переписать метода как save итд?