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

[Rodrigo Moya <rodrigo gnome-db org>]

On Fri, 2003-10-31 at 05:41, Paisa Seeluangsawat wrote:
> 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?
> 
because we want to make the data model know about that, and for some
data models, it might not even support transactions. That's why I think
we need another way to do the editing.

Transactional providers will use a transaction, but non-transactional
providers will use whatever they need to.

> 
> > 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?
>
yes, that's why we can't rely on the client using begin/commit/roolback,
since the provider might not even support transactions.

>   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.
> 
right, but as I already said, not all providers support transactions. So
what we want to provide with the updatable data models is something as
generic as:

	* get data model
	* start edition
	* modify/remove/add
	* end edition/cancel changes

That is, this is orthogonal to the gda_connection_*_transaction
functions. Those are for people using libgda as any other database API.
But thew updatable data models concept is to get users out of that, if
they don't need it. We want to provide them a good way of editing the
data model without worrying about normal DBMS issues.

One thing we could do, though, is allow the user to provide a
GdaTransaction to the begin_edit method on the models. Thus, if users
want, they can force the data model to be using that transaction. If
that is NULL, then the data model will operate as I said (do the
initialization it needs, like starting a new transaction, allow changes
to be made, and save/discard the changes).

I don't think we should impose a DBMS-like look&feel to the data model.
It is not intended for that, but for a simple access to the data.

> 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.
> 
yes, that's a good idea.

> Benefits:
> 
>    - the user can choose whether to use auto-commit or transaction,
>      and know if that mode isn't available.
> 
we could probably also provide functions like
gda_transaction_get/set_auto_commit_mode.

>    - new model knows whether it's in _READ_WRITE or _READ_ONLY.  So,
>      it can prepare data updating stuff right from _init() or _new(
>
but some updates are per-model, so it will still need some
initialization when starting the edition of a data model. Or well, it
could do that initialization when creating any new data model, based on
the connection opening options. That way, every data model will be ready
to be updatable on initialization. The only thing missing here is that
we'll still need a way to confirm/cancel the updates on each model.

>    - no additional functions user have to call before/after editing.
> 
but the problem then is not solved. If you use a transactional provider,
no problem, you use begin_transaction/commit/rollback. But if it's a
non-transactional provider? Do we force to always work on auto-commit
mode, or do we better make it able to cancel a set of changes on the
data models? I'd vote for the second option.

> 
> 
> > 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 :-).
>
well, mysql is a nice DBMS, but Postgres is a professional DBMS, which
includes most things you would expect in such a piece of software :-)

cheers