DataService
-Specific Best Practices

Following these recommendations and best practices for writing Data Service queries, helps you improve the performance and scalability of your extensions.

To increase the performance of your extension, you must avoid creating constraints, such as

ObjectIdentityConstraint

PropertyConstraint

s, and

RelationalConstraint

s, and defining

OrderingPropertySpec

objects that have multi-valued properties such as collections and arrays.

For example, when you create a

PropertyConstraint

object that filters all

VirtualMachine

objects based on their

network

property, the filtering process is slowed down. This situation occurs because the back end Data Provider does not support such requests. In such cases, the Data Service fetches the entire data set and then filters the received data.

To improve the performance of your extension, you must avoid creating constraints and defining

OrderingPropertySpec

objects by using the length of multi-valued properties such as collections and arrays.

For example, when you create a

PropertyConstraint

object that filters query results by using the property

network._length

for all

VirtualMachine

objects, the filtering process is slowed down. This situation occurs because the back end Data Provider does not support such requests or does not maintain a separate index for property length. In such cases, the Data Service fetches the entire data set and then proceeds with filtering the received data.

To improve the performance of your extensions, you can use

QuerySpec.resultSpec.maxResultCount

field to limit the returned result set.

To improve the performance of your extensions in case you use

PropertyConstraint

s, you must use the

com.vmware.vise.data.query.Comparator.EQUALS

comparator instead of a text-matching comparator such as

com.vmware.vise.data.query.Comparator.CONTAINS

and

com.vmware.vise.data.query.Comparator.TEXTUALLY_MATCHES

for the

PropertyConstraint

queries. Text-matching operations require a specific database indexing which only a few properties, such as

name

, have. If you need to use a text-matching comparator, you can use

CONTAINS

instead of

TEXTUALLY_MATCHES

, because

TEXTUALLY_MATCHES

requires more complex processing.

To improve the performance of your extensions, you can set a value to the

targetType

field of each

com.vmware.vise.data.PropertySpec

and

com.vmware.vise.data.query.OrderingPropertySpec

object. The Data Service uses the

targetType

field to optimize the performance of the queries.

To avoid future compatibility issues with your extension, you must avoid using multi-valued properties, such as collections and arrays, as the middle nodes in the property paths.

For example, you must not use the property path

configurationEx.drsVmConfig.key

for

ClusterComputeResource

objects because the

drsVmConfig

property of the

vim.cluster.ConfigInfoEx

data object is a collection. In this case, you must request the whole

vim.cluster.ConfigInfoEx

data object.

To avoid future compatibility issues with your extension, you must not use any custom properties defined by the

vSphere Client

modules. These properties are prone to change in the future. You must use only the properties defined in the vSphere Web Services API for the managed objects and data objects.

To avoid future compatibility issues with your extension, you must avoid using the

com.vmware.vise.data.query.Conjoiner.EXCEPT

operator in your

CompositeConstraint

s. Instead you must use negation and De Morgan's laws.

To avoid future incompatibility, avoid using the

relation

field of the

com.vmware.vise.data.PropertySpec

objects.

To avoid future incompatibility, avoid using the

facets

field of the

com.vmware.vise.data.query.ResultSpec

objects.

The Data Service uses the value of the

targetType

field to optimize query run time. To improve the performance of your extensions, set the

targetType

field on every constraint except for the following cases:

com.vmware.vise.data.query.ObjectIdentityConstraint

- You must not specify the

targetType

field because the type is already present in the object reference. You can set the type by using the

target

field of the

ObjectIdentityConstraint

class.

com.vmware.vise.data.query.RelationalConstraint

with

hasInverseRelation

field set to true - The

targetType

field is ignored for such constraints.

To avoid performance issues with your extension in case you use constraints, you must use a specific managed object type as a value for the

targetType

field. For example, if you use an abstract base type such as the

ManagedEntity

managed object type, the speed of the query is slowed down.

To ease the future optimization of your extensions, you must limit the size of each

CompositeConstraint

by limiting the number of child constraints in the

nestedConstraints

field of the

CompositeConstraint

class, and you must avoid also nesting multiple

CompositeConstraint

Make sure that your Data Provider Adapter takes less than 3 seconds to process a query. If your adapter takes too long to process a request, the Data Service cuts the adapter from the result.

Best Practices for Extending the Service Layer

Content feedback and comments

VMware vSphere SDKs and Tools 7.0

DataService-Specific Best Practices

DataService
-Specific Best Practices