Built-in FQL Range function bug?

Help
,
1

While developing yesterday, I noticed a bug in my code where the Range function didn’t actually limit the tuples in my set to my desired range. All members of the set were being returned:

A)

q.Range(
  q.Join(
    propertiesSetRef,
    q.Lambda(
      'propertyRef',
      q.Match(
        q.Index('property_entries_by_date_seconds'),
        q.Var('propertyRef')
      )
    ),
    q.Var('startTimeSeconds'),
    q.Var('endTimeSeconds')
  )
)

After a while of debugging, I moved the Range function inside the Join, and things worked as expected.

B)

q.Join(
  propertiesSetRef,
  q.Lambda(
    'propertyRef',
    q.Range(
      q.Match(
        q.Index('property_entries_by_date_seconds'),
        q.Var('propertyRef')
      ),
      q.Var('startTimeSeconds'),
      q.Var('endTimeSeconds')
    )
  )
)

These two snippets seem functionally identical to me. But for some reason snippet A doesn’t work as expected.

1 Like
2

In the top query, the from and to arguments are being passed to the Join function. Is that intentional or a typo when writing in the post?

In any case, I can confirm what you found. Interestingly, if you use the direct index form of Join rather than the Lambda it works (assuming that propertiesSetRef returns only the Ref as values.

q.Range(
  q.Join(
    propertiesSetRef,
    q.Index('property_entries_by_date_seconds')
  ),
  q.Var('startTimeSeconds'),
  q.Var('endTimeSeconds')
)

So I believe it’s the Lambda version that is causing some issues.

UPDATE:
Doing some more tests with the second query you show, with Range inside of the Lambda: It will cost more Compute Ops since additional FQL has to be run for each entry in the Index.

3

That was

That was just a typo. I’m glad that you were able to reproduce it and I wasn’t going crazy :sweat_smile:

4

Not crazy! :slightly_smiling_face: We have an internal ticket, now, to make the Range function work on Joins with a Lambda argument. Thanks for catching this :+1: