Thanks for your answers!
On Feb 12, 2007, at 1:58 AM, [EMAIL PROTECTED] wrote:
"Wesley W. Terpstra" <[EMAIL PROTECTED]> wrote:
Suppose you have two prepared queries: q1 and q2. I currently believe
that it is an error to execute: step q1, step q2, step q1.
No. Queries can be interleaved this way.
Ok.
What is the defined behaviour of interleaved inserts and selects? I
gather since an insert completes in a single step there is no
problem? Active queries now return the result if they have not been
stepped past this point? Will an UPDATE ... WHERE ... also *always*
complete in a single step?
For that matter SQLite is reentrant, and this fact is used within
the implementation.
So, I can create subqueries within user-code in response to some of
the rows I've retrieved? That's pretty cool
An implicit transaction was already started when you started
stepping q1. That implicit transaction will not end until all
active queries have finished.
If you run the BEGIN command, all that does is set a flag that
tells SQLite not to commit once all queries have finished but
rather to keep the transaction open.
Is there some sort of 'open transaction counter'? ie: if I
begin&commit within the scope of an 'automatic' transaction, it will
not commit until the automatic transaction completes?
Suppose I ran: begin, select *, step1, commit, step2. Does the commit
fail because there is still a nested, active query? If yes, then
great. If not, then what is the behaviour of step2?
What happens to an open transaction if you reset a query?
If you have not run BEGIN, then the transaction will end once *all*
active queries have completed.
While most helpful in understanding the mechanism (is this documented
somewhere?), that didn't actually answer this question:
What I meant is that if I am running a "select * from giant_table;"
and find on row 10/800 the data I was looking for, I might want to
just finalize the select statement. My question is what happens to an
explicitly opened transaction that included this select statement?
The documentation implies that the transaction will be aborted, which
is not very desirable.
Here's a concrete example: I need to compute some statistic and write
it into a table. I start a transaction and then begin processing some
accounting records. Part-way through reading those records, I realize
I have enough information, so I stop the select with finalize/reset,
and then run an update, then commit. Is this ok?
Now that I'm working on wrapping bind_text/bind_text16, I have
another question: what is the native on-disk format of the strings?
The documentation suggests that open/open16 determine the encoding.
Does this mean that if I created the database with open, then a
future bind_text16 will do an automatic charset conversion? ie:
should I pick one encoding and stick with it, or allow users to mix
them? (SML has its own Unicode character classes, so I have to
convert to UTF-8/16 anyway. It would be a shame to do it twice.)
It's ackward that there is no separation between a compiled VM and a
compiled VM's state. ie: If I want to run the same precompiled query
twice in parallel (since this is apparently well defined), then I
would need two separate instances of the state.
How hard would it be to create a method that cloned only the byte-
code: stmt* sqlite3_clone(stmt*)? If I wrote this, would it be
accepted? TBH, it would be more helpful if there was an intermediate
form between prepare and the stmt.
Again, thanks for your answers. I just want to be sure that I don't
allow breaking SQLite's invariants.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
