Models Overview

Models organize and store data in App Maker. You can think of a model like a table in a database or a sheet in a spreadsheet. Spreadsheets organize data using named column headers, and store it in the sheet's rows. Similarly, models organize data into named fields, and store it in collections called records.

For example, imagine you work for a new startup, Weyland Corp, and are assigned to build an HR app that tracks employees' names, ID numbers, and dates of birth. In App Maker, you could make an Employee model with three fields: Name, EmployeeID, Active and DateOfBirth. You'd then create a UI to populate that model with a record for each employee. Alternatively, here's how the data would be represented in a spreadsheet:

Types of models

There are five types of models:

• Google Drive Tables—A model that stores data as files in your Google Drive. This model is the easiest to create, but should only be used for datasets smaller than 50 megabytes.

• Calculated—A "virtual" model that uses scripts to produce data. This model lets you manipulate data from models or other sources, but requires significant server-side scripting to set up.

• Google Cloud SQL—A traditional SQL table that can be shared among multiple applications, and even integrated with existing Google Cloud SQL databases. This model supports a wide range of queries, but it requires more work to set up.

• Calculated SQL—A query that is run against a Google Cloud SQL database.

• Directory—A model that obtains information from your organization's directory, for example, email addresses and phone numbers.

The model editor

The model editor is where you define the structure and settings of your models. App Maker directs you to the editor after you create a model, and you can return there at any time by clicking your model's name in the left-hand nav bar. The editor has six tabs:

• Fields—Add new fields to a model and adjust settings for existing fields. For example, you could add a HireDate field to the Employee model.

• Datasources—Define how a model retrieves and stores data when queried, including the subset of records it returns. For example, you could create a datasource for the Employee model that only returns active employees when queried.

• Events—Create server-side scripts that run when your app displays, creates, or deletes records. For example, you could write a script for the Employee model that automatically populates the HireDate field when a user creates a new employee record.

• Relations—Describe relationships between records within a model or across models. For example, you could establish relations in the Employee model between a manager and their direct reports.

• Security—Control which users can create, load, save, or delete records in a model. For example, you could restrict the Employee model so that only employees could view the records in the model.

Display Field

When a model is selected in the left sidebar, a dropdown for selecting the default display field appears in the action bar. Choose a display field specifies which field to use when referring to a record of that model. A display field is commonly used for widgets that select a record like dropdowns. An alternative approach is to specify the display field by binding the names property of a widget to the field you want to display.