I filed the following bug:
Ideally, I would like the contract changed :). Having the storage
engine return whether the row was affected can be very very expensive.
On Fri, Apr 23, 2010 at 12:04 PM, Sergei Golubchik <sergii@stripped> wrote:
> Hi, Zardosht!
> On Apr 23, Zardosht Kasheff wrote:
>> Hello Sergei,
>> Thanks for responding. Just to make sure I understand, it is a bug in
>> the documentation, right?
> No, I take it as a bug in the implementation of
> HA_EXTRA_WRITE_CAN_REPLACE. Feel free to submit it.
> I'm not quite sure about the fix, though. For example, one could say
> that write_row should return a special error code to indicate that it
> replaced, not inserted a row. That would fix the bug in the original
> patch, as the cluster can do it,
> But, of course, it won't help you as you really don't know (or do not
> want to know) if you insert or delete, even after the statement ends.
> Well, you could say that it's a peculiarity of your engine that REPLACE
> may return incorrect row count - kind of "shifting the blame" thing,
> from bug in MySQL it becomes a bug in TokuDB that you will decide not to
> fix (but document instead).
>> On Fri, Apr 23, 2010 at 2:29 AM, Sergei Golubchik <sergii@stripped>
>> > Hi, Zardosht!
>> > On Apr 21, Zardosht Kasheff wrote:
>> >> Hello all,
>> >> If I understand correctly, the flag HA_EXTRA_WRITE_CAN_REPLACE implies
>> >> that handler::write_row can overwrite existing rows, if a duplicate is
>> >> found. That is what the comment states, and that is what I heard NDB
>> >> does in MySQL Cluster. If this is the case, then I assume that
>> >> handler::write_row returns success even when the row is overwritten.
>> >> If that is the case, how is this part of the contract honored, as
>> >> stated by the MySQL 5.1 reference manual
>> >> (http://dev.mysql.com/doc/refman/5.1/en/replace.html):
>> >> "The REPLACE statement returns a count to indicate the number of rows
>> >> affected. This is the sum of the rows deleted and inserted."
>> >> Is something in my understanding not correct? Because it seems that if
>> >> handler::write_row silently overwrites an existing row, as
>> >> HA_EXTRA_WRITE_CAN_REPLACE seems to allow, then the counts will not be
>> >> accurate.
>> > Yeah, seems like you're right.
>> > I think it's a bug.
>> > Regards,
>> > Sergei
>> MySQL Internals Mailing List
>> For list archives: http://lists.mysql.com/internals
>> To unsubscribe: http://lists.mysql.com/internals?unsub=1