You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 9, 2022. It is now read-only.
Currently, forming the response to _all_docs requires the entire response fit into memory. I've made some changes which should improve the situation so we're copying this response around less, but at its core the response still has to fit. There may be some other changes we could make to improve this in the future, but for now I would suggest you use the limit parameter to access _all_docs in smaller batches.
Agreed. I currently use _all_docs purely as a debugging aid. Our real queries for the db should all be way smaller than that.
Out of curiosity: would it be a goal for TouchDB to be abel to stream out responses from the db? In principle the architecture of it should allow for this (at least for http, I'm not sure if the Java API allows for it).
Yes, that is still the goal. Previously we handed byte streams between the layers, which made that impossible. With the new changes we now pass streams. For things like attachments this is a FileInputStream off of disk. In order to keep everything working, the TouchDB responses are ByteArrayInputStreams to sort of bridge it to the old way of working. At least two more levels of optimization are possible (depending on the type of request).
When the response object is ready, return from the TouchDB single threaded path, then on another thread perform the JSON serialization to a stream for the client. This should work for all requests.
There are some requests where you never really want to have the entire response object in memory (things like _all_docs and large view responses). In these cases ideally we would stream out data to the client as we go. This requires some deeper changes. This level of optimization may be after 1.0.
I believe this to be the relevant log cat output:
The view asked was _all_docs, the database contained about 3000 entries.
The text was updated successfully, but these errors were encountered: