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

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2003-10-29 at 19:50, Paisa Seeluangsawat wrote:
> > > 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
> 
> Conceptually, users can think of XML as transactional provider.  I
> don't know LDAP so can't say anything, but if want you said it true,
> we can change back to rows in the library and let the user
> conceptually think of it as a transactional provider.
> 
what I mean is that the provider will have to simulate the transaction
if possible. If not, it will work on auto-commit mode.

> But the problem remains, what happen in non-transactional providers?
> Do we want different beheavior between transactional and non-trans
> providers?
>
no and yes. That is, if the provider can simulate transactions, we want
the same behavior. If not, we want it to work like in auto-commit mode.

>   I think there's nothing like 'rollback' to do in non-trans
> provider.  Isn't this feature trans-specific?
> 
> However I look, the function names should be like
> 
>   _start_transaction()
>   _end_transaction()
>   _rollback_transaction()
> 
> And clearly state there's nothing to do in non-transactional provider
> or auto-commit mode.
> 
> 
> > 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.
> 
> I must misunderstand you here somehow.  Do you expect the server to
> notify all connected clients that it's being updated by other
> connections?  Is this even possible with most SQL C API?
>
with postgres, it's possible to be notified when a table changes. You
register to the change notifications and every time the table you are
listening to changes, you get a notification.

But as I said, I'd leave that for phase 2. For phase 1, we just want to
update the models, without worrying about the data being changed while
modifying. In fact, this won't even be a problem for some providers,
since they'll be able to start a transaction for updating a table, in
which case that table will be locked.

cheers