: Wednesday, 30 May, 2018 02:34
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re: [sqlite] [EXTERNAL] Re: database locked on select
>
>> Do the select and updates run inside a explicit transaction or they
>> run in individual implicit transactions?
>>
>
>implic
If you are doing each update in a separate transaction it will be much
slower than wrapping them in a single transaction.
See the faq here, it refers to inserts but updates will be the same.
http://sqlite.org/faq.html#q19
Cheers
Paul
On Wed, 30 May 2018 at 09:34, Torsten Curdt wrote:
> >
> Do the select and updates run inside a explicit transaction or they
> run in individual implicit transactions?
>
implicit - does that make a big difference in this case?
If you really want a single query you could write something like:
>
> WITH data(id, c1, c2 /*, ... */) AS (VALUES
>
Do the select and updates run inside a explicit transaction or they
run in individual implicit transactions?
pseudocode:
-
exec(BEGIN);// <- Do you have this?
st_sel = prepare(SELECT ...);
st_upd = prepare(UPDATE tab SET c1=?1, c2=?2, WHERE id=?3);
while(step(st_sel) ==
Yes, manually buffering the resultset or buffering the updates is of course
a possible workaround.
But I would like to avoid that as much as possible.
Another approach is to use limit/offset and then page through the resultset
to control the amount of buffering needed.
But this just feels like a
On 28 May 2018, at 7:56pm, Torsten Curdt wrote:
> Just to clarify: I have a single thread - so intermixing the stepping
> through a resultset and doing an update requires WAL mode but should be
> fine. Correct?
Yes, this should work fine. Obviously, one thread is not going to be trying to
do
an update and the row-valued function new_data()
> > returns the new values.
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: sqlite-users
> > [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> > Im Auftrag von Torsten Curdt
> > Gesendet: Montag
An: sqlite-users@mailinglists.sqlite.org
Betreff: Re: [sqlite] [EXTERNAL] Re: database locked on select
Thanks for the suggestion but I feel that will just make things more complex.
Right now I have one function that does it work and then decides whether to
update or not.
That way I would have
orsten Curdt
> Gesendet: Montag, 28. Mai 2018 10:04
> An: sqlite-users@mailinglists.sqlite.org
> Betreff: [EXTERNAL] Re: [sqlite] database locked on select
>
> I have to query an external resource for each row.
> Unfortunately nothing I can do in a single update query.
> Would
] Re: [sqlite] database locked on select
I have to query an external resource for each row.
Unfortunately nothing I can do in a single update query.
Would mean keeping a lot of data manually in memory.
On Mon, May 28, 2018 at 2:33 AM Abroży Nieprzełoży <
abrozynieprzelozy314...@gmail.com>
10 matches
Mail list logo
