Как сделать привязку сохранения модели к изменению другой модели?

Question

[Игорь]

Добрый день! Есть модель Item. Нужно, чтобы когда создаётся экземпляр модели TakenItem у модели Item из поля number вычиталось какое-либо количество вещей (зависит от TakenItem'а). Сначала хотел реализовать это при помощи сигналов сохранения для моделей, однако потом понял, что если, к примеру, у Item'а поле number уже 0, то его вычитание ведёт к отрицательному числу, что не правильно.
Вопрос: как сделать так, чтобы при создании TakenItem'а если поле number у Item'а ненулевое, то объект создавался, а у number'а уменьшалось значение на переданное в создании TakenItem'а.
Спасибо.

Post Scriptum

P.S. Кто-нибудь может ответить, что решается это простым добавлением метода takeItem к модели Item, в котором всё и проверяется. Однако этот вариант не подходит, так как мне нужно, чтобы это работало ещё и в админке, при этом горожение огородов в самой админке (вызов takeItem'а вместо простого редактирования поля) кажется для меня костылём. Я бы хотел, чтобы это реализовывалось на уровне самой модели, прозрачно для внешнего взаимодействия.

Comments

[sim3x]

Похоже, что у вас неправильная схема БД

Если не хотите морочиться, то у джанги есть PositiveIntegerField и def save

[Игорь]

sim3x, а в чем она не правильна, и как тогда сделать это некостыльно?

[sim3x]

Игорь, Для начала нужно описать задачу и цели

[Игорь]

sim3x, я думал, это не важно в рамках решения данного вопроса.
Цель — учёт деталей на складе и запись того, кто, когда, сколько и чего забрал.
Item — модель одного наименования, включает количество всего и количество взятых предметов, также обладает категорией (ForeignKey).
TakenItem — описывает взятую вещь, ссылается на Item, обладает количеством и User'ом из стандартного Auth'а.

[sim3x]

Игорь, если вам не важно, что детали будут теряться, то да

Item расходники?

[Игорь]

sim3x, вы имеете в виду, предполагается ли возврат, или нет? Если да, то и да и нет, то есть в случае "расхода" убавляется общее количество у Item'а и удаляется запись из TakenItem.

[sim3x]

Игорь,
0. Я б разделил расходники и инструменты
1.

Item:
 name
 json_with_charachteristics

ItemUser:
 user
 item
 count
 datetime

и при каждом обновлении считаем count для каждого айтема перед обновлением
Тогда при race condition будете понимать, что и когда пошло не так и сможете откатить

[Игорь]

@sim3x
0. Вы имеете в виду, в разные модели?
1. Для чего модель ItemUser, для записи взятых айтемов? Об обновление чего идёт речь, об обновление полей? Немного не понял, как там будет race condition.

[sim3x]

Игорь,
0. Да
1. для записи взятый айтемов

об обновление чего идёт речь, об обновление полей?

при вставке нового значения

Немного не понял, как там буклет race condition.

Два юзера взяли по одному айтему при остатке 1

[Игорь]

sim3x, скажите, в принципе ведь никого костыля нет в def save, просто определение поведения модели?

[sim3x]

Игорь, я не совсем понимаю, что вы хотите спросить

[Игорь]

sim3x, просто вы написали в первом комменте, что костылем было бы использовать def save, почему?

[sim3x]

Игорь,
Потому что в данном случае можно потерять информацию
В случае бложика для моно пользователя - save - отличное решение
Для решения, в котором требуется отчетность и есть больше одного пользователя - save нужно использовать очень осторожно

Возможно ето преувеличение с моей стороны было использовать слово "костыль" по отношению к стандартному апи орм

[Игорь]

sim3x, спасибо большое, что потратили на меня время и помогли!

Answer 1

[tema_sun]

Можно, например, оверрайднуть метод save() у TakenItem, или выкинуть эксепшн в pre_save сигнале.

Comments

[Игорь]

или выкинуть эксепшн в pre_save сигнале

tema_sun, честно говоря, не знаю, как поведёт себя Django при каком-то левом исключении, я имею в виду что увидит пользователь в браузере, не завершится ли процесс Python с Django вообще?