forked from archiver_config/sf_databuffer
Fixes.
This commit is contained in:
@@ -129,7 +129,7 @@ Lets assume the channels 'SINDG01-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:
|
||||
- '\^SINDG.\*|\^SINOG.\*|\^SINUG.\*': '**SINDG01-RCIR-PUP10:SIG-AMPLT**' and '**SINOG01-RCIR-PUP10:SIG-AMPLT**'
|
||||
- '\^SINDG01.\*': '**SINDG01-RCIR-PUP10:SIG-AMPLT**' and 'SINOG01-RCIR-PUP10:SIG-AMPLT'
|
||||
|
||||
as the patterns matches the full channel names. Again, ties could be broken by considering the length of the pattern resulting in '\^SINDG.\*|\^SINOG.\*|\^SINUG.\*' matching both channels as it is longer. Certainly not what the user intended. One could try to overcome this problem by splitting *or* connections and use separate but equivalent data policies internally (i.e., in a separate data policy for '\^SINDG.\*', '\^SINOG.\*', and '\^SINUG.\*'). However, regex allows for expressions which are difficult to split (not to mention how to understand, e.g., '((\^|, )(part1|part2|part3))+$'). Therefore, keep to the general rules of pattern definition.
|
||||
as the patterns matches the full channel names. Again, ties could be broken by considering the length of the pattern resulting in '\^SINDG.\*|\^SINOG.\*|\^SINUG.\*' matching both channels as it is longer. Certainly not what the user intended. One could try to overcome this problem by splitting *or* connections and use separate but equivalent data policies internally (i.e., a separate data policy for '\^SINDG.\*', '\^SINOG.\*', and '\^SINUG.\*'). However, regex allows for expressions which are difficult to split (not to mention to understand, e.g., '((\^|, )(part1|part2|part3))+$'). Therefore, keep to the general rules of pattern definition mentioned above.
|
||||
|
||||
|
||||
## Example Policies
|
||||
|
||||
Reference in New Issue
Block a user