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

[Rodrigo Moya <rodrigo gnome-db org>]

On Sun, 2003-11-16 at 02:23, Paisa Seeluangsawat wrote:
> In non-transactional provider, what do you mean by "batch updating"?
>
I mean we might want to provide to the applications a way to cancel a
set of changes. That's what I refer to when saying 'batch updating'.

> What does it do when _cancel_edit()
>
in non-transactional providers, discard all changes made since
begin_edit.

>  or _end_edit()?
>
it would save the changes, if not already done, and will remove the
temporary area for changes, so now you can't cancel what was saved.

It is like transactions, although we really want to provide that feature
to both transactional/non-transactional providers. Thus the need for
those begin_edit/end_edit/cancel_edit.

>   We agreed that
> the query get sent by _update_row().
>
for DBMS yes. Although we could simulate the transaction in
non-transactional DBMS by sending a batch of updates when end_edit is
called.

>   Isn't that the end of it?
> What more are there to do?
> 
yes, that's all for transactional providers. But as we said, we really
want this feature for all providers.

Of course, we can always just not support that at all, but I guess that
would be a bad idea.

Anyone has other opinions?

> 
> > > 2) What is supposed to happen to (local and server) data when a user
> > >    opens models A and B in the same connection, edit A and B, then
> > >    _model_cancel_edit(A), _model_end_edit(B)?
> > > 
> > depends on the provider I guess. For postgres, we might use nested
> > transactions, for others, whatever it needs, etc.
> 
> Even with nested transaction, I still have no idea how to implement
> it.
> 
well, some providers allow nested transactions, and some even allow you
to start a transaction for an UPDATE of a table.

I guess this gets too complicated. So, I think we are going to follow
Paisa's advice and just make the modifications be sent immediately to
the provider.

begin_edit et al were supposed to provide a way of cancelling/committing
a set of changes, but if this gets so complicated that we can't even
implement it, I guess we'll go for the simple update_row/remove_row, and
have the client apps use transactions as they want.

Any other thoughts? Maybe we should go now for the simple case, and plan
the batched updates for 1.4?

> 
> Anyway, I'm getting my hand off this record updating issue.  After
> several e-mails, I still have no idea what a user should expect from
> these functions.  I'll just work on other parts of libgda/gnomedb.
>
:-(

cheers