The thing about IGNORE that makes it different from other
ignore-bad-data things is that you have to explicitly say you want to
ignore duplicates. (Except for LOAD DATA LOCAL INFILE, and maybe the
protocol hacking is already eliminating the need for that?)
It's really quite useful when you're cleaning up crappy data, which I
have done a lot of.
Or when you're restarting something that failed partway through.
Ditto, done a lot of that.
I don't see the harm in it, since it's not one of those on-by-default
things; rather I see it as a useful extension like ON DUPLICATE KEY
UPDATE, or some of the other non-relational extensions I proposed in
an earlier thread.
$0.02 :-)
INSERT IGNORE's used heavily in mogilefs... this is partially because we
avoid syncronization for a lot of events. So INSERT IGNORE becomes a
ghetto syncronization primitive. Other parts of the system heavily use
SELECT GET_LOCK/RELEASE_LOCK.
To mogilefs, it doesn't matter if two processes attempt to queue the same
FID for deletion, the first one in will win the race, and if both win (FID
is dequeued before the second process drops it in) the row will be parsed
as an already-deleted item and ignored.
Probably a bizarre abuse in an edge case, but it's handy to be able to
blindly do that instead of tiptoeing to avoid breaking replication.
-Dormando
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
