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

[Paisa Seeluangsawat <paisa unt edu>]

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

I thought we agreed that we _have_to_ send the sql command to server
during update_row()--regardless of provider types.  In the above
quote, did you say you wanted to do that only in transactional
providers?

if (answer == "yes") {
    please reply to,
    http://mail.gnome.org/archives/gnome-db-list/2003-October/msg00111.html
}
if (answer == "no") {
    It's impossible to implement _end_edit() and _cancel_edit() to do
    what you said.  Not just hard, but impossible!  A simple example,

    CREATE TABLE doom {
        a	int;
	b	timestamp;
    }
    
    SELECT a FROM doom;

    You don't know the timestamp values, and once you call
    _update_row(), the old timestamp is lost.  How are you going to
    implement _cancel_edit() ?
}



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

You've been saying it's possible with feature [something] in 'some'
providers.  We are talking about a very fundamental operation here
(updating a record)!  You should be thinking whether this can be done
in Oracle, Postgre, MySql, and XML.  I have no idea how to implemented
it in Postgre and MySql.  If you know how, please enlighten me.  If
you don't, you need a serious rethinking.



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

My problem wasn't that it's hard to implement.  I think it's
impossible!  Though apparantly you think it's possible, you haven't
soundly explained how.  So when your "batch update" implementation
time come, you can bet I'll be there asking "HOW".  <evil>Mwa Ha Ha
Ha, Mwa ha ha ha ...</evil>