Built.io Named in Gartner's 2018 Magic Quadrant for Enterprise iPaaS for 2nd year! Get a copy of the report here.

Built.io Blog

Working With Uniqueness In Built.io Backend


Built.io Backend is an enterprise-grade mobile Backend-as-a-Service (mBaaS) that allows companies create applications without having to design, build, or maintain a custom backend technology stack. While most of the features and specifications of the platform are covered in detail on our documentation site, there is one particular feature that needs special attention: Uniqueness.

What Do We Mean By Uniqueness?

Uniqueness refers to validating uniqueness of values of a field. This means that if a field of a class is marked as unique, the values entered for this field while object creation should be unique. The value entered in this field should not be the same as any of the values entered for this field in any objects of the same class.

So, for instance, if the ‘first_name’ field of a class is marked as unique, no two objects of this class can have same values for ‘first_name’.

Built.io Backend performs a validation for fields marked as unique. If the value entered for the fields marked as unique is not unique, Built.io Backend will not allow you save/create the object.

Let’s quickly look at the steps to mark a field as unique:

  • Create a new class
  • Add any field to the class (e.g., Name)
  • Check the 'Unique' option checkbox
  • Backend 1.png

Note: You can, at any time, mark the field as not unique. No data is lost in this case.

Compound Uniqueness

Uniqueness can be applied on a combination of two or more fields as well. In such a case, Built.io Backend validates the uniqueness of the combined values of the fields.

So, for instance, compound uniqueness has been applied on ‘Name’ and ‘Age’ fields of a class.

In such a case, many objects of a class may have John as name and  30 years as age. But the combination of John, 30 years (‘John’ as name along with ’30 years’ as age) could be used only once.

Let’s see how this is implemented in a class.

  • Create a new class
  • Add any field to the class (e.g., Name)
  • Check the 'Unique' option checkbox
  • In the 'Unique Path' field, select the field that you wish to add to make combined uniqueness
  • Backend 2.png

The sub-fields that are part of a Group field can also be added to the unique path. So, if, for instance, there is an ‘Address’ field that contains ‘Street’ and ‘City’ as its sub-fields, you can add ‘address.street’ and ‘address.city’ sub-fields also to the unique path of a field that is marked as unique.

backend 4.png

Uniqueness For Multiple Fields

Fields that are marked as ‘Multiple’ can be marked as ‘Unique’. In this case, the multiple values entered for the field should not be the same as any other object’s multiple values for this field.

However, fields marked as ‘Multiple’ cannot be part of some other field’s unique path. So, for instance, ‘phone number’ (which is a ‘Multiple’ field) can be marked as unique. However, it cannot be added to the ‘Name’ field’s unique path.

Modifying Unique Fields

It’s important to note that once you define compound uniqueness for one or more fields, modifying the schema of these fields or changing the unique path will result in data loss.

Let’s consider an example to understand this well. Let’s say you have a class called ‘Members’, with ‘name’, ‘age’, ‘gender’ and ‘profession’ as its fields. You have defined compound uniqueness for ‘name’, ‘age’ and ‘gender’ fields, i.e., you mark the ‘name’ field as unique, and add ‘age’ and ‘gender’ fields to its unique path.

After adding objects to this class, if you change the ‘name’ field as not unique, it will  not result in data loss.

However, if you add a new field to the ‘name’ field’s unique path (e.g., ‘profession’) or remove a field from its unique path, the values for the ‘name’ field for all the saved objects will be lost.

It is also important to note that Built.io Backend does not allow you to modify the properties or data type of any fields added to the unique path of a field marked as unique. So, for instance, if you wish to change the datatype of ‘age’ from number to text, the system will not allow you to make this change. This is because such modifications will result in data replication, and thereby the uniqueness of data may not be maintained.

Let’s consider an example to understand why such modifications are not allowed.

Using the above example, let’s say the data of your class is as given below:

Name (Unique) Age (Unique path of 'Name') Gender (Unique path of 'Name') Profession
Alex 30 M QA
Maria 28 F Designer
Alex 32 M Designer
Jennifer 36 F Senior Engineer

You wish to change the datatype of ‘Age’ from ‘number’ to ‘text’. The system does not allow such a change. But let’s consider this was possible. In such a case, the data saved under the ‘Age’ field would have been deleted. This would have resulted in the following data table: 

Name (Unique) Age (Unique path of 'Name') Gender (Unique path of 'Name') Profession
Alex Undefined
Maria Undefined F Designer
Alex Undefined M Designer
Jennifer Undefined F Senior Engineer

Here, if you notice, there are two objects with name as Alex and gender Male. This means that despite the compound uniqueness of name, age, and gender fields, such a modification, if permitted, can create data replication. 

It is therefore recommended that you do not modify the schema of any fields that are part of the unique path of any field marked as unique.

Compound Uniqueness For "Owner"

There may be times when you may want to allow unique values for a field per user. This means that each user is allowed to create objects with unique value for the specified field, and any user cannot create more than one object with same value for that field. However, different users can provide same values for this field.

In such a case, you need to mark the field as unique, and select ‘Owner’ as value in ‘Unique Path’.

backend 3.png

So, for instance, if you mark the ‘Name’ field as unique, and add ‘Owner’ to it’s unique path, it will ensure that a users can individually add many objects, but the value entered in the ‘name’ field by any user cannot be same as the name entered in any of the earlier created objects by that user.  

Popular Posts

Subscribe to our blog