Josh Berkus wrote:
> Tim,
>
>
>>That loop apparently does not find any matching rows, which would
>>have been inserted just before this row was, inside the same
>>transaction.
>>
>>It was successfully finding those rows before, when the trigger was
>>AFTER INSERT. If I manually select those rows after the query is
>>committed, I am able to pull up the matching rows.
>
>
> I think that triggers are probably not a good strategy for the kind of
> calculation you're doing. I'd suggest instead a middleware module or a
> "data push" function which would bundle all of the calculation logic
> before calling any of the inserts.
Yeah, but this is so much cooler. ;-)
Essentially this would be like recursion to push back/pull forward tasks
which are dependent on each other. The "UPDATE" trigger I wrote is about
5x longer.
I guess I can push this back into the PHP code and do a recusive
function call, but that seems less sexy.
Tim