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?
On Mon, May 28, 2018 at 11:01 AM Hick Gunter <h...@scigames.at> wrote: > As long as you are and remain in serialized mode, you can re-use the same > connection from different threads. > > If you can guarantee that each thread will have it's own, personal, > connection, you may achieve a performance increase by using multithread > mode. > > In single thread mode, all the checks are turned off and it is up to you > to make sure that exactly 1 thread does all the calls to SQLite. This mode > is fastest. > > -----Ursprüngliche Nachricht----- > Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] > Im Auftrag von Torsten Curdt > Gesendet: Montag, 28. Mai 2018 10:38 > 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 to split that one function into two (new_data, > needs_update) > which is not so easy. > Plus that also makes things less portable (not this really is a > requirement though). > > WAL mode seems to solve this for me much better. At least I don't see any > drawbacks yet. > I am just wondering if having both statements on the same connection is a > valid way of using this. > > cheers, > Torsten > > On Mon, May 28, 2018 at 10:25 AM Hick Gunter <h...@scigames.at> wrote: > > > It is possible to bring an external resource into SQlite by writing > > user-defined functions and/or virtual tables. This would allow > > something > > like: > > > > UPDATE <table> set (<rowlist>) = new_data(<arguments>) where > > needs_update(<arguments>); > > > > With the UDF returning 1 (TRUE) if the current row (identified by the > > arguments) needs 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, 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 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> wrote: > > > > > BTW why not to update all rows by single update query? > > > > > > 2018-05-27 20:30 GMT+02:00, Torsten Curdt <tcu...@vafer.org>: > > > > I am doing a select, then iterate through the resultset and on > > > > each row call update on that row. > > > > I am using the golang driver and ran into the issue that on the > > > > update > > > the > > > > database is still locked from the select. > > > > > > > > https://github.com/mattn/go-sqlite3/issues/569 > > > > > > > > I have read http://www.sqlite.org/cvstrac/wiki?p=DatabaseIsLocked > > > > and > > > IIUC > > > > these types of updates should be possible since version 3.3.7 > > > > though > > > > - > > > and > > > > I am using 3.19.3. > > > > > > > > Any suggestion on how to track down why the updates fail? > > > > > > > > cheers, > > > > Torsten > > > > _______________________________________________ > > > > sqlite-users mailing list > > > > sqlite-users@mailinglists.sqlite.org > > > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-use > > > > rs > > > > > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@mailinglists.sqlite.org > > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > > ___________________________________________ > > Gunter Hick | Software Engineer | Scientific Games International GmbH > > | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 > > | (O) > > +43 1 80100 - 0 > > > > May be privileged. May be confidential. Please delete if not the > addressee. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ___________________________________________ > Gunter Hick | Software Engineer | Scientific Games International GmbH | > Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) > +43 1 80100 - 0 > > May be privileged. May be confidential. Please delete if not the addressee. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
