Query optimization best practices

You can optimize WSRR read and query performance, by using the following guidelines.

Use the minimum amount of information

Always use the minimum amount of information needed to identify the required objects.

If you need only a few properties from an object: do a property query, not a retrieve or graph query.
If you are unsure how to resolve the objects you want, perform property queries iteratively until you must perform a full retrieve on a smaller set of candidate objects.
A good query will aim to bring back as few objects as possible (less than ten) by using a minimum number of query criteria.

The filter and query criteria are listed with an indication of the approximate impact weighting in brackets.

[1] modelled properties ( name, namespace, description, and other modelled properties )
[2] classifications
[2] modelled relationships (such as 'ports' on WSDLService)
[2] user-defined properties ( such as business modelled properties )
[4] user-defined relationships ( such as business modelled relationships )

The various options in increasing impact include:

Property queries that return only specific object property values.
Graph query depth 0, which will return only properties and classifications.
Graph query depth 1, which will return properties and relationships but not the objects at the end of the relationships.
Graph query depth 1 with content. Avoid retrieving content in the query unless it is really required - this will allow the object retrieved to be updated safely.
Graph query depth 2 or -1, only use if absolutely necessary

Wherever possible prevent users from issuing complex XPath queries. These are defined in UI ViewQuery definitions or coded into plug-ins.

Modify the UI view query definitions to provide concise, specific and meaningful views of WSRR data for each user / perspective
if a view is likely to have large amounts of data (500 rows or more) it is best to turn off the UI filters
Treat XPath as a WSRR Developer tool, not as a tool for users to issue queries.

All relationships are directional in WSRR. The full graph follows only relationships so directionality can be used to break up graphs and prevent the whole registry being retrieved as a dependency on one object.
Use reverse relationship view queries if information needs to be shown in a view, rather than creating bidirectional relationships.
Be very careful when associating resources with each other especially if the resources themselves have large or complex graphs.