I think what IGNORE wants to be is a flag to either abort on error or
continue on error.
i.e.
please execute this query and if you encounter an error, keep processing
the query. If i don't like result, i'll ROLLBACK myself.
OR
please execute this query and if you encounter an error, stop processing
the query.
In ndbapi this is a flag to execute() and in SQL the IGNORE keyword is
kinda like it.
The question remains - do you want the error messages at all?
If you're loading in 10 million rows and 5 million are duplicate key
errors.... perhaps you don't care about the error messages for them and
don't particularly want to use the network bandwidth for getting them
back....
Perhaps I want to ignore duplicate key errors and not ignore invalid
data errors? (or the other way around. i.e. i know my data stream is
corrupt if i get 2008-0-1 as a date).
do we need some way to express this in SQL?
So... presently you get the "rows affected" message back, along with some
flags. You'd see a subset of your requested rows inserted, but no notes as
to why. But most of the time we don't care since it's just going to be
'duplicate key error', we care if it's syntactical or constraint or some
other real bug. Table full maybe. Int overflow maybe.
If I attempt to insert 10k rows in which I expect to average a few hundred
in errors, I don't want to be reading back those errors all the time. But
I'd find it reasonable in either case, either forcing the user to read
(and ignore) the errors, or not having access to them at all. There're
points for both?
-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
