Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Vet #1 10/1

We covered the concept of joining between two different tables/query bases in Slate, looking at a test record that has multiple schools, multiple addresses, multiple applications etc. to show why it's important to configure the join to tell Slate which one we want. We talked about the idea of rank in Slate (for example, how Slate decides which school is School 1 or School 2) and I shared this Knowledge Base article. For our first two queries, we compared what happens when you build a query on the Person base, joining to the rank 1 application, and what happens when you build a query on the Application base instead, joining to Person. This helped illustrate the difference between Direct Exports (those available to us because of the query base and joins we've already added) and Extended Exports (those suggested to us as possibilities, if we were to join out to additional tables).

Rebecca also mentioned the need to be able to query for people who have multiple applications for the same term but in different rounds, which is a great use case that is now possible in Configurable Joins. We'll cover that as an example when we get to subqueries in a later session.

Vet #2 10/8

We got our first look at subqueries in Configurable Joins, both exports—for example, concatenated lists of missing checklist items, aggregate counts of the number of schools attended—and filters—returning person records who have at least 2 applications or where the 'Test Account' tag exists. We also discussed how fields like 'Round' belong to the application record, so if I'm interested in querying based on round, that's usually going to indicate that I want a query base of 'Application' rather than 'Person'. The query base by default will include the exports and filters for the data specific to that base (in this case, applications), and then to bring in data about the person record (name, birthdate, citizenship, other information that wouldn't likely change if someone reapplies) I just need to join to Person at the base of the query to make that available.

...