Warning
You are viewing the technical documentation for the Sharetribe Developer Platform. If you are looking for our no-code documentation, see our new help center.

Last updated

Manage search schemas with Sharetribe CLI

This tutorial shows you how to manage extended data search schemas with Sharetribe CLI. With search schemas in place, you can use custom extended data fields as filters in your queries.

Table of Contents

Sharetribe CLI (Command-line interface) is a tool for changing your marketplace's advanced configurations such as transaction processes and email templates.

This tutorial expects that you have already installed Sharetribe CLI and are logged in with your API key. If not, it's recommended to first read the tutorial Getting started with Sharetribe CLI.

In this tutorial, we will add a data schema for the listingType public data field in listings. If your marketplace uses different listing types, you may want to create pages that only show one type of listing.

We will also see how to manage data schema for user profiles. Those schemas are not required for Sharetribe Web Template to work, but can be useful when building own integrations via the Sharetribe Integration API.

Extended data types and schema scopes

There are various types of extended data. Search schema is scoped to a particular type of extended data and the support differs depending on whether the schema is defined for listings or user profiles. The following table summarizes the supported search schema scopes.

Schema forSupported scopes
listingpublic, metadata
userProfilepublic, private, protected, metadata

All types of extended data are editable in Console by the operator, but only public data and metadata can be seen by other marketplace users. To see more details about extended data, see the Extended data reference.

You can store any JSON data in extended data, but only top-level keys of certain type can have search schemas. If there is a mismatch between the defined schema and what is stored to the extended data, the indexing just skips those values.

Schema types and cardinalities

TypeCardinalityExample dataExample query
enumonecondition: "new"pub_condition=new,used
multi-enummanyaccessories: ["bell", "lights"]pub_accessories=has_all:bell,lights or pub_accessories=has_any:bell,lights
booleanonehasPannierRack: truepub_hasPannierRack=true
longonemanufactureYear: 2021pub_manufactureYear=2020,2023
textoneaccessoriesDescription: "Pannier bags and a dog carrier (max 18 pounds) available on request."keywords=bags%20dog%20carrier

Note that the scope in the examples above is public. Please use the correct prefix depending on the scope of the data (meta_ for metadata, priv_ for private data, prot_ for protected data and pub_ for public data). Also, it's worth noting that the query parameter with a text schema is keywords which also targets the title and description attributes of a listing. This query parameter is only supported in listing queries. See Keyword search for more information.

Providing multiple query params for a single field

You can provide multiple values in the query parameter by separating those with a comma. The matching behavior is different for different schema types.

With the enum type like the one above, when you query pub_condition=used,new, you will match listings with either "used" OR "new" as the condition. With the multi-enum, you can control the matching mode explicitly. The query pub_accessories=has_all:bell,lights will match listings with "bell" AND "lights" in the accessories whereas the query pub_accessories=has_any:bell,lights will match listings with either "bell" OR "lights" (or both). If you don't specify the match mode in the query (i.e. pub_accessories=bell,lights), by default we use the has_all mathing mode (AND) for multi enums.

With the text type, you provide a search query, so splitting values with a comma doesn't make sense. You will just provide a string of text as the search query, and the query will be used as described in the keyword search explanation section.

With the long type, you can provide minimum and/or maximum values for the filtering.

For the full query reference, see the /listings/query endpoint API reference.

Listing fields and search settings in Sharetribe Console

When you add listing fields in Sharetribe Console, and select Include this field in keyword search or Add a filter to Search Page, Sharetribe generates a search schema for the field automatically. In Console, the available field type options are

  • free text (search schema: text)
  • number (search schema: long)
  • select one (search schema: enum)
  • select multiple (search schema: multi-enum)

When you review your search schemas with the flex-cli search command, schemas defined for listing fields in console have the following doc string in the search schema:

A listing field defined in Console. Can not be edited with the CLI.

If you then try to add a search schema through Sharetribe CLI for a key and scope that already exists in a Console-originated listing field, you will see the following error:

 › API call failed. Status: 409, reason: A search schema with the same key and scope has already been defined in an asset.

Adding listing search schemas

When creating a listing, the template saves the listing type in the listing's public data. If you are using multiple listing types, you may want to only show one type of listing at a time on the search page. We will create a search schema for the public data attribute listingType to make this kind of filtering possible.

Our marketplace has one Console-created listing field, condition. Let's first see how that search schema looks:

$ flex-cli search -m my-marketplace-dev

Schema for   Scope   Key       Type   Default value   Doc
listing      public  condition  enum                   A listing field defined in Console. Can not be edited with the CLI.

Let's add the search schema for listing type:

$ flex-cli search set --key listingType --type enum --scope public -m my-marketplace-dev

We should now see the details for this new schema alongside our Console created one:

$ flex-cli search -m my-marketplace-dev

Schema for   Scope   Key          Type   Default value   Doc
listing      public  condition     enum                   A listing field defined in Console. Can not be edited with the CLI.
listing      public  listingType  enum

Note that --schema-for option is not needed when adding schema for listing as listing is the default.

If you wish to remove a schema, you can use the search unset command.

Adding user search schema

User profile search schema can be useful, if you have an Integration API application that needs to query different sets of users, depending on some value in the user profile's extended data. For instance, if users have age attribute stored in their protected data, you can use the /users/query endpoint in the Integration API to find users of a certain age range.

Search schema for user profiles can be added as follows:

$ flex-cli search set --schema-for userProfile --key age --type long --scope protected -m my-marketplace-dev

The above adds a search schema for userProfile with long type for a key named "age".

Querying the defined schemas now shows both the listing schemas added on the previous step and the new user profile schema:

$ flex-cli search -m my-marketplace-dev

Schema for   Scope      Key          Type   Default value   Doc
listing      public     condition     enum                   A listing field defined in Console. Can not be edited with the CLI.
listing      public     listingType  enum
userProfile  protected  age          long

If you wish to remove a schema, you can use the search unset command.

Adding a search schema with a default value

Sometimes, you may want to query listings that do not have a certain attibute set. For instance, you may have promoted listings on your marketplace, labelled with a metadata attribute isPromoted: true. If you only have a handful of promoted listings, you likely do not want to tag all other listings with isPromoted: false.

Instead, Sharetribe allows you to set a default value for the search schema – all listings that do not have the attribute get returned when querying the default value.

You can set the default value for a search schema simply by passing a --default flag with the desired default value. To create the search schema described above, the Sharetribe CLI command is as follows:

$ flex-cli search set --key isPromoted --type boolean --scope metadata --default false -m my-marketplace-dev

Now, if we query all the search schemas on the marketplace, we can see the default value for the isPromoted schema in the corresponding column.

$ flex-cli search -m my-marketplace-dev

Schema for   Scope      Key          Type     Default value   Doc
listing      metadata   isPromoted   boolean  false
listing      public     condition     enum                     A listing field defined in Console. Can not be edited with the CLI.
listing      public     listingType  enum
userProfile  protected  age          long

Summary

In this guide, we used Sharetribe CLI to define search schemas for our marketplace. We also saw how schemas defined through Sharetribe Console and Sharetribe CLI interact. We used the public data attributes condition and listingType as examples. In addition, we looked at adding user search schemas for Integration API as well as adding a listing schema with a default value.

For more information, see the following resources: