The fuzzer executes randomly generated actions against an Airtable base. In order to find potentially obscure Recalculator bugs, we complemented our existing unit and integration tests with a custom fuzzer. The Recalculator contains many more optimizations to avoid extraneous recalculations, making it quite complicated. Note that if the “First Name” column is updated, only its dependencies (colored green) need to be recalculated. Here “Name” is a formulaic column which depends on “First Name” and “Last Name”, and there are two view filters. Since it runs on every write transaction, it needs to be fast, and so it tries to do the minimum amount of recalculation via constructing a dependency graph.Ī dependency graph used by the Recalculator. The Recalculator analyzes the writes performed in a transaction and determines what formulas, filters, and sorts need to be recalculated in order to produce the correct results. To solve this problem, we have the Recalculator. Views also need to be efficient since our larger customers have many views. For example, since you can add filters on formulaic columns, incorrect formula computation can also incorrectly display information. And there are other downstream impacts as well. If a filter doesn’t work or is not set up properly by a user, a view might incorrectly display information to other users. Airtable’s view feature also powers automations - one of our most common automations is “send an email when data enters this view.”įor this reason, it’s important that views work correctly. Customers use Airtable’s shared views feature in order to share filtered down data with third-party businesses and outside contractors. Most of our users interact with filtered and/or sorted views of their data rather than the entire table. This view shows only records where the “Book” column contains the text “Sein” or where the “Canceled” column is checked. An example of configuring filters on an Airtable view.
0 kommentar(er)
