Re: Rationale behind FEDERATED engine queries

[Jay Pipes]

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?

Cheers!

jay