On Tue, Jan 31, 2017 at 12:15 PM, Jens Alfke wrote:
>
> > On Jan 31, 2017, at 9:39 AM, James K. Lowden
> wrote:
> >
> > According the SQL standard, every SQL statement is atomic. SELECT has
> > no beginning and no end: the results it returns reflect the state of
> > the database as of the momen
On 1/31/17, Jens Alfke wrote:
>
> My immediate workaround (implemented last night) is to iterate over the
> statement at the moment the query is run, saving all the rows in memory. Our
> enumerator object then just reads and returns successive rows from that
> list.
That's how client/server SQL d
> On Jan 31, 2017, at 9:39 AM, James K. Lowden wrote:
>
> According the SQL standard, every SQL statement is atomic. SELECT has
> no beginning and no end: the results it returns reflect the state of
> the database as of the moment the statement was executed. If you fetch
> the last row six day
On Mon, 30 Jan 2017 19:29:40 -0800
Jens Alfke wrote:
> if I iterate over the the rows in a table using sqlite3_step, and
> update each row after it?s returned, Bad Stuff happens. Specifically,
> my query is just getting the first row over and over and over again,
> and the iteration runs forever.
Jens Alfke
Gesendet: Dienstag, 31. Jänner 2017 04:30
An: SQLite mailing list
Betreff: [sqlite] Bitten by lack of isolation between SELECT and UPDATE on the
same connection
I’ve just run headlong in to the issues described in "No Isolation Between
Operations On The Same Database Connec
On 31 Jan 2017, at 5:26am, Jens Alfke wrote:
> I don’t follow. What’s the “resource” you’re talking about here?
In your case, the NSEnumerator .
Would the solution I proposed in my post work for you ?
Simon.
___
sqlite-users mailing list
sqlite-user
> On Jan 30, 2017, at 9:10 PM, Simon Slavin wrote:
>
> Nope. Cannot do that. Any number of things might happen between the first
> _step() and the _finalize(). For all you know someone might delete the
> object the iterator is currently on instead of just updating it. Then where
> would t
> On Jan 30, 2017, at 8:03 PM, Rowan Worth wrote:
>
> If the iterator isn't exhausted, how do you know when to dispose the
> sqlite3_stmt?
The iterator (which is an Objective-C NSEnumerator object) will be deleted
shortly after it exits scope. Some of the refcounting is deferred via the
auto
On 31 Jan 2017, at 3:29am, Jens Alfke wrote:
> I’ve discovered (after some debugging) that if I iterate over the the rows in
> a table using sqlite3_step, and update each row after it’s returned, Bad
> Stuff happens. Specifically, my query is just getting the first row over and
> over and ove
The iterator pattern has another caveat when applied to sqlite:
foreach (row in statement) {
if (isMatch(row)) {
return true
}
}
return false
If the iterator isn't exhausted, how do you know when to dispose the
sqlite3_stmt? There are other ways to manage the statement
I’ve just run headlong in to the issues described in "No Isolation Between
Operations On The Same Database Connection”. Specifically, I’ve discovered
(after some debugging) that if I iterate over the the rows in a table using
sqlite3_step, and update each row after it’s returned, Bad Stuff happe
11 matches
Mail list logo
