Email list hosting service & mailing list manager

Re: John Cowan's preliminary notes on a SQLite oriented Simple SQL (ssql) API hga@xxxxxx (12 Sep 2019 15:20 UTC)
How to do transactions, especially nested hga@xxxxxx (18 Sep 2019 01:22 UTC)
Re: How to do transactions, especially nested Peter Bex (18 Sep 2019 06:05 UTC)
Re: How to do transactions, especially nested Lassi Kortela (18 Sep 2019 07:41 UTC)
Re: How to do transactions, especially nested Peter Bex (18 Sep 2019 07:58 UTC)
Re: How to do transactions, especially nested Lassi Kortela (18 Sep 2019 08:26 UTC)
Re: How to do transactions, especially nested Alaric Snell-Pym (18 Sep 2019 10:27 UTC)
Re: How to do transactions, especially nested Alaric Snell-Pym (18 Sep 2019 10:26 UTC)
Re: How to do transactions, especially nested hga@xxxxxx (18 Sep 2019 15:54 UTC)

Re: John Cowan's preliminary notes on a SQLite oriented Simple SQL (ssql) API hga@xxxxxx 12 Sep 2019 15:19 UTC

> From: Peter Bex <xxxxxx@more-magic.net>
> Date: Thursday, September 12, 2019 7:11 AM
>
> On Thu, Sep 12, 2019 at 06:35:40AM -0500, xxxxxx@ancell-ent.com wrote:
>
> > A very preliminary set of notes on the API is at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/SimpleSqlCowan.md>.
>
> Cool, thanks for the link.

You're welcome.

> My first thoughts:
>
> - It seems unnecessarily complicated to me to have a special
>    "transaction" object.  All SQL databases I know of have a
>    transaction be a state of the connection.  So you can't
>    create multiple transactions on the same connection.
>    Dropping this and having transaction be a property of the
>    "db" object would be simpler and reduce the API surface.

This was discussed in the SRFI 167 Ordered Key Value Store
(OKVS) mailing list, see e.g. "Unstructured transactions
considered harmful" by John at:
https://srfi-email.schemers.org/srfi-167/msg/11596319/

One thing noted to be careful about, especially if folding
transactions into the db object, is that you must make sure it
works if you have two databases open, for example to copy data
from one to the other.

Another concept I bought up is that the API should not
necessarily require formally requesting a transaction for single
isolated statements.  And should not turn such from 1 to 3
rounds trips to the database, that is, begin transaction, the
action, close transaction, if instead you can have your database
connection in an auto traction mode.

- Harold