Prevent trigger run twice and unit tests

[quote="Gres"]Как вы реализуете проверку на то, что ваш триггер не запустится больше 1 раза?
А если вам в тесте нужно сделать несколько DML операций и на каждое действие должен сработать триггер?[/quote]

1. Есть флаг в триггер диспатчере. Который предотвращает повторное срабатывание. но его можно сбросить.
2. Собственно все тоже самое и в тестах.

[quote="wilder"]1. Есть флаг в триггер диспатчере. Который предотвращает повторное срабатывание. но его можно сбросить. [/quote]
Отдельный флаг на каждый тип?
[quote="wilder"]2. Собственно все тоже самое и в тестах.[/quote]
Т.е. если тебе нужно обновить 100 записей, ты будешь его сбрасывать 100 раз?

+1 
Хотел тоже самое написать.
Только словами попроще :D 

[quote="Gres"]Отдельный флаг на каждый тип? [/quote]
Да флаг на каждое действие (триггер, кусок триггера)

[quote="Gres"]Т.е. если тебе нужно обновить 100 записей, ты будешь его сбрасывать 100 раз?[/quote]
100 записей апдейтятся пачкой или в цикле?

[quote="Dmitry Shnyrev"]100 записей апдейтятся пачкой или в цикле? [/quote]
Пусть последовательно.

[quote="Dmitry Shnyrev"]Да флаг на каждое действие (триггер, кусок триггера)[/quote]
И зачем вам столько флагов, если можно, например, сработавшие действяи хранить?

тогда да, перед каждой DML операцией сбрасывать флаг - а что тут сложного добавить одну строчку для изменения статической переменной?

[quote="Gres"]И зачем вам столько флагов, если можно, например, сработавшие действяи хранить?[/quote]
Что-то я не улавливаю твоей задумки.
Пример на пальцах можешь привести?

[quote="Dmitry Shnyrev"]тогда да, перед каждой DML операцией сбрасывать флаг - а что тут сложного добавить одну строчку для изменения статической переменной?[/quote]
Тогда, мне кажется, теряеся весь смысл, ведь может сработать какой-нить WF with field update, который запустит триггер еще раз.

[quote="Dmitry Shnyrev"][quote="Gres"]И зачем вам столько флагов, если можно, например, сработавшие действяи хранить?[/quote]
Что-то я не улавливаю твоей задумки.
Пример на пальцах можешь привести?[/quote][quote="Gres"]И зачем вам столько флагов, если можно, например, сработавшие действяи хранить?[/quote]

Именно так и работает. Но при этом для автоматической проверки есть стандартный метод. А флаг лишь один и он говорит что в конкретном месте не делать эту автоматическую провеку и все.

[quote="Dmitry Shnyrev"]Что-то я не улавливаю твоей задумки.
Пример на пальцах можешь привести? [/quote]
У тебя есть 7 и более Boolean переменных, так?
Я предлагаю использовать Set.

[quote="Gres"]Я предлагаю использовать Set.[/quote]
В принципе можно и так. Это всего лишь вариант хранения. 
Смысл же проверки и установки/сброса значений в триггере я думаю это не меняет.

[quote="Gres"]Я предлагаю использовать Set.[/quote]
Но за идею кстати спасибо. Отложу в памяти :) 

Т.е. если в одном контексте надо сделать несколько операции, вы так руками везде и выставляете ваш флаг?

[quote="Gres"]Т.е. если в одном контексте надо сделать несколько операции, вы так руками везде и выставляете ваш флаг?[/quote]

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

А так, мне толковых юз кейсов не попадалось с такой логикой.

[quote="Dmitry Shnyrev"]А так, мне толковых юз кейсов не попадалось с такой логикой.[/quote]
Допустим делаешь ты пакет, а у клиента куча WF, которые ломают тебе логику.

[quote="Gres"]Допустим делаешь ты пакет, а у клиента куча WF, которые ломают тебе логику.[/quote]
ВОТ! ты прямо в точку - именно с такой хренью я и боролся однажды.
Но вообще я уже даааавно не делаю пакеты. Говорю же что работаю напрямую с заказчиками или с небольшими стартапами которые еще до пакета не доросли.

[quote="Gres"]Т.е. если в одном контексте надо сделать несколько операции, вы так руками везде и выставляете ваш флаг?[/quote]

Да. Потому что он автоматически сбрасывается после проверки. М пока с таким поведением не было проблем.

