Hi!
On Dec 25, 2008, at 12:37 PM, Jim Starkey wrote:
I just don't get it. Why would anyone want to do an operation where
they couldn't tell if it failed, why it failed, or what it did? If
it logged the failures, I wouldn't mind. I can also understand why
somebody might want it for a non-transactional engine (though not
why someone would *want* a non-transactional fine) where there was
going to be partial data load whether they liked it or not. But a
legitimate transactional system being asked -- yea directed -- to
lose unknown quantities of data, well, I just don't get it.
Alan's discussion about how MogileFS uses it made sense to me. The
only time I have found it useful is when we were handling of merging
data between multiple systems, where there was a possibility that
their might be a conflict on primary key. If the data already
exists... move on and don't worry about it. It boils down to lossy
data cases.
My only big care about it? If the data is bad, aka does not fit the
constraints for the table, it should not be stored. No fuzzy matching
for "this might be a correct entry". If there are duplicate entries in
a bulk insert... drop them. But if they are bad entries? (aka poor
data), drop them as well. Don't just "insert" them with whatever bits
of random logic are in place.
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
