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

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2003-10-27 at 19:11, Paisa Seeluangsawat wrote:
> 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?
> 
hmm, not sure, but think that we are going to support weird kinds of
providers (LDAP, etc)

> 
> > 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?
> 
might be, if they support batched updates.

> 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?
> 
right, we need to know which rows to lock/save/whatever, so, yes,
begin_edit does not look very good.

> 
> > 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].
>
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.

>   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?
> 
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.

cheers