This method enables you to specify a schema for Gigya's Accounts Storage. Schemas apply either to the Profile object or to a single user-defined Data object, which is stored in the User account and holds site specific custom data. Note that the data object can itself contain other objects.
- Profile object - the schema sets client side access restrictions and makes content required. Other field definitions in the Profile object are fixed and cannot be changed.
- Data object - the schema sets field names, data types, formatting and encryption as well as client side access restrictions and making content required. The data object schema acts as metadata, guiding Gigya in how to handle the data in the specified fields. If the schema is defined as dynamic, other fields can be added to the storage outside the schema, and Gigya will add them as is, without special treatment.
Changes to the Data object and Profile schema are incremental. When setting the schema for some of the fields, the properties of the omitted fields remain unchanged.
It is important to note that all field names must comply with the following rules:
- Must contain only letters, digits, underscores "_", and/or periods ".".
- Caution: using periods "." in the Name field will create a nested data structure.
- Must begin with a letter.
- Must be a minimum of 2 characters long.
us1.gigya.com- For the US data center.
eu1- For the European data center.
au1- For the Australian data center.
ru1- For the Russian data center.
cn1- For the Chinese data center.
If you are not sure of your site's data center, see Finding Your Data Center.
|JSON object||A JSON object defining the schema to be set on the Profile object. See the format definition of the profile schema object below. Note that you may only set the writeAccess and the required properties on the Profile fields.|
|JSON object||A JSON object defining the schema to be set on the Data object (site specific data stored in the User account ). See the format definition of the data schema object below.|
|JSON object||A JSON object defining the schema to be set on the Subscriptions object . See the format definition of the subscriptions schema object below.|
|JSON object||A JSON object defining the schema to be set on the Preferences object .|
When calling this method on a member of a site group, this parameter determines if the schema being set is applied to the entire site group or a specific child site. You may specify one of the following:
When using this parameter, setSchema behaves differently based on the api key used in the call.
Each REST API request must contain identification and authorization parameters.
Some REST APIs may function without these authorization parameters, however, when that occurs, these calls are treated as client-side calls and all client-side rate limits will apply. In order to not reach client-side IP rate limits that may impact your implementation when using server-to-server REST calls, it is Recommended Best Practice to always sign the request or use a secret. A non-exhaustive list of REST APIs that this may apply to are as follows:
Please refer to the Authorization Parameters section for details.
Profile Schema Object
|fields||JSON object||This object defines properties per data fields. The object contains field names and their corresponding list of properties (see the example below).|
The optional properties are:
Data Schema Object
This object defines properties for data fields. The object contains field names and their corresponding list of properties (see the example below).
Requirements for field names:
Properties that can be set for each field:
When the type property is not specified the type will be deduced from the field name extension or automatically according to the content of the first item. When defining a 'binary' field type, it is not in ferred from the data and must be declared explicitly through the 'type' parameter. Note that a field's type cannot be changed after it contains data. Size limitations for numerical fields are the same as those defined for C#. For details about the size of a KB, see this article.
To delete a field from the schema, you must ensure that data has never been saved to it (even if said data has been deleted), it has no defined type, and then set it to null (see "field6" in the example below). Saving data to a field automatically assigns a type.
Setting a field's properties to null will reset the writeAccess property to "serverOnly" (without deleting the field), if the field contains/contained data and/or has a type setting.
Specifies whether the schema is strict or dynamic. The default value of this parameter is true i.e. dynamic schema. In a dynamic schema you may add new fields that are not defined in the schema to the storage. The new fields are automatically added to the dynamic schema. In a strict schema you can only write into fields that are already defined in the schema.
If dynamicSchema is set to false you must make sure to set field types on creation. Failure to declare a type will prevent the field from being indexed and returned by accounts.search.
Note that the dynamicSchema parameter only applies to server side setAccountInfo calls, and it enables the server to create/modify fields outside of the schema.
When creating Dynamic fields using accounts.setAccountInfo, the write access of these fields is always serverOnly and may impact your implementation. It is recommended best practice to ONLY ever create new schema fields using accounts.setSchema, except in very rare scenarios.
Subscriptions Schema Object
Creates a new Subscriptions Object in the schema. The optional properties are as follows. See the structure of the JSON object below:
This contains the unique name for this subscription in the schema and must be in the format below:
Preferences Schema Object
Creates a new Preferences Object in the schema. The optional properties are as follows. See the structure of the JSON object below:
This contains the unique name for this consent in the schema and must be in the format below:
Schema Object Example
For information relating to Site Groups or SSO, see Site Groups and Single Sign-On.