At 3:42 PM +0000 1/8/07, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Can someone tell me why attach cannot be called within transaction?
I do not recall.
Clearly a DETACH will not work inside a transaction if the
table being detached has been accessed or modified within that
transaction. But ATTACH could work, I would think.
Perhaps we disallowed ATTACH so that people would not expect
an automatic DETACH if the transaction rolls back?
I think that it would be okay, though not mandatory, for an ATTACH to
occur within the context of a parent-most transaction; similarly, a
DETACH could happen within a parent-most transaction *if it was not
updated in any way*.
Generally speaking, all SQLite data files that are attached while a
transaction is active are a collective entity for which the
transaction succeeds (commit) or fails (rollback) entirely.
It does not make sense to DETACH a file that was modified during the
currently active transaction, because it would no longer be possible
to fulfil the mandate of a transaction. A DETACH during a
transaction should simply return an error if it was changed; the
transaction must first be committed or rolled back before such a
DETACH is allowed.
Or more generally, we could disallow all ATTACH and DETACH during a
transaction period, but the more specific case I mentioned before is
all that is really needed.
Note that I am assuming that things like foreign key constraints
(when implemented) can not be defined over entities in different data
files, since they couldn't be realized when both aren't mounted
together.
Note that I used the term "parent-most" above under the situation
where parent+child transaction support is available ... which is
trivially true anyway if individual SQL statements are atomic.
-- Darren Duncan
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
