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

[Rodrigo Moya <rodrigo ximian com>]

On Sun, 2003-11-02 at 02:14, Paisa Seeluangsawat wrote:
> Before the argument starts going into a loop, let's straighten out
> what we are (or seem to be) disagreeing on,
> 
> 
> 1) Should it be explicit whether the user is writing a code in
>    transaction or auto-commit mode?
> 
I think when starting to update a data model, there should be an error
code or status that says all modifications will be immediately sent to
the provider, if the provider does not support transactions (or can't
simulate them).

> > 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
> > ...
> > 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.
> 
> The difference transaction and auto-commit is one thing that's too big
> to hide.  If you really want to hide it, please tell me me what
> exactly should the user expect to happen to the (server and local)
> data in _cancel_edit() and _end_edit()? 
>
if the provider can simulate the transaction, it should just use that.
If not, it would be in auto-commit mode.

>  If you can come up with a
> consistent scheme (i.e. act the same whether we're in transaction or
> auto-commit mode), the rest of this e-mail is irrelevant.
> 
well, it really depends on the provider. I'd say all providers should
either use a transaction or simulate it. If that's not possible at all,
it could work in auto-commit mode.

> I think we can't make _cancel_edit() behave consistently because the
> set of commands you have is just a renaming of the transaction syntax.
> You're trying to impose that syntax on auto-commit users.
> 
no, we're trying to have a unique and as generic as possible way for
updating the data models. We should really not force any transaction or
auto-commit knowledge to the user.

> Being uniform doesn't mean providing one set of commands that act very
> differently on different mode/providers.  Your _cancel_edit() acts
> differently in different modes.  Uniform means each command (that's
> not specific to that mode) gives the same result no matter what
> mode/providers we're in.
> 
what I'm saying is:

	if (gda_data_model_begin_edit (cnc) == SUCCESS)
		---work in transaction mode
		gda_data_model_end_edit (cnc);
	else if (.. == AUTOCOMMIT_MODE)
		---work in autocommit

thus, you have the same API for both modes, but the user can easily know
what the mode is, and act accordingly.

> > what I mean is that the provider will have to simulate the
> > transaction if possible. If not, it will work on auto-commit mode.
> > ...
> > if the provider can simulate transactions, we want the same
> > behavior. If not, we want it to work like in auto-commit mode.
> 
> Codes for auto-commit and transaction mode are intrinsically
> different.  Forcing users to state explicitly right from
> gda_connection_new() what mode he's coding in can contributes to code
> readability.
>
yes, or, we could probably, as was also mentioned on this thread, have a
gda_transaction_set_mode function, and the ability to provide a
GdaTransaction on the begin_edit.

>   It also prevents a bug caused by the mode being silently
> changed when moving to a new provider.
> 
that's why we'd need some status code so that the app knows what's going
on.

> 
> 
> 2) _connection_rollback v. _model_cancel_edit
> 
> Please let me be explicit.  I assume that when a connection (or
> transaction) opens multiple models, a rollback affects all models in
> that connection.  If this isn't true, my point is mute.
> 
it isn't true for some providers. In some DBMS you can create a
transaction for the update of a table. That transaction only affects
that table, and you can create new transactions for other tables.

Also, some providers allow nested transactions, so they can create a new
nested one, and when that one is rolled back, only the changes done for
that transaction are rolled back

> Model-level begin/commit/rollback is clearly not in sync with what
> happens on the server.  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)?

> I'll also be explicit about what I proposed.  When you call
> gda_connection_rollback_transaction(), it sends rollback command to
> the server, roll back local data in all models in that connection, and
> emit whatever signals necessary.  You raised several objections...
> 
no, rolls back data in the transaction you specify.

> > that's why we can't rely on the client using begin/commit/roolback,
> > since the provider might not even support transactions.
> > ...
> > 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.
> 
> In the proposed scheme, the user knows right from gda_connection_new()
> what mode he's in.  In auto-commit mode, there's nothing like
> begin/commit/roolback to do so he won't even ask for it.
> 
> You stressed "(so|since|because) some providers don't support
> transaction" many times.  If it hasn't been clear from my e-mails, I
> explicitly state here that I'm aware of that.  What I don't understand
> are the "so", "since", "because" parts.  I'll appreciate more details
> on how you draw the conclusion, and how does the existent of
> auto-commit-only providers causes a problem with my case.
> 
no, doesn't cause any problem. The thing is that we want it to work on
transaction mode always, if at all possible. When that's not possible,
auto-commit mode is the way to go, of course.

> > 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.
> 
> I agree with your vote.  I couldn't think of what I wrote that would
> make you doubt that.  On the other hand, in providers that allow both
> transaction and auto-commit, your earlier writings _seem_ like you
> want to force users to use transaction.  That had me worried up until
> when you mentioned otherwise in your last e-mail.

no, I don't want to force :-) What I mean is that the API for updating
data models should provide the way to have sets of changes. Again, when
that's not possible, the provider will work in auto-commit mode, and the
app should have to be informed (via a return code in _begin_edit, as in
the example above) of that.

cheers