Jay Pipes wrote:
> Peter B. Volk wrote:
>>> What's the reason for not sending the original query
>>> to
>>> the remote server?
>>
>> # Select all rows that have to be deleted
>> # Send them to the "virtual int delete_row (buf);" function of the
>> storage
>> engine. The Buf contains the row to be deleted. The storage engine does
>> not "know" the real query. Actuall this is rather logical. Delete
>> statements may also contain Select statement. E.g.
>>
>> Delete From cafeteria Where coke IN (SELECT type FROM pepsi).
>>
>> Now imagine that the table cafeteria and pepsi are created using
>> different
>> storage engines. One storage engine does not know from the other.
>> Especially not the data in it. Therfore the storage engine is told to
>> simply delete the row containing the data in the bufer. If there is more
>> than one row than the delete_row function is called multiple times untill
>> all rows where passed through the delete_row function.
>
> Hi!
>
> But, by this logic, then statement-based replication wouldn't make
> sense, since the storage engine on the master and slave can be
> different, no?
>
> In other words, why was this method chosen for the federated handler,
> but not for the replication writer?
I think this would still replicate correctly to a different storage engine, because of
the LIMIT 1 added to each DELETE.
Baron
