в том, что люди изменяют данные, без понимания всего маханизма.
инструкции типа:
self.env['fucked.model'].sudo().search([]).write({'fucked_field': some_val})
чуть лучше чем SQL UPDATE,DELETE
но они могут быть не менее разрушительны чем SQL
не в SQL инструкция проблема и не в .search([]).write({...
а в непонимании последствий.
Я вообще не противник, ни SQL UPDATE, ни .search([]).write({...
я за то, чтобы сначала понять: а ничего ли это не зацепит?
А для этого нужно понимать весь механизм.
Если ты понимаешь весь механизм, то SQL тебе в помощь. Я вообще не против. Понимаешь?
А если разраб не понимает, то лучше просто использовать стандартные функции.
Есть например модель Инвентаризация, и в ней есть методы, которые проводят списание. Ну так бери их и используй.
Для этого даже не нужно понимать весь механизм.
За то в результате такого подхода - гарантировано ничего не сломаешь и гарантировано получишь нужный тебе результат.
Просто проблема в том, что чтобы вызвать нужные функции, нужно понять какие параметры ей нужны.
А разрабам проще кодить search([]).write({...
чем разбираться как вызвать нужную функцию.
А ее еще найти нужно в коде среди тысяч других функций!
А разрабы просто не знают где искать!
Вот дали задание молодому разрабу - списать весь товар,
а он не знает, что в оду есть документ Инвентаризация... и всё... вот тут начинаются извращения...
А знал бы он про Инвентаризацию, сделал бы документ, поставил точку останова в функции validate, посмотрел бы как вызывается функция, списывающая товар, да написал бы либо свой визард, либо скрипт... понимаешь о чем я?
Я вообще не понимаю людей, которые меняют данные в базе, вместо того, чтобы вызвать нужные функции.
Конечно иногда это нужно. Но мне кажется - это прям очень редко когда надо.
Более того, если бы ты сделал через Инвентаризацию,
то у тебя бы была возможность потом ее отменить или откорректировать в ней данные, докидать товары и пр.
Плюс наглядно открыл документ и глазами видишь что было списано, какого числа, в каком количестве с каких складов,...
А скрипт прошелся по данным и все - концов не сыщешь. А юзеры людят лезть в старые периоды и там что-то меня.
Залезут, докинут товара, и у тебя снова на остатках на 1-е число есть товар. Что ты будешь делать? Снова скрипт свой запускать?
А как твой скрипт узнает остатки именно на число Х? Ты ж скорее всего написал скрипт, который списывает на сейчас все что есть.
Пройдет месяц, После даты списания остатков появятся новые документы, которые нельзя будет трогать... придется усовершенствовать твой скрипт, чтобы он определял остатки именно на Дату... тебе надо эти проблемы?
Не понимаю я людей. Ради чего лезть в базу? Чтобы что-то себе доказать? Или чтобы быстрее задачу закрыть, а потом хоть трава не расти? Вообще не понимаю...
> Более того, если бы ты сделал через Инвентаризацию, Я работаю с Odoo 15, там похоже отличается от того, что было в ранних версиях (а я не изучал как склад работал на предыдущих версиях). В Оду 15 инвентаризация работает с квантами, и создает передвижения продукта с/на виртуальный склад Inventory Adjustments. Поэтому я точно делаю через Инвентаризацию :)
Там еще нужно не забывать, что инвентаризация, а точнее оприходование и списание, также делают движения пл финансам (account.move.line) и пл аналитическийюм счета (account.analytic.line,если не ошибаюсь в написании) в зависимости от настроек и установленных модулей. Так что если аккаунтинг включён, то тоже обратите на это внимание.
Обсуждают сегодня