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

[Paisa Seeluangsawat <paisa unt edu>]

I'm the slow headed one :-P.

> but then this adds confusion, in some cases, since some providers dont
> need to lock rows at all.

I've used only MySQL and readed about Postgre.  Is there any provider
that needs to lock rows in a separate call before hand before you can
update them?


> well, it's about doing it as generic as possible so that all kind of
> providers can implement it

If it's local resource issue, do we agree that _get_updatable_row and
_finalize suffice?

Suppose it's server resource issue. In gda_data_model_begin_edit() of
providers that allow locking, what should it do?

   - lock some rows -- which rows?
   - lock all rows or lock table -- many users wouldn't want this.
   - do nothing?


> There are a lot of cases where you'll want to modify several rows and
> commit that once. Of course, there are transactions, but what about
> providers that don't have transactions? How can we tell it to cancel the
> modification we just made to a set of rows? or to commit it?

In providers without transaction, there's no atomicity.  If, say, the
second update command fails, you can't undo the first command anyway
[1].  These function names could mislead some users to think they have
atomicity when they actually don't.

We also have to tell users which rows failed to update.  It can get
messy in user's code trying handle this multi-row, delayed failure
report.  Isn't it better to update the row right away in _update_row()
and tell the user right then whether it fails or succeeds?