Even if you fire the trigger, you will have the same amount of change
On Tue, Jan 20, 2009 at 4:16 AM, Alex Karasulu <email@example.com
> Hi Emmanuel,
> On Sat, Jan 17, 2009 at 7:15 PM, Emmanuel Lecharny <firstname.lastname@example.org
>> Last, not least : the triggers. If some modification can triggers some
>> other (because of integrity constraints being activated), then it should be
>> logged in the change log. When replicating, the triggers _must_ be disabled,
>> as the merged operations will contain all the triggered operations.
> This is one way to handle it but it could be very expensive. If the trigger
> firing impacts many entries or results in a cascade of firings, then the
> cost of replicating the changes could be very large.
Right now, I think that the first step would be to have replication
> replication event processing must perform operations against the DIT with
> the identity of the client making the change at that time on the supplier.
> So unlike a regular operation, an operation to apply replication deltas,
> must use different values for these attributes. In a way this kind of
> operation is not a direct operation against the consumer, but an indirect
> Direct operations by clients may raise, triggers which may perform
> additional operations against the DIT. These triggered operation can
> themselves raise triggers that cause more changes. A cascade may result
> although should be constrained through various means. The server is
> designed to track the fact that a triggered change is occuring because of
> another change. This is tracked through a linked list where at the head
> you'll find the operation that started it all. All the triggered operations
> are treated as indirect operations caused by the operation at the head.
> The point I want to make is we already have some machinery here for tracking
> direct and indirect opertations. Although presently triggers don't work and
> the tracking mechanism lacks a way to put the same timestamp on all changed
> entries as if they happened at the same time, it should have this. The
> server must treat replication operations at the consumer in a similar
> fashion and apply timestamps properly. It can also do the same with respect
> to the changes due to triggers even if the operation in question is
> replicated or not.
> This is the main worry with triggers and if we can properly solve this
> problem in a simple and easy to maintain way then we're golden.