dormando wrote:
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.
It seems to me that this is an argument for server-resident logic to
handle error conditions rather than an imperative to crud up SQL with
nonsensical hacks. I won't dispute your desire to have un-orthodox
error handling semantics performed without breaking the traffic flow,
but maybe a smarter, more general mechanism can be found.
Most of the worst parts of MySQL came as quick hacks to solve immediate
problems. There are, over time, a large number of immediate problems,
and the size of the cross product leads to (say) an unmaintainable system.
I think this is a case where a more agile solution to a more general
problem will be significantly better system than propagating short
sighted and shallow hacks.
There are are variety of mechanism that would be better solutions that
INSERT IGNORE. One that codes to mind is an aggregating interface -- an
interface containing both logic and SQL executed server side in a single
interaction. For MogileFS, it could handle the (don't say bizarre,
Jim) error semantics required without the need to client interaction.
But it could also handle other pathological requirements as well. (For
clarity, I am arguing for an open end set of aggregating interfaces
because there is not enough time or bandwidth to agree on a single
interface. Each could be handled by a distinct server side plugin, each
properly layered on the server, but executing server side.)
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
