Ann W. Harrison wrote:
Is there a plausible (non-QA) use case for ignoring other errors?
I can tell you where we use it. You can decide if it is plausible.
We have triggers on tables to track changes to key tables. When
inserts, updates and deletes happen on those tables, their primary key
is placed into a queue table. We then use this queue (MEMORY) table to
process the changed data and move it up to our front end servers. We
use INSERT IGNORE in the trigger as the key in question may already be
in the queue table. We don't want our trigger failing as it would make
the query that started it fail.
I could switch that to DELAYED and get the same effect. DELAYED (please
oh please don't kill delayed) is used in our real time logging inserts.
More reliable methods are used for keeping logs that matter (i.e. make
us money). But, for real time analysis - what is happening right now -
it is easier to insert delayed into a table and let our application
continue on its way.
Of course, I could keep all that on MySQL as well. I would guess that
IGNORE is not going away from MySQL.
The other option to not use IGNORE for insert is to use REPLACE INTO.
It has the uneviable quality however that it inserts and deletes every
time. AFAIK, it does that even if no columns/rows change.
Perhaps an extension to the ON DUPLICATE KEY UPDATE syntax could be used
instead of IGNORE. ON DUPLICATE KEY IGNORE perhaps? That is more
explicit than just IGNORE and would not ignore other errors that are not
duplicate key related?
--
Brian Moon
Senior Web Engineer
------------------------------
When you care enough to spend the very least.
http://dealnews.com/
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
