A RecordQueryResult represents a set of records. It’s a little bit like a one-off Airtable view: it contains a bunch of records, filtered to a useful subset of the records in the table.
but in the API for Table there’s no way I see to filter when calling selectRecordsAsync(). Is there no way to query only a subset of rows in the table, i.e. the equivalent of a SQL WHERE clause? If so, what is the RecordQueryResult documentation referring to regarding ‘filtered to a useful subset’?
Page 2 / 2
Okay, I’m listening, but I don’t see a clearly presented reason you don’t agree. Here’s why I believe my assertion is correct.
Scenario:
A recycling company has 50 van drivers crisscrossing London picking up an average of ten loads each per day.
They use the Tookan platform to indicate when they arrive at a job and when they finish collecting the recycled goods.
Tookan fires a webhook for each of these two events for all fifty drivers; approximately 1,000 events.
The receiving Airtable webhook needs to link three different tables to the order which reaches two different states - first when they start the job, and then when they complete the job. The linked relationships provide lookups into details concerning the load size, the company the driver works for, and other location data concerning postal codes and taxing authorities.
To create this collection of links and modify them when the job is complete, three different lookups must occur to map the detail records into the order record.
I’m convinced there are many ways to address these requirements but a few things are clear:
Each of the three tables must be queried.
A lookup into each of the three tables must be performed.
A linked record to the order must be established in each table.
My data shows the following given four different approaches. If we extrapolate these values my cached hash seems to win once you pass about 50 updates.
If you have some different data or a better approach for evaluating this, let me know.
Now I got it. You are right. Multiple single events with unpredictable time density
If they intend to raise the limits for enterprise, querying all table will cause bottleneck. Of course, there are some workarounds, but why invent wheel, if index exists.
I think your discussion here provided a prompt to Airtable Devs:
My one complaint with selectRecordsAsync() is that the sorts option fails to sort records brought in via the recordIds option, meaning if you'll need to sort records either with a predefined view, or with a secondary operation after selectRecordsAsync().
I've mentioned this to Airtable support, hoping that it can be addressed one day.
