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

[Paisa Seeluangsawat <paisa unt edu>]

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?

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

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.

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 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.  It also prevents a bug caused by the mode being silently
changed when moving to a new provider.



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.

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

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

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