Re: [gnome-db] Minor API change and MySQL [update/delete]_row

[Paisa Seeluangsawat <paisa unt edu>]

Another separate issue,

> hmm, one of the things I think providers could do in this function
> is to store the old row in some cache, so that if editing is
> cancelled, they just put back the old row.

I agree.


> right, but I'm talking about cancellation because of the program
> logic, not the database logic. A user might want to edit some rows,
> and then decide to discard. Or a program doing calculations might
> cancel itself the update if some calculation fails.

> yes, that's the idea. But what I mean is that we might want, apart
> from that, to have a way for apps to commit/cancel a set of updated
> rows. Of course, for each individual row, update_row should tell
> whether it failed or not.

We can't tell whether update_row fail until we send UPDATE command to
the server.  Constrains might not be met.  The record might have been
updated/deleted by other users.  Etc.,.

On non-transactional servers, if we delay SQL execution and do them in
batch, we will always have the problem of partial failure.  And we
won't be able to get back to the original state.  Again, any user code
handling this delayed, partial, multi-row failure will likely be very
messy.

Logistically, anything batch aspect that GdaDataModel can do, the user
can easily do the same by keeping an array of GdaRow* to be updated.
In the end, the user can decide whether to for loop over that array
and call update_row().

So why bother worrying about this batch thing?