We make a JSON object of the selected rows and send it to a client in 
one network access to minimize network traffic.  Suitable for clients 
with Javascript.  Packaging of the object can suit the client.  Limits 
are set to avoid choking the client.

Alex Katebi wrote:
> Dennis,
> 
>   After your explanation the prefixing doesn't look so bad.
> 
>   The client might do lots of queries before it exits. But I can drop that
> temp table when client does finalize. I have to have a state machine for
> clients so they don't crash the server by misusing the API anyways.
> 
>   Thank you!
>   -Alex
> 
> 
> 
> On Wed, Jun 11, 2008 at 9:36 AM, Dennis Cote <[EMAIL PROTECTED]> wrote:
> 
>> Alex Katebi wrote:
>>> However there are two things I don't like about this method. One is that
>> I
>>> need to parse the prepared statments and prefix queries, and replace the
>>> table name with the temp table name in the surrogate query. Two is that
>> if
>>> the client does lots of queries before disconnecting from the server it
>>> can waste whole lot of memory. Three is that it is a hack.
>>>
>> Alex,
>>
>> There should be no need to parse the queries other than to check for
>> "select" at the beginning to identify it as a select statement. All
>> select statements would be prefixed with the same prefix string, "create
>> tmp.result as", regardless of the complexity of the original query. You
>> are simply storing the result set of the query into a temp table.
>>
>> Since the temporary result table is always the same, the surrogate query
>> is always the same, "select * from from tmp.result". There is no need to
>> replace any table names.
>>
>> I imagined the temporary memory database would be closed, and hence its
>> memory released, after each query completes. The memory footprint
>> wouldn't grow with each query, it would be the same as that required for
>> the query with the largest result set.
>>
>> It is not a hack of any sort. It simply uses the public APIs to quickly
>> copy the result data into a private table to avoid locking the entire
>> database while those results are slowly scanned by a client.
>>
>> Dennis Cote
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to