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 ObjectIdentityConstraints, PropertyConstraints, and RelationalConstraints, 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 PropertyConstraints, 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 CompositeConstraints. 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.