Further documentation for the query builder.

[leotheloser]

Added supporting documentation for the query builder with multiple common examples (if they are supported) such as

• Querying a table and returning results based on IDs from another table. For example: I only want Events that have taken place in these Locations - Location ID: 1, Location ID 2

[GV14982]

Hi, just to clarify are you looking for better documentation on the query builder? Or are you currently working on a PR for this?

[leotheloser]

Hi, just to clarify are you looking for better documentation on the query builder? Or are you currently working on a PR for this?

Thanks for the reply, I am after better documentation

[GV14982]

What specifically are you looking for?

For instance, querying based on values from another table require you to link the value in the table you are querying. Then you would just use a regular query on that table.

[leotheloser]

Specifically I am looking for more documentation on your query builder using objects, as well as examples of different use cases, querying of different types and across linked tables. If that makes sense

So far the only documentation I can find is your one example:

  {
  where: {
    name: 'AsyncAirtable',
    $gte: {stars: 13}
  }
}

[seanmetzgar]

Hey, this might help. It outlines all the logical operators and examples of how to use them.

https://asyncairtable.com/interfaces/queryobject

[GV14982]

Currently, the query build is not quite finished, so it is missing a method you would need to handle your example, because when you link or lookup from another table, it returns an array (whether or not you have it linked to multiple entries). I will create an issue to track adding the additional methods required for easily handling linked/lookup values from other tables.

As far as the documentation goes, the only issue I foresee is that there are a multitude of ways you can organize your tables, and depending on how you organize it is going to have a large effect on what your queries look like. Even with your one example, I can think of a handleful of ways to structure the tables, and different ways to handle querying them.

If you have specific use cases I can probably help, but I don't want to bloat the documentation too much.