Lazy evaluation of lists

Hi everyone,

Does FQL evaluate its collections lazily?

For example, when I do something like:

Take(
    10,
    Append(
        <query A>,
        <query B>
    )
)

(And let’s assume there is no way of doing both query A and query B in a single Paginate call because they’re very complex.)

Is query B evaluated if query A returns 10 or more results?

The reason I’m asking is that I have some very complex queries (also involving Reduce and Map) and I am looking for ways to avoid unnecessary reads and computations.

If the collections are not evaluated lazily (which I suspect is the case), are there any alternatives other than the client doing many small queries (and stopping once it has enough results)?

It’s a good question. The query as you have it not lazy. Each call to Paginate is going to get all the items that it calls for. The laziest thing to do is to combine Sets with Union, Intersection, etc. and only call Paginate once with the specific size that you want.

So, if possible, rather than Append try to use Union with multiple Sets before running Paginate. For example, this would be as lazy as possible:

Paginate(
  Union(
    <Set A>,
    <Set B>
  ),
  { size: 10 }
)

But I know that’s not always possible. If you can share more of what query A and query B then maybe we can brainstorm more about it.

1 Like

Interesting, thanks! This could certainly help.

The solution I went with for now was to issue the individual queries from the client, where I’m then able to have a custom, sufficiently intelligent logic to decide on the concurrency level of the queries (in my use case, there can be many of them, not just two) - probably at the cost of increased overall latency, but hopefully with reduced financial cost for Fauna read/compute ops.