When searching a data table, it would be useful to be able to specify the number of rows returned from the resulting iterator on each call.
Alternatively, specifying the max number of server calls required to exhaust the iterator would work too.
I would add more optional parameters as mentioned here:
- number of rows per round trip
- which columns to return
- set a maximum number of rows to return
- whether to include the content of the simple object columns
The last one is very important because I noticed that rows containing large amount of data in simple object columns slow down the whole query even if I don’t use the content of the simple object column.
But, when those rows are sent to the client, the content of the simple object is not sent, and another roundtrip will be required if the client needs them.
So, if my feelings are correct (I didn’t make any serious testing here), simple object columns are never lazy in the server and always lazy in the client. This means that we have the worst of both worlds: in the server it’s slow even if you don’t need simple object data, in the client it’s slow when you do need it, because it’s always lazy.
1 Like
Tell me if I’m misunderstanding, but I’m thinking that (1.) is the same as Owen’s OP request, (2.) is the same as his other recent request, (3.) is already (partially*) possible by slicing the SearchIterator, and (4.) is premised on something we’re not sure about yet.
If that’s right, I guess it might make sense to post (4.) as a separate FR? (As an alternative to combining these FRs, we can at least link between them?)
* I guess slicing would return the maximum number of rows all at once rather than batching them lazily until the maximum is reached. Is that the distinction you’re making? I’m having trouble imagining a use case for that, but then I’m a database noob.
Yes, 1 is the same as this.
Yes, 2 is the same as the other requests (in my defense I wrote this before @owen.campbell posted his, well, before I saw it)
Yes, 3 is same as slicing, but slower because now we either use slicing or we have a lazy search. With that argument we would have both maximum limit and lazy search. Perhaps adding two arguments offset and limit would both do the job and sound familiar for people speaking SQL-ish.
I haven’t seen 4 (yet) in the forum, I guess this is new.
When I saw this FR I thought I would hijack it and make it an FR about the search options in general rather than about this specific one. As I said, combining the requests for each argument in one request would increase the visibility. Instead of 4 FRs each with low priority, we would have 1 FR with higher priority.
If it was me, I would like fewer fatter requests rather than many little ones, that require me doing the job of putting them together.
But it is not me, and I’m sure the Anvil team is not going to look at one FR and do the job based on that.
So, one or four or more, doesn’t make a big difference.
1 Like
The only way I can give 4 “votes” (likes) on these 4 topics is if they’re separate requests. If they’re all in one, I can only give 1 vote.
1 Like