И кстати если происходит множественная сработка триггера на одном объекте и на одной и той же операции, то скорее всего косяк в логике.

[quote="wilder"] то скорее всего косяк в логике.[/quote]
Меня все подмывало сказать это :D , но тут собрались уважаемые люди :D 

[quote="Gres"]Т.е. если в одном контексте надо сделать несколько операции, вы так руками везде и выставляете ваш флаг?[/quote]

DML Manager не пробовал использовать. Это спасает от множества проблем.

[quote="Dmitry Shnyrev"]Меня все подмывало сказать это  , но тут собрались уважаемые люди [/quote]

Логика вполне может быть клиентская и он не хочет ничего менять. И от программиста уже ничего не зависит.

[quote="Gres"]Допустим делаешь ты пакет[/quote]
Gres, а расскажи какой пакет ты сейчас пилишь, если это не коммерческая тайна.

[quote="wilder"]И кстати если происходит множественная сработка триггера на одном объекте и на одной и той же операции, то скорее всего косяк в логике.[/quote]
Я же писал выше, что пишу тесты, и чтобы проверить одну из ситуаций, мне надо создать и обновить несколько объектов. Думал, вы может что-то подскажете, а сброс флага у меня и так был.

[quote="Dmitry Shnyrev"]Gres, а расскажи какой пакет ты сейчас пилишь, если это не коммерческая тайна.[/quote]
Это пакет для одного клиента.

[quote="wilder"]DML Manager не пробовал использовать. Это спасает от множества проблем.[/quote]
У меня написана похожая обертка над DML операциями, если ты про https://github.com/patronmanager/apex-dml-manager

[quote="Gres"]рос флага у меня и [/quote][quote="Gres"]У меня написана похожая обертка над DML операциями, если ты про https://github.com/patronmanager/apex-dml-manager[/quote]

Да. Примерно такая обертка. только у нас исползуется еще один метод для накопления объектов а потом их разовая вставка в базу.

[quote="wilder"]только у нас исползуется еще один метод для накопления объектов а потом их разовая вставка в базу.[/quote]
Да, у меня тоже есть [url=http://martinfowler.com/eaaCatalog/unitOfWork.html]Unit Of Work[/url]

[quote="Gres"]Unit Of Work[/quote]
О! помню такую штуку на одном проекте.
Только гемора кучу добавляло - профита 0!

Проще было сложить объекты в list и передать лист в dml чем вспомнить как эту хрень инициализировать и заставить работать. Кстати на том проекте была еще и <Object>Selector (вроде того же автора) - тоже блин сука головная боль. Короче любите вы себе и другим жизнь усложнять своими абстракциями. Все равно рано или поздно на проект придут такие парни как Я и сломают вашу красоту :D 

Вроде отсюда это пришло
https://github.com/financialforcedev/fflib-apex-common

[quote="Dmitry Shnyrev"]Короче любите вы себе и другим жизнь усложнять своими абстракциями.[/quote]
Вечный холивар.

[quote="Dmitry Shnyrev"]Вроде отсюда это пришло
https://github.com/financialforcedev/fflib-apex-common[/quote]
Не, я дак пишу свои обертки.

[quote="Dmitry Shnyrev"]Все равно рано или поздно на проект придут такие парни как Я и сломают вашу красоту [/quote]
Или к тебе на проект придут крутые парни и сломают тебе кайф.
Я уже кучу людей переучил, мне не привыкать.

[quote="Gres"]Я уже кучу людей переучил, мне не привыкать.[/quote]

А те кто не хочет переучиваться - давай досвиданья :)

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

Как-то двухсмысленно звучит.

Еще раз расскажу из своего много летнего опыта.

Видел кучу проектов и НИ РАЗУ НЕ ВИДЕЛ нормальной реализации хоть какой-либо абстракции. Да были проекты на которых пытались внедрить какие-то паттерны, врапперы, или другую лабуду из мира книжных теоретиков. Но занимался этим один человек, которые просто не был в состоянии переучить всю комманду и следить за заждым изменением. В итоге внедряли, а потом дружно забивали. Где-то использовали, где-то нет, много где использовали просто неправильно. Код становилось писать и читать сложно (я на одном  таком проекте код НЕ ПИСАЛ, я тупо лазил по проекту и копипастил, потому что по другому не получалось).

Так что если вы пилите свой мега проект в вакууме, то вам круто повезло. 

Если хотите сделать мир лучше, научите всех. Я только за! Давайте сделаем серию статей про то как надо писать код, какие паттерны и врапперы использовать. А то пока кроме разговоров что все вокруг лохи ничего нет.ъ

Я кстати думаю что если вы Gres и Wilder столкнетесь на одном проекте, этому проекту придет звиздец!

[quote="Dmitry Shnyrev"]Я кстати думаю что если вы Gres и Wilder столкнетесь на одном проекте, этому проекту придет звиздец![/quote]

Ну я вполне себе flexible man. До тех пор пока я не начинаю принимать решения :)

По поводу абстракций. В оргах уровня Enterprise без этого никак, иначе просто куча кода и никто не знает почему его так много.

По поводу проверки синтаксиса. Как раз сегодня закончил автоматическую проверку при коммите. Теперь остальных можно дрючить в автоматическом режиме, правда это не отменяет code review, но по крайней мере hardcoded id ловятся сраазу.

З.Ы. Дима не кипятись. Всех научить/переучить не возможно. да и не зачем это. Разный масштаб проектов, разные подходы.

[quote="Dmitry Shnyrev"]Как-то двухсмысленно звучит.[/quote]
[quote="Dmitry Shnyrev"]Все равно рано или поздно на проект придут такие парни как Я и сломают вашу красоту[/quote]
Ну да, точно)

[quote="Dmitry Shnyrev"]Если хотите сделать мир лучше, научите всех.[/quote]
Тут дело в том, каждый пишет код, так как ему нравится. А если ты работаешь в команде, то ты попадаешь под стиль этой команды, если ты хочешь работать вместе с командой, то тебе придется писать код также.
А ты пытаешься доказать, что паттерны это плохо, да у тебя есть негативный опыт, но я также могу сказать, что с говнокодом тоже куча проблем из личного опыта.

[quote="Dmitry Shnyrev"]Я кстати думаю что если вы Gres и Wilder столкнетесь на одном проекте, этому проекту придет звиздец![/quote]
Почему же, я всегда готов к диалогу, постоянно работаю с разными командами и проблем никогда не было.

[quote="wilder"]З.Ы. Дима не кипятись.[/quote]
:D сорри, опять холивар развел. 

[quote="wilder"]Ну я вполне себе flexible man.[/quote]
[quote="Gres"]Почему же, я всегда готов к диалогу,[/quote]
Вот это правильно! Вот это хорошо :)
Я тоже спокойно в проекты вхожу и очень даже спокойно работаю под началом бывших junior которые по воле судьбы становятся лидами на проекте и занимаются архитектурой :D 

Не совсем понятно что надо предотвратить: если в очередной раз произошло изменение объекта, то почему не надо выполнять какую-то бизнес логику?

А так: отслеживаю нужные изменения в объекте, если они были - дёргаю логику; если логика должна дёргаться как-то единожды - складываю в set обработанных записей.

А как вам такая задача: в результате каких-то манипуляций объект на котором висит бизнес-логика может изменяться n-раз, задача - сделать так чтобы логика выполнилась только один раз после самого последнего изменения. Пока что её решение видится только через асинхрон. 

[quote="ilya leshchuk"]Не совсем понятно что надо предотвратить: если в очередной раз произошло изменение объекта, то почему не надо выполнять какую-то бизнес логику?[/quote]
Trigger -> WF -> Trigger

[quote="ilya leshchuk"]А так: отслеживаю нужные изменения в объекте, если они были - дёргаю логику; если логика должна дёргаться как-то единожды - складываю в set обработанных записей.[/quote]
Контекст то не меняется следовательно, нужные изменения будут 2 раза.

[quote="ilya leshchuk"]А как вам такая задача: в результате каких-то манипуляций объект на котором висит бизнес-логика может изменяться n-раз, задача - сделать так чтобы логика выполнилась только один раз после самого последнего изменения. [/quote]
n известно? А так, да, только отложенное изменения и блокировка.

[quote="Gres"]Trigger -> WF -> Trigger
Контекст то не меняется следовательно, нужные изменения будут 2 раза.[/quote]
Ну почему же, второй раз триггер сработает только если в результате WF были внесены изменения в запись и не факт что изменения были внесены по тем полям которые мониторятся для бизнес-логики.
[quote="Gres"]n известно? А так, да, только отложенное изменения и блокировка.[/quote]
Ага, хитрый :) Нет, конечно же, n заранее не известно, может один раз зайти, а может и больше.

[quote="ilya leshchuk"] и не факт что изменения были внесены по тем полям которые мониторятся для бизнес-логики. [/quote]
О чем и речь