prevent infinite loops

[andriytyurnikov]

via prevent_depth option for backwards compatibility

[andriytyurnikov]

@jeremyevans do you think some other function definitions could use same option as well?

[jeremyevans]

I think it would be a good idea to support this for all triggers that could results in additional triggers.

[jeremyevans]

Looks good. I'll try to test and merge this today.

[andriytyurnikov]

I am not sure I have context for such generalization, so I only altered definitions for counter, sum, and many to many sum.

Also, I am somewhat concerned about depth as a numerical parameter in case of sum and counters, and maybe track_recursive_trigger is a better option or worthy alternative - but this is beyond my depth of understanding at the moment.

[andriytyurnikov]

After giving it some thought - I've added guard clause to every other function definition (including to previously missing for many to many summation). It's relevance might vary on case by case basis, but having access via simple parameter seems like a good thing.

[jeremyevans]

I squash-merged your first two commits as f32ebdd (I started working on that before your third and fourth commits). I also renamed the option to :trigger_depth_limit and added some minor changes and more tests in d68b631.

I added support for this to some methods, but not all. I only added it to methods that define trigger functions that result in additional triggers. I don't see a reason to support the option if the trigger function defined cannot result in additional triggers.

Please review and let me know if you think we should make further changes.