>>>>> "Jules" == Jules Bean <jmlb2@stripped> writes:
Jules> Rick Moore wrote:
>> Agreed-- same with UPDATE DELAYED.
>> It would also be nice if AUTO_INCREMENT values could some how be anticipated
>> (and returned) or perhaps I could "pre-allocate" a block from MySQL and
>> assign them myself. Unfortunately, I can't use INSERT DELAYED as much as
>> I'd like because the AUTO_INCREMENT values are required to maintain
>> referential integrity-- I'm sure this is a common problem...
Jules> Yes. In fact, insert delayed and delete delayed are an integrity
Jules> What would be best, I suppose is if mysql did all the integrity checks
Jules> (i.e. duplicate keys) and allocated the insert_id exactly as if it was a
Jules> normal insert, but didn't actually apply it to the database until a bit
Jules> later (following the existing delayed algorithm).
Jules> So, by the time an insert was in the delayed queue, it was guaranteed to
Jules> succeed, just 'not until later'.
Jules> This implies that the existence of a delayed queue on a particular table
Jules> would have to block other queries. I'd be willing to live with this.
Jules> (In fact, when a particular option was switched on *all* queries could
Jules> be delayed like this)
The problem with the pre-allocating LAST_INSERT_ID()'s is that if you
'accidently' insert a row where the AUTO_INCREMENT column is not NULL,
then there could be a big problem.
Adding delete delayed and update delayed are not trivial; I will
however put this on the TODO...
DELETE are on the other hand not that 'hard' if we would allow 'dirty
reads'. There is also the option to allow appending new rows to a
table while you select on it (this is actually not THAT hard to do).