Mamta Satoor <[email protected]> writes: > Rick, thanks as always. All this makes sense. My recent emails about > trigger behaviors are to see where we can avoid having before and > after copies of the LOB columns in the triggering table so we don't > run into OOM when it can be avoided. > > Since the only way to pass before and old values to the stored > procedure in trigger action is through formal arguments, then I guess > we can safely assume that before and after values of LOB columns from > triggering tables will never make their way into stored procedure. The > Derby Reference manual says "Note: Data-types such as BLOB, CLOB, LONG > VARCHAR, LONG VARCHAR FOR BIT DATA, and XML are not allowed as > parameters in a CREATE PROCEDURE statement."
This limitation is likely to be lifted, though. See DERBY-4066. > So based on the fact that stored procedure gets before and old values > through parameters and LOBs can't be passed as parameters to stored > procedure, there is no need for us to keep before and after values of > LOB columns from the triggering table when the trigger action is a > stored procedure. I haven't looked at the code, so I don't know how viable the different approaches are, but I would think that looking at which columns the different triggers actually reference is a more robust way to determine which columns to copy into the before and after images. Then we would save memory/copying for trigger actions that don't call stored procedures too, and also for non-LOB types. -- Knut Anders
