■
|
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 execution of the
queries.
|
■
|
To avoid future
compatibility issues with your
vSphere Web
Client 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
vSphere Web
Client extension, you must not use any custom properties defined
by the
vSphere Web
Client modules. These properties are prone to change in the
future. You must use only the properties defined in the vSphere Web Service 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 execution. 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 execution 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.
|