Progress will discontinue Telerik Platform on May 10th, 2018. Learn more

Limitations and Design Considerations

Limitations and Design Considerations

You need to have certain limitations and design considerations in mind when writing relation expanding expressions in Telerik Platform.

Content at a glance:

Write Considerations

When expanding data you are modifying the returned object by altering one if its fields. Therefore you need to be careful when writing the object back to the content type.

If you write the object directly, you are writing a different data type to the field that you originally expanded. If, for example, the original field content was a numerical User ID that you expanded to an alphabetical username, you would be writing a username to a field that expects an ID.

Another consideration comes from field renaming. When writing an object that contains a renamed expanded field, you are effectively creating a new field in the content type named after the renamed field. The original field is not affected.

To avoid these situations, delete the expanded field from the update (create) object before writing the object back.

Security

The expanding of relations results in additional read requests on the server side. Those additional requests inherit the same permissions as the original request.

Filtering and Sorting

Filtering and sorting are enabled only when expanding a single item. Otherwise the request could result in too many internal requests to the underlying database.

For example, if you want to filter the Likes field to return only users with a specific Email, you can only do it for a single activity (GetById request):

Request:
    GET https://api.everlive.com/v1/your-app-id/Activities/{activityId} 
Headers:
    X-Everlive-Expand: {
        "Likes": {
            "TargetTypeName": "Users",
            "Filter": {
                "Email" : {"$regex" : "@telerik.com$"}
            },
            "Sort" : {
                "DisplayName" : 1               
            }
        }
    }

Querying the Content Type that Does Not Hold the Relation

Only "by ID" requests (that return a single item) are allowed when querying the content type that does not hold the relation.

For example:

Request:
    GET https://api.everlive.com/v1/your-app-id/Users/{userId}
Headers:
    X-Everlive-Expand: {
        "Activities.Likes": {
            "ReturnAs": "LikedActivities"
        }
    }

Maximum Result Item Count

Each request result is limited to 50 items when using expand expressions. The limit applies to:

  • The result of the primary query if it uses a filter—In other words if your primary query contains a filter expression and one or more expand expressions, its result will be limited to 50 items.
  • The result of each request triggered by expand expressions—In other words, if your primary query contains one or more expand expressions for multiple relations, each of the ensuing requests is limited to 50 result items.

Overall Request Count

The overall request count is limited to 25 when using expand expressions. This includes the primary request and all requests that ensue from the included expand expression.

File Metadata Expansion

File metadata can only be expanded when querying the content type the holds the relation field (that points to the Files content type).

Nested Expands

Nested expands are subject to the following limitations:

  • Although the nesting depth is not limited (i.e. you can nest as many levels down as you like), there are other limitations that may prevent you from nesting too deep. See Maximum Result Item Count and Overall Request Count for details.
  • Expanding a multiple relation after another multiple relation is not possible. This also applies to the case where you are querying the content type that does not hold the relation (the ContentType.RelationField syntax).

Using Expand Expressions in Cloud Code

It is possible to set expand expressions in Cloud Code. It is worth noting that in this case your client code does not need to know about what is being expanded, it just gets the additional data. This might prove useful if you are invoking the same requests with the same expand expressions from client applications for different platforms.

Always use the beforeRead event when setting expand expression definitions in Cloud Code. For example:

Everlive.Events.beforeRead(function (request, context, done) {
        request.expandExpression = {
            RelationFieldDefinition: {
                ...
            }
        }
        done();
});
Start a free trial Request a demo
Contact us: +1-888-365-2779
sales@telerik.com
Copyright © 2016-2017, Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.