Scope and precedence importing items
When items are exported from a source, those items are made public. However, to use those items you must have access to the module from which the items were exported. And, you must import those items into the module in which you want to use the exported items.
When importing items, it's important that you understand scope and precedence.
Scope defines which items are available for you to use from your current module. Your current module is the module in which you are actively creating searches.
The following list defines what is "in scope" for you to use from your current module:
|Items in the current module||Any item created in a module is available for you to use inside that module.|
|items that are imported||Items that you have imported from other modules are available for you to use in searches in your current module.|
|Items in the namespace where the current module resides||Items, such as datasets, in a namespace are available for you to use in your current module without importing those items.|
In the following image, your current module is the
What you can use when the
response_team module is the current module is described in the following table:
|Type of item||Items in scope||Description|
||Because the |
For comparison, suppose the current module is the
audit_team module, as shown in this image:
Suppose your current module is the the
audit_team module, and you have access to the
response_team module. The following table describes what you can use while creating searches in the
|Type of Item||Items in scope||Description|
When you refer to an item in a search, such as the name of dataset, view, or function, SPL2 resolves the reference to the item by finding the matching item at is "in scope". See Scope.
If there are multiple items in scope that match the reference, for example if the items have the same name and are the same kind of item, then precedence rules determine which item to use.
The following list shows the precedence rules order for items:
- Local. Items created inside a module are local to that module and take precedence over items that are imported or built-in.
- Namespace, for datasets only
Here are a few precedence examples:
- Suppose you create a function called
isErrorin a module. If the module also has an imported function called
isError, then when the function is used in a search statement, the local
isErrorfunction is used. The imported function is ignored. Local items take precedence over imported items.
- Suppose you import a function called
ifinto your module. When the function is used in a search statement, the imported
iffunction is used instead of the built-in
iffunction. The built-in function is ignored. Imported items take precedence over built-in items.
- If one item is a function and the other item is a view, then even though the items have the same name there is no conflict because the items are different kinds of items. SPL2 determines which item to use based on how the item is used in the search. Where and how you specify functions in a search is different than where and how you can specify views.
- If both items are functions with the same name but have a different number of arguments, the function that matches the arguments specified in your search is used. However, if both functions have the same number of arguments an error is returned.
Avoiding precedence errors
To avoid precedence errors, you can use one of the following techniques:
- Rename an imported item
- Import items into a subnamespace inside the module.
For more information, see Items with duplicate names.
Specifying import paths
This documentation applies to the following versions of Splunk® Cloud Services: current