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

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2003-10-29 at 05:13, Paisa Seeluangsawat wrote:
> > 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 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.
> 
> What happen in non-transactional providers
>
in non-transactional providers, it depends on the provider. For
instance, the XML provider will not save the file until the
"transaction" hasn't been committed. The LDAP provider might change back
what it changed on the server, etc

>  or auto-commit mode?  You
> roll back to the original state, which now doesn't match the data in
> the server?
> 
in auto-commit mode, right, we need to think about this. We probably
want an error code, when doing the "start update" operation that says so
"the connection is in auto-commit mode". And return an error if
cancellation is attempted.

> If what you want is specific to transaction feature, the function name
> should say so.
> 
> Also, the user can,
> 
>   const gchar* command = gda_data_model_get_command_text (model);
>   model = gda_connection_execute_single_command (cnc, command, ...);
> 
> So, you are worrying about speed, not functionality, right?
>
right, this is another problem. Since the model might get changed while
we are editing it. We probably want to start with the easy case (no
parallel updates) and then try to add to the providers the ability to
get notified when things changed, if that can happen when editing.

cheers