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 four fields:
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 four types of models:
Google Cloud SQL—A traditional MySQL table that can be shared among multiple applications,
Default—a G Suite administrator can set up a Google Cloud SQL instance that is shared among App Maker apps in an organization. When this is enabled, a new database is automatically created whenever you add a Cloud SQL data model to an app. Choose this option if your app needs a database that requires no set up and is easy to use.
Custom—Once your administrator sets up a default Cloud SQL instance, you can also set up your own Cloud SQL instance. Choose this option when:
- your application serves a large number of users or stores a large amount of data.
- the database must be shared with other applications.
- you need to manage the database or retain control of the Cloud SQL instance.
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.
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 five tabs:
Fields—Add new fields to a model and adjust settings for existing fields. For example, you could add a
HireDatefield to the
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
Employeemodel 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
Employeemodel that automatically populates the
HireDatefield 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
Employeemodel 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
Employeemodel so that only employees could view the records in the model.
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.