Load Related Records from an Array

also accepts and resolves queries with the array type property.

This tutorial shows you how  can be used based on a real scenario.

You will use it to build a homepage that presents three lists:

• Most popular programmers
• Most valuable programmers
• Most popular companies

One way of solving this is to create three queries and calculate what to display each time the page is accessed. But this is not recommended, at least on the homepage, as it is the very first page of our site. We have to make sure it loads as quickly as possible.
Moreover, pages based on live queries are hard to customize; imagine wanting to add one extra record to be displayed, which is not accessible by the query. When the time comes to create another query, you will find out that the page is so slow.

To speed things up in this scenario, you need an extra structure.

Prerequisites

This is an advanced tutorial. To follow it, you must understand how Databases, Database Fields, and Loading Related Database Items work on Insites.

• Database Fields and Tables
• Database Items
• Loading Related Database Items

Steps

Loading related records from an array property following this scenario is a four-step process:

• Step 1: Creating a record type
• Step 2: Creating the first record
• Step 3: Populate the ranking record
• Step 4: Fetching the ranking record

Step 1: Creating a record type

Create a special record type .

name: ranking
properties:
  - name: name
    type: string

  - name: company_ids
    type: array
    belongs_to: company

  - name: vip_programmer_ids
    type: array
    belongs_to: programmer

  - name: featured_programmer_ids
    type: array
    belongs_to: programmer

It consists of three properties of the type , which serves as cache containers of the homepage lists (parameter is currently only used during import/export operations).

Step 2: Creating the first record

Now create the first record of the record schema that executes the following query:

mutation createRanking {
  record_create(
    record: {
      table: "ranking"
    }
  ) {
    id
  }
}

Step 3: Populate the ranking record

Next, populate the ranking record.

mutation updateRecord($companies: [String], $vips: [String], $featured: [String]) {
  record_update(
    id: 167655
    record: {
      properties: [
        {
          name: "company_ids",
          value_array: $companies
        },
        {
          name: "vip_programmer_ids"
          value_array: $vips
        },
        {
          name: "featured_programmer_ids",
          value_array: $featured
        }
      ]
  }) {
    id
  }
}

Alternatively, you can add a single ID to a specific field with the following query:

mutation updateRecord($name: String!, $id: String) {
  record_update(
    id: 167655
    record: {
      properties: [
        { name: $name, array_append: $id }
      ]
  }) {
    id
    property_array(name: $name)
  }
}

If you want to remove an element from an array, use: .

Step 4: Fetching the ranking record

Finally, you are ready to fetch the ranking record.

query rankings {
  rankings: records(
    per_page: 1,
    sort: {
      created_at: { order: DESC }
    },
    filter: {
      table: { value: "ranking" }
    }
  ) {
    results {
      vips: related_records(
        join_on_property: "vip_programmer_ids",
        foreign_property: "id",
        table:"programmer"
      ) {
        name: property(name: "name")
      }

      featured: related_records(
        join_on_property: "featured_programmer_ids",
        foreign_property: "id",
        table:"programmer"
      ) {
        name: property(name: "name")
      }

      companies: related_records(
        join_on_property: "company_ids",
        foreign_property: "id",
        table:"company"
      ) {
        name: property(name: "name")
      }
    }
  }
}

As a result, you will get a ranking record filled with nested objects - featured programmers and popular companies - ready to be presented on the page.

Your homepage - backed up by a really simple structure - will load much faster because there is only one query. In addition (even though you added some extra code), the final solution is clearer than a complex query and easier to maintain and extend.