query
Perform searches on system metadata objects and their relationships.
Usage: <system> query <table> [filters...]
required arguments:
| The type of object/relationship to query, must be one of |
optional arguments:
| One or more filters to filter the results by. See Basic Filters and Filter and Field Reference by Table below for more information. |
Basic Filters
Filters are a comma separated list of literal values or wildcard expressions matched against fields of the same name. Filter values are combined using or semantics, whereas multiple filters are combined using and semantics.
For example, the query:
> system query component-relationships --from-component a,b --to-component c,d
would match the component relationships “from a to c”, “from b to c”, “from a to d”, and “from b to d”.
Query Chaining
Multiple queries may be chained together by feeding fields from previous results into filters of a given query. This allows for advanced queries that traverse different types of objects or relationships in the system. For example, a query to retrieve file relationships that are involved in violations at the component level would be:
> system query component-relationships --severity error > system query file-relationships --from-component @from_component --to-component @to_component
The @<field-name>
operator specifies that the unique values from a given field in the previous query are to be used in the current query as a series of literal match filters. When multiple chained filters are combined, matches are performed row-by-row. This means that a given object or relationship will only be returned if it matches all chained fields in a given row. For example, if the above query for component relationships returned two relationships:
From A to B
From B to C
Then, in the query on file-relationships
, only file relationships from components A to B, and B to C would be returned.
Filters containing chained fields and filters containing values are combined with and semantics. For example, to reduce the results of the above file-relationships
query by erroneous file relationships:
> system query component-relationships --severity error > system query file-relationships --from-component @from_component --to-component @to_component --severity error
Chained fields cannot be combined with values in the same filter. For example, a filter of --from-component @from_component,a
is invalid.
The CLI will interpret any values starting with @
as chained fields. To specify a filter value starting with a literal @
, escape the @
at the beginning of the value with a backslash (\
):
> system query files --name \@sources.js
Filter and Field Reference by Table
components
Filters:
| The name of the component. May include wildcard expressions. |
Fields:
| The name of the component. |
| The number of files inside the component. |
| How many components directly depend on the component. |
| How many components are directly depended on by the component. |
| The number of files within the component that are members of a cyclic group. A cyclic group is a group of files that are, either directly or indirectly, circularly dependent upon each other. |
component-relationships
Filters:
| The component that uses the |
| The component used by the |
| The type of relationship between the components. Must be one or more of: actual_dependency, |
| The state of the relationship between the components. Must be one or more of: ok, circular, undeclared, missing. |
| A coarse indicator of the level of attention to pay to a given relationship. Must be one or more of: |
Fields:
| The component that uses the to_component. |
| The component used by the from_component. |
| The type of relationship between the components. See Component Relationship Types for more information. |
| The state of the relationship as determined by CodeMRI. See Relationship States for more information. |
| A coarse indicator of the level of attention to pay to a given relationship. See query#Severities for more information. |
| The number of files involved in the given component relationship. Will be |
| The number of entities involved in the given component relationship. Will have a value of |
files
Filters:
| The relative path of the file. May include wildcard expressions. |
| The component in which the file resides. May include wildcard expressions. |
| Restrict the search to files assigned to the given list of files tagged with the provided list of file property / value combinations. At time of writing, the only recognized value for file properties is |
| The programming language of the file, as detected by static analysis. May include wildcard expressions. |
| The McCabe complexity class of the file. Must be one of the following: |
| |
| |
| |
| |
| |
| Restrict search to files indirectly dependent upon a given file or set of files matching the given expression. |
Fields:
| The relative path of the file. |
| The component the file resides in. |
| The programming language of this file detected by static analysis. |
entity_count | The number of entities contained in this file. |
| The number of files that directly depend on this file. |
| The number of files this file directly depends on. |
|
|
| The ID of the cyclic group this file is part of. |
| The size, in files, of the cyclic group this file belongs to. |
| A simplified representation of the complexity of this file. |
| The cyclomatic complexity of this file. |
| The number of source lines within the file. |
| The ratio of comment lines to source lines within this file. |
| Property values assigned to the given file. |
Please note that this command may display files not present in the reports. CodeMRI removes files deemed “isolates” from reports. A file is an “isolate” if:
it does not depend on any other files.
no other files depend on it.
file-relationships
Filters:
| The name of file that uses the |
| The name of the file used by the |
| The component containing the file that uses the |
| The component containing the file used by the |
| Files tagged with the file property matching the given property/value combination. At time of writing the only supported value is |
| Files tagged with the file property matching the given property/value combination. At time of writing the only supported value is |
| The state of the relationship between the files. Must be one or more of: |
| A coarse indicator of the level of attention to pay to a given relationship. Must be one of: |
| Restrict search to files indirectly dependent upon a given file or set of files matching the given expression. |
| The cyclic group ID of the file that uses the |
| The cyclic group ID of the file used by the |
Fields:
| The file that uses the |
| The file used by the |
| The component that uses the |
| The component used by the |
| Property values assigned to the file on the |
| Property values assigned to the file on the |
| The state of the relationship. See Relationship States for more information. |
| A coarse indicator of the level of attention to pay to a given relationship. See query#Severities for more information. |
| The number of entities involved in the given file relationship. |
entities
Filters:
| The name of the entity. May include wildcard expressions. |
| The type of the entity. May include wildcard expressions. |
| The file the entity is contained in. May include wildcard expressions. |
| The component the entity is contained in. May include wildcard expressions. |
| The language of the file the entity is contained in. May include wildcard expressions. |
| The McCabe complexity class of the file. Must be one of the following: |
| |
| |
| |
| |
|
Fields:
| The name of the entity. |
| The type of the entity. Please note that these types are not standardized across static analysis engines. |
| The relative path of the file that owns the entity. |
| The component that owns the entity. If the entity is not part of any component, this field will be blank. |
| Whether the entity is in a group of entities that are circularly dependent on each other. |
| The ID of the cyclic group the entity belongs to. Will be |
| The number of files in the cyclic group the entity belongs to. Will be |
| The programming language the owning file was written in, as detected by the static analysis engine. |
| The McCabe complexity of the entity, as determined by static analysis. May not be valid for all entity types, will be |
| The McCabe complexity class of the entity, as determined by CodeMRI. May not be valid for all entity types, will be |
| The number of lines of code (LOC) in the entity. May not be valid for all entity types, will be |
| The ratio of comment lines to source lines in the entity. May not be valid for all entity types, will be |
entity-relationships
Filters:
| The name of the entity that uses |
| The name of the entity used by the |
| The file that owns the |
| The file that owns the |
| The name of the component that owns the |
| The name of the component that owns the |
| The state of the relationship between the |
| The weight of the relationship state. Can be overridden by the user. Must be one of |
Fields:
| The name of the entity that depends directly on the |
| The name of the entity that the |
| The file that owns the |
| The file that owns the |
| The line number in the |
| The column in the |
| The name of the component that owns the |
| The name of the component that owns the |
| The type of the relationship between the |
| The state of the relationship between the |
| A coarse indicator of the level of attention to pay to a given relationship. See query#Severities for more information. |
Relationship States
Within a system, a given relationship may be in one or more “states”. Silverthread determines relationship states by looking at both user-supplied rules as well as the network of relationships within the codebase. At the time of writing, the possbile relationship states are:
| The relationship is not introducing cyclicality or violating any user-defined rules, if this is a component relationship, the relationship has been explicitly declared in user-defined architecture and is present within the codebase. |
| This relationship forms part of a cycle, either directly or indirectly. |
| This relationship is present in the codebase, but not in the user-defined architecture. Undeclared relationships may indicate signs of divergence from agreed upon architecture or gaps in documentation of codebase architecture. |
| This relationship is in direct violation of a user-defined rule. |
| This relationship has been declared inside of the user-defined architecture, but is not present in the codebase. |
| The relationship is in direct violation of one or more user-defined constraints. For more information about constraints see the system architecture command. |
Component Relationship Types
Component relationships have multiple types:
| component relationships that reside in the actual codebase. |
| component relationships provided by the user in user-defined architecture. |
Severities
Severities provide a simple abstraction over relationship states for the purpose of checking a codebase for problems. Severities are initially computed by Silverthread, but may be overridden explicitly by applying user-defined rules. The levels of severity recognized by Silverthread are in the table below:
| The state of the relationship is either |
| The relationship is problematic, but is not an immediate issue. Undeclared and missing component dependencies fall under this category. This also may be a circular or illegal relationship that the user has elected to ignore until a later time. It is common to mark pre-existing issues as warnings. |
| The relationship is an issue that deserves immediate attention. Circular and illegal dependencies fall under this category. |