What I’m trying to do:
Send a partial search iterator to the client .
What I’ve tried and what’s not working:
return app_tables[table_name].search()[:10]
Error:
anvil.server.SerializationError: Cannot serialize return value from function. Cannot serialize <class 'anvil.tables.v2._search.PartialSearchIter'> object at msg['response']['body']['args'][0][0]
This seems odd to me that a full search iterator can be returned to the client, but not a partial one and a bug.
It’s not a bug. It’s something we haven’t supported because it’s not a common thing to want to do. And there aren’t many use cases for sending partial search iterators over the original search iterator.
If sending additional data is a concern you can always set the page size (in the example case to q.page_size(10)). But since search iterator are already lazy it probably wouldn’t buy you that much.
Happy to convert to a feature request.
q.page_size only changes how many rows are loaded at a time though right? It doesn’t only send 10 back to the client instead of all the searched rows?
I am trying to speed things up by doing some incremental loading, so I don’t want to send more than a few rows at a time, so if my assumptions above are correct I think a feature request is appropriate.
Are you saying that returning a regular search iterator is too slow? Or what is the larger context of what you’ve done for optimization
A search iterator loads only a page of rows, along with information about how to fetch the rest as needed. With a page size of 10, it’ll load 10 rows and send those to the client with the search iterator. As the client needs further rows, those will be fetched from the server at that later time.
I’m not sure it is too slow, but I’m investigating speeding up my page load by implementing some kind of incremental loading and I’m not sure what the most efficient way of doing so is.
That matches what I was seeing when playing with it earlier. I think I do want to actually return a partial iterator (or one converted to a list) to implement the incremental loading so that I can have more control with the loading of other rows.
My pages all load very fast because I never pass iterators or row objects.
I always build a json object with what I need and return that to the client, so I’m sure there are no unintentional round trips or unintentional columns or other surprises.
I’m always sure I only have one round trip per user interaction, and that round trip carries only need data.
You could return a client readable view instead of a search iterator and then do all your searching and slicing client side.
That turned out to be the right method! Thanks!