Recipes for LoopBack Models, part 5 of 5: Model Synchronization with Relational Databases

Last time, we looked at using LoopBack while defining models from scratch. In the last part of this 5-part series, we demonstrate how to synchronize your data.

Now I have defined a LoopBack model, can LoopBack create or update the database schemas for me?

LoopBack provides two ways to synchronize model definitions with table schemas:

  • Auto-migrate: Automatically create or re-create the table schemas based on the model definitions. WARNING: An existing table will be dropped if its name matches the model name.

  • Auto-update: Automatically alter the table schemas based on the model definitions.


Let’s start with auto-migration of model definition. Here’s an example:

Assuming the model doesn’t have a corresponding table in the Oracle database, you can create the corresponding schema objects to reflect the model definition:

This creates the following objects in the Oracle database:

  • A table CUSTOMER_TEST.

  • A sequence CUSTOMER_TEST_ID_SEQUENCE for keeping sequential IDs.

  • A trigger CUSTOMER_ID_TRIGGER that sets values for the primary key.

Now we decide to make some changes to the model. Here is the second version:


If we run auto-migrate again, the table will be dropped and data will be lost. To avoid this problem use auto-update, as illustrated here:

Instead of dropping tables and recreating them, autoupdate calculates the difference between the LoopBack model and the database table definition and alters the table accordingly. This way, the column data will be kept as long as the property is not deleted from the model.


This series has walked through a few different use cases and how LoopBack handles each. Take a look at the table below for a round-up of what was covered.

RecipeUse CaseModel Strict ModeDatabase
Open ModelTaking care of free-form datafalseNoSQL
Plain ModelDefining a model to represent datatrue or falseNoSQL or RDB
Model from discoveryConsuming existing data from RDBtrueRDB
Model from introspectionConsuming JSON data from NoSQL/RESTfalseNoSQL
Model synchronizationMaking sure models are in synctrueRDB





What’s next?

Recipes for LoopBack Models, part 4 of 5: Models by Instance Introspection

Last time, we looked at using LoopBack with relational databases, allowing you to consume existing data. This time around, we are looking at your options when the data does not have a schema.

I have JSON documents from REST services and NoSQL databases. Can LoopBack get my models from them?

Yes, certainly! Here is an example:


Now we understand that we can define the models from scratch, or discover them from relational databases or JSON documents. How can we make sure that the database models are in sync with LoopBack if some of the database models don’t exist or are different? LoopBack has APIs to facilitate the synchronization. We will demonstrate how next time, in the final part of this series.

What’s next?

Recipes for LoopBack Models, part 3 of 5: Model Discovery with Relational Databases

In the prior part of this 5-part series, we looked at schema definitions and defined a model using an in-memory source to mock up the data access. This time around, we are looking at model discovery with existing  relational databases or JSON documents.

I have data in an Oracle database. Can LoopBack figure out the models and expose them as APIs to my mobile applications?

LoopBack makes it surprisingly simple to create models from existing data, as illustrated below for an Oracle database. First, the code sets up the Oracle data source. Then the call to discoverAndBuildModels() creates models from the database tables. Calling it with associations: true makes the discovery follow primary/foreign key relations.

For more information, please check out:

Discovery from relational databases is a quick way to consume existing data with well-defined schemas. However, some data stores don’t have schemas; for example, MongoDB or REST services. LoopBack has another option here. Find out more next time, when we will take a look at models by instance introspection in part 4 of this series.

What’s next?

Recipes for LoopBack Models, part 2 of 5: Models with Schema Definitions

Last time, we looked at how you can mobilize data through LoopBack with open models, which works well for free-form style data.  This time around, we are looking at models with schema definitions.

I want to build a mobile application that will interact with some backend data. I would love to see a working REST API and mobile SDK before I implement the server side logic.

In this case, we’ll define a model first and use an in-memory data source to mock up the data access. You’ll get a fully-fledged REST API without writing a lot of server side code.

The snippet above creates a ‘Customer’ model with a numeric id, a string name, an array of string emails, and a numeric age. Please also note we set the ‘strict’ option to be true for the settings object so that LoopBack will enforce the schema and ignore unknown ones.

For more information about the syntax and apis to define a data model, check out:

You can now test the CRUD operations on the server side. The following code creates two customers, finds a customer by ID, and then finds customers by name to return up to three customer records.

To expose the model as a REST API, use the following:

Until now the data access has been backed by an in-memory store. To make your data persistent, simply replace it with a MongoDB database by changing the data source configuration:

For more information about data sources and connectors, please check out:

When defining a model, it may be troublesome to define all the properties from scratch. Fortunately, LoopBack can discover a model definition from existing systems such as relational databases or JSON documents, as we’ll show in part 3 next week.

What’s next?

Recipes for LoopBack Models, Part 1 of 5: Open Models

Rich mobile applications are driven by data. Data can be produced and consumed by mobile devices, browsers, cloud services, legacy applications, databases, and other backend systems.

LoopBack mobilizes data through models that represent business data and behavior. LoopBack exposes models to mobile apps through REST APIs and client SDKs. You need to interact with the model differently, depending on the location and type of data. In this 5-part blog series, I’ll explain some of the most important recipes for working with LoopBack models:

  • Part 1: Open models – for free-form data.

  • Part 2: Models with schema definitions such as relational databases.

  • Part 3: Model discovery with relational databases – consuming existing data from a relational database.

  • Part 4: Models by instance introspection – Consuming JSON data from NoSQL databases or REST APIs.

  • Part 5: Model synchronization with relational databases – keeping your model synchronized with the database.

The source code is available at

Let’s start with the simplest one: open models.

I’m mobile developer. Can LoopBack help me save and load data transparently? I don’t need to worry about the backend or define the model up front, because my data are free-form.

For free-form data, use an open model that allows you to set any properties on model instances.

The following code creates an open model and exposes it as a REST API:

Notice the call to ds.createModel() with only a name to create an open model.

To try it out, enter the following command:

This command POSTs some simple JSON data to the LoopBack /forms URI.

The output that the app returns is a JSON object for the newly-created instance.

The id field is a unique identifier you can use to retrieve the instance:

Note: Your ID will be different as it is generated by the database. Please copy it from the POST response.

Try submitting a different form:

Now you see the newly created instance as follows:

For the complete list of REST APIs that LoopBack scaffolds for a model, please read:

If you have StrongLoop Suite (  installed, you can build and run this project from scratch in 5 commands:

Now open a browser and point it to http://localhost:3000/explorer.

You get an explorer to try the forms APIs right away. The UI is pretty straghtforward, feel free to play with it. For more information, check out:

The open model is simple and flexible. It works well for free-form style data because the model doesn’t constrain the properties and their types. But for other scenarios, a predefined model is preferred to validate the data and ensure it can be exchanged among multiple systems.

Next week, we’ll talk about models with schema definitions.

What’s next?