This commit is contained in:
Fabian Märki
2016-06-16 14:31:33 +02:00
parent ce64e9d6bf
commit 6ae0503b46

View File

@@ -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