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

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2003-10-28 at 08:38, Paisa Seeluangsawat wrote:
> > 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.
>
I am not talking about doing the UPDATE command for all rows in one
shot. The UPDATE's will be executed every time you call
gda_data_model_update_row. But we want to have a way to cancel a series
of UPDATE commands. That is, you execute a set of UPDATE's, and then
want to cancel. In that case, the provider, apart, of course, of rolling
back the transaction, will need to put back the old rows in the model.
That is, the same operation we do for a single row, but with a set of
rows. The API needs to reflect that, so that's why I added the
begin_edit/cancel_edit/end_edit. The provider will just need to keep a
list of the old rows that have been modified, and when cancelled, put
back all stored rows, and when finished successfully, commit the
transaction.

In fact, this makes me think again about not removing
begin_edit/cancel_edit/end_edit, unless the API you propose reflects the
possibility of starting/ending/cancelling.

cheers

cheers