Size: a a a

Django [ru] #STAY HOME

2019 September 14

T

Tim in Django [ru] #STAY HOME
Mihail
вообщем-то я думаю, что если на уровне админки сразу все лишние поля отсеивать в InlineModelAdmin, то не должно проблем с несколькими введёнными полями возникнуть. Но на всякий случай проверку, конечно, неплохо было бы сделать
так, ты можешь просто исключить эти поля)
источник

T

Tim in Django [ru] #STAY HOME
Mihail
вообщем-то я думаю, что если на уровне админки сразу все лишние поля отсеивать в InlineModelAdmin, то не должно проблем с несколькими введёнными полями возникнуть. Но на всякий случай проверку, конечно, неплохо было бы сделать
ну и всегда метод save можно переписать)
источник

M

Mihail in Django [ru] #STAY HOME
Tim
так, ты можешь просто исключить эти поля)
Я же вроди как это и написал. Или имелось ввиду исключать не на уровне админки?
источник

T

Tim in Django [ru] #STAY HOME
Mihail
Я же вроди как это и написал. Или имелось ввиду исключать не на уровне админки?
мне показалось, что ты имеешь ввиду blank=True, я имею ввиду exclude в inline, при это в модели надо добавить null=True
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
у тебя есть некоторая модель данных, если её можно сломать, сломав админку и только - это плохая архитектура потому что админка берёт на себя слишком много, это не её задача обеспечивать проверку целостности данных
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
у тебя есть некоторая модель данных, если её можно сломать, сломав админку и только - это плохая архитектура потому что админка берёт на себя слишком много, это не её задача обеспечивать проверку целостности данных
разумеется, из этого не следует, что люди так не делают :-) просто на выходе получаются "макароны" и замена админки на какую-нибудь другую приведёт к багу со структурой, сэкономишь время сейчас, всецело положившись на админку - получишь грабли потом)
источник

M

Mihail in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
разумеется, из этого не следует, что люди так не делают :-) просто на выходе получаются "макароны" и замена админки на какую-нибудь другую приведёт к багу со структурой, сэкономишь время сейчас, всецело положившись на админку - получишь грабли потом)
ну вообщем-то да. Я думаю, что делать проверку в save() это более ли менее здравая идея... Правда внедрять её уже буду при возникновении проблем с моей моделью
источник

M

Mihail in Django [ru] #STAY HOME
Давайте я вам, наверное, опишу задачу подробнее. Всё таки интересно было бы узнать ваше мнение, действительно ли такая архитектура оправдана в моём случае.
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
да, разумеется, для этого и чатик)
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Mihail
ну вообщем-то да. Я думаю, что делать проверку в save() это более ли менее здравая идея... Правда внедрять её уже буду при возникновении проблем с моей моделью
я не сторонник толстых моделей (и переопределения save() ) - это приведёт к сильной зависимости от Django ORM, к более сильной, чем могло бы быть, будь эта логика отдельно в файле services.py
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
я сторонник тонких вьюшек и моделей и помещения всего кода с бизнес-логикой отдельно в services.py
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
этот подход гуглится по словам Django API Domains, там не только про это, но и про это тоже
источник

M

Mihail in Django [ru] #STAY HOME
Есть модель Partner. Это что-то вроде физ.лица. У него может быть компания, соответственно связь с моделью Company, которой может и не быть.

Во время создания заказа в админке менеджер выбирает, формировать инвойс на физ.лицо или же на юр.лицо. Кроме того он выбирает, на какой счёт компании, или же на какой счёт владельца компании как частного лица нужно будет переводить деньги.

Я думаю, что самое адекватное в таком случае это ссылка через одно только поле recipient_of_money = ForeignKey(PaymentInfo) с конкретной информацией о плательщике.

Как у физ.лица так и у юр.лица может быть разная платёжная информация PaymentInfo

Получателем может быть не сама компания, которая выдаёт инвойс, а та, перед которой у неё долг (в т.ч. это может быть обычный Partner, т.е. физ.лицо).

Исходя из всех вышесказанных условий я сделал вывод, что самым оптимальным вариантом, это сделать в PaymentInfo одновременно ссылки на Company и на Partner через ForeignKey(blank=True). А в recipient_of_money выбирать кошелёк, на который отправлять в ручную с помощью django-autocomplete
источник

M

Mihail in Django [ru] #STAY HOME
Небольшое дополнение. Один и тот же Partner может быть как поставщиком, так и клиентом.
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Mihail
Есть модель Partner. Это что-то вроде физ.лица. У него может быть компания, соответственно связь с моделью Company, которой может и не быть.

Во время создания заказа в админке менеджер выбирает, формировать инвойс на физ.лицо или же на юр.лицо. Кроме того он выбирает, на какой счёт компании, или же на какой счёт владельца компании как частного лица нужно будет переводить деньги.

Я думаю, что самое адекватное в таком случае это ссылка через одно только поле recipient_of_money = ForeignKey(PaymentInfo) с конкретной информацией о плательщике.

Как у физ.лица так и у юр.лица может быть разная платёжная информация PaymentInfo

Получателем может быть не сама компания, которая выдаёт инвойс, а та, перед которой у неё долг (в т.ч. это может быть обычный Partner, т.е. физ.лицо).

Исходя из всех вышесказанных условий я сделал вывод, что самым оптимальным вариантом, это сделать в PaymentInfo одновременно ссылки на Company и на Partner через ForeignKey(blank=True). А в recipient_of_money выбирать кошелёк, на который отправлять в ручную с помощью django-autocomplete
в одном из проектов нечто подобное сделано через выделение аккаунта и проверка связи пользователь-аккаунт или организация-аккаунт через check
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
class Migration(migrations.Migration):


   dependencies = [
       ...,
   ]

   operations = [
       migrations.RunSQL(
           """
           ALTER TABLE table ADD CONSTRAINT user_or_organization CHECK (
               (user_id is null) != (organization_id is null)
           );
           """,
           """
           ALTER TABLE table DROP CONSTRAINT user_or_organization;
           """
       ),
   ]
источник

ПГ

Павел Гиль in Django [ru] #STAY HOME
Всем привет! Вопрос к ветеранам или кто активно работал с удаленной машиной. Проблема вот в чем, настроил удалённую машину, nginx, gunicorn, все работало, после того, как отключился от машины, при повторном подключении: mosh log@IP
Долго думает и выдаёт такую ошибку:
ssh_exchange_identification: Connection closed by remote host

/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).
Хочу заметить, что фаилы с конфигурацией на своём пк я не трогал. Вопрос активно гуглил, нашёл такую же проблему, но там сказано, что проблема в самом сервере. У кого какие идеи? За ранее спасибо
источник

M

Mihail in Django [ru] #STAY HOME
Alexander Ovchinnikov 🦁
в одном из проектов нечто подобное сделано через выделение аккаунта и проверка связи пользователь-аккаунт или организация-аккаунт через check
Ну то есть идея с двумя полями ForeignKey(blank=True) адекватная в моём случае?
источник

AO

Alexander Ovchinnikov 🦁 in Django [ru] #STAY HOME
Mihail
Ну то есть идея с двумя полями ForeignKey(blank=True) адекватная в моём случае?
она адекватная с constraint'ами и/или с другими проверками, а если эти проверки запихнуть только в админку - это не очень хорошо)
источник

M

Mihail in Django [ru] #STAY HOME
По сути главная проблема из-за чего я так делаю, чтобы менеджеру системы было удобно только лишь в одном поле выбрать информацию о кошельке, куда отправлять деньги клиенту.
источник