Feature: Introduce sum through many

[TSMMark]

Like sum cache, but through a join table.

[jeremyevans]

Thanks for the patch. While the need for this seems to be rarer than for other supported functions, it does look complete and comes with specs. I'm not too worried about bloat for this library, since it's generally only used during migrations, not during application runtime.

The API for pgt_sum_through_many_cache is a bit too unwieldy, with 9 required arguments. Can you change the API so that it accepts just an options hash, or at least reduces the number of required arguments by moving some of them to options (and having suitable defaults)? Also, could you update the README to document this function?

[TSMMark]

@jeremyevans I agree 9 required arguments is far too many. Although it will differ from the rest of the API, I can certainly update the method to accept just the options hash. README docs incoming as well!

[TSMMark]

@jeremyevans I made the changes you suggested. Please take another look.

[jeremyevans]

These changes look good. I won't have time to test and merge this until Monday, but one thing I noticed is that this handles inserts and deletes on the child table. I'm not sure if we want to support that. Real foreign keys should be used in the database, so we shouldn't have a case where you can insert a child row that is already referenced by the join table, or delete a child row still referenced by the join table. You still do need to handle updates on the child row, but I think you only need to handle insert, update, and delete on the join table. What are your thoughts on that?

[TSMMark]

I totally agree with the assertion that real foreign keys should not support this kind of thing. However, I wanted to implement triggers which would handle any case and provide proper sum values regardless of the architecture / FK constraints. Are you concerned about performance? In that case, do you suggest I make the INSERT & DELETE handlers opt-in?

[jeremyevans]

Since you've already done the work and it appears to work correctly, I guess there is no point in removing support for INSERT and DELETE on the related table. I'll test this shortly and merge if there are no problems.

[jeremyevans]

I've merged this with some changes, mostly requiring additional constraints so that the trigger functions could be simplified. Could you review and let me know if you are happy with the changes? If so, I'll release a new gem.

[TSMMark]

I suppose it is rather unrealistic to expect anyone to reference columns other than primary keys from a join table. I'm happy with the changes, thanks for checking.