Re: [gnome-db] Minor API change and MySQL [update/delete]_row
- From: Paisa Seeluangsawat <paisa unt edu>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Paisa Seeluangsawat <paisa unt edu>, GDA <gnome-db-list gnome org>, Laurent Sansonetti <laurent datarescue be>
- Subject: Re: [gnome-db] Minor API change and MySQL [update/delete]_row
- Date: Thu, 30 Oct 2003 22:41:04 -0600
Commit and rollback are done per connection, not per model. If you
want to do anything related to it, shouldn't the functions be in
gda-connection.h?
Since you want local data to be consistent with the server data, you
rollback local data only when "ROLLBACK" is sent to the server, right?
Why not do that in gda_client_commit_transaction() then?
> if the provider can simulate transactions, we want the same
> behavior. If not, we want it to work like in auto-commit mode.
I'm worried about this inconsistency between different providers.
Isn't the point of libgda is to provider access to different provider
in a _uniform_ way? Switching providers, and now the users
automatically from auto-commit to transaction mode? The difference
between the two modes is huge. The user, not libgda, should be
deciding which mode to use.
And here's yet another proposal. I don't care much if we implement
this. But I really care that we address the problem above.
In modify GdaConnectionOption to have
_READ_ONLY
_READ_WRITE
_AUTO_COMMIT
_TRANSACTION
etc.,.
Some of these can be set as default. Then in _open_connection(), we
return NULL if the provider doesn't support that mode.
Benefits:
- the user can choose whether to use auto-commit or transaction,
and know if that mode isn't available.
- new model knows whether it's in _READ_WRITE or _READ_ONLY. So,
it can prepare data updating stuff right from _init() or _new().
- no additional functions user have to call before/after editing.
> 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.
Gee, that make MySQL sounds like a toy :-P. Good luck on it :-).
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]