info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
sqlite & async read data
69 views
Skip to first unread message
Едуард Зозуля
Apr 21, 2019, 2:46:09 AM4/21/19
to
Сan I get the data from the sqlite asynchronously ?
Is there, for example, a syntax of this kind:
db eval "select * from tblname" -callback myreadproc
proc myreadproc { args } {
puts $args
}
Thanks.
Is there, for example, a syntax of this kind:
db eval "select * from tblname" -callback myreadproc
proc myreadproc { args } {
puts $args
}
Thanks.
Manfred
Apr 21, 2019, 3:59:48 AM4/21/19
to
See https://www.sqlite.org/tclsqlite.html
##
$db eval {select * from tblname} values {
parray values
}
##
or
##
proc myreadproc {args} {
puts $args
}
$db eval "select * from tblname" values {
puts $args
}
myreadproc [array get values]
}
##
regards
Manfred
Am 21.04.19 um 08:43 schrieb Едуард Зозуля:
> Сan I get the data from the sqlite asynchronously ?
>
> Is there, for example, a syntax of this kind:
>
> $db eval "select * from tblname" -callback myreadproc
>
> Is there, for example, a syntax of this kind:
>
Едуард Зозуля
Apr 21, 2019, 4:10:34 AM4/21/19
to
неділя, 21 квітня 2019 р. 10:59:48 UTC+3 користувач Manfred написав:
This code work not asynchronously.
If query executing 60 second, my tcl code will be blocked on 60 second.
My questions about no lock tcl code while being database query executed.
If query executing 60 second, my tcl code will be blocked on 60 second.
My questions about no lock tcl code while being database query executed.
Rolf Ade
Apr 21, 2019, 8:44:39 AM4/21/19
to
build-in solution (build-in into sqlite, I mean) for that.
This is probably, because no one had the need. For sure I can say: Using
sqlite in my (commercial) tcl apps since more than a decade I didn't
feel the need - my queries always returned fast enough.
60 seconds executing time for a query is _loooong_. How big is your
database? What kind of queries are that?
It may be possible to speed up your queries temendious with some careful
crafted SQL or adding one or a few indices.
If that is not possible you could use another thread for the query. Run
your app and maybe GUI in one (main) thread and do the long running
query in another (working) thread. That should keep you app responsive.
Едуард Зозуля
Apr 21, 2019, 8:59:51 AM4/21/19
to
неділя, 21 квітня 2019 р. 15:44:39 UTC+3 користувач Rolf Ade написав:
Thanks ! I know about ways to improve performance - they're all exhausted.
Rich
Apr 21, 2019, 11:12:12 AM4/21/19
to
?????? ?????? <ed.zo...@gmail.com> wrote:
> ?an I get the data from the sqlite asynchronously ?
But, if you use the Thread package, you can run your queries in a
second thread, and submit, and receive, queries and results
asynchronously.
See the -async flag of the ::thread::send command. You'd thread::send
queries to the background thread, and the background thread would
thread::send results back to your main thread.
The background thread would be synchronous as far as actually running
the queries, but asynchronous as far as the main thread is concerned.
> ?an I get the data from the sqlite asynchronously ?
>
> Is there, for example, a syntax of this kind:
>
> $db eval "select * from tblname" -callback myreadproc
>
> proc myreadproc { args } {
> puts $args
> }
>
> Thanks.
Nothing built in to the Sqlite Tcl api.
> Is there, for example, a syntax of this kind:
>
> $db eval "select * from tblname" -callback myreadproc
>
> proc myreadproc { args } {
> puts $args
> }
>
> Thanks.
But, if you use the Thread package, you can run your queries in a
second thread, and submit, and receive, queries and results
asynchronously.
See the -async flag of the ::thread::send command. You'd thread::send
queries to the background thread, and the background thread would
thread::send results back to your main thread.
The background thread would be synchronous as far as actually running
the queries, but asynchronous as far as the main thread is concerned.
Едуард Зозуля
Apr 22, 2019, 3:58:37 AM4/22/19
to
неділя, 21 квітня 2019 р. 18:12:12 UTC+3 користувач Rich написав:
Thanks for the answer !
I think that working with the database through an asynchronous function should be more efficient than through threads.
For example, if I run two heavy asynchronous queries to a database, then each query the finded row item will consistently return it.
That is to say:
the first query, returned a few row
then
the second query, returned a few row
and so on ....
But, In one thread, these queries will be executed sequentially. I have a many the database query: about 60 per second.
Creating 360 threads, if a request execution time of 60 seconds - not beautifully.
Do not know, is there any hope for implementation of asynchronous code in the tclsqlite?
I think that working with the database through an asynchronous function should be more efficient than through threads.
For example, if I run two heavy asynchronous queries to a database, then each query the finded row item will consistently return it.
That is to say:
the first query, returned a few row
then
the second query, returned a few row
and so on ....
But, In one thread, these queries will be executed sequentially. I have a many the database query: about 60 per second.
Creating 360 threads, if a request execution time of 60 seconds - not beautifully.
Do not know, is there any hope for implementation of asynchronous code in the tclsqlite?
Rich
Apr 22, 2019, 6:17:13 AM4/22/19
to
?????? ?????? <ed.zo...@gmail.com> wrote:
> ??????, 21 ?????? 2019 ?. 18:12:12 UTC+3 ?????????? Rich ???????:
available via Sqlite, so you do not have this as an option (unless you
create it for yourself).
> Do not know, is there any hope for implementation of asynchronous
> code in the tclsqlite?
That would be a question best addressed to D. Richard Hipp and the
other Sqlite maintainers.
> ??????, 21 ?????? 2019 ?. 18:12:12 UTC+3 ?????????? Rich ???????:
>> ?????? ?????? wrote:
>> > ?an I get the data from the sqlite asynchronously ?
>> >
>> > Is there, for example, a syntax of this kind:
>> >
>> > $db eval "select * from tblname" -callback myreadproc
>> >
>> > proc myreadproc { args } {
>> > puts $args
>> > }
>> >
>> > Thanks.
>>
>> Nothing built in to the Sqlite Tcl api.
>>
>> But, if you use the Thread package, you can run your queries in a
>> second thread, and submit, and receive, queries and results
>> asynchronously.
>>
>> See the -async flag of the ::thread::send command. You'd thread::send
>> queries to the background thread, and the background thread would
>> thread::send results back to your main thread.
>>
>> The background thread would be synchronous as far as actually running
>> the queries, but asynchronous as far as the main thread is concerned.
>
> Thanks for the answer !
> I think that working with the database through an asynchronous
> function should be more efficient than through threads.
The fact is, you do not have an asynchronous function currently
>> > ?an I get the data from the sqlite asynchronously ?
>> >
>> > Is there, for example, a syntax of this kind:
>> >
>> > $db eval "select * from tblname" -callback myreadproc
>> >
>> > proc myreadproc { args } {
>> > puts $args
>> > }
>> >
>> > Thanks.
>>
>> Nothing built in to the Sqlite Tcl api.
>>
>> But, if you use the Thread package, you can run your queries in a
>> second thread, and submit, and receive, queries and results
>> asynchronously.
>>
>> See the -async flag of the ::thread::send command. You'd thread::send
>> queries to the background thread, and the background thread would
>> thread::send results back to your main thread.
>>
>> The background thread would be synchronous as far as actually running
>> the queries, but asynchronous as far as the main thread is concerned.
>
> Thanks for the answer !
> I think that working with the database through an asynchronous
> function should be more efficient than through threads.
available via Sqlite, so you do not have this as an option (unless you
create it for yourself).
> Do not know, is there any hope for implementation of asynchronous
> code in the tclsqlite?
other Sqlite maintainers.
0 new messages