forked from archiver_config/sf_databuffer
escaping special character.
This commit is contained in:
36
Readme.md
36
Readme.md
@@ -81,7 +81,7 @@ The JSON structure is defined as follows:
|
||||
|
||||
## Overwriting Policies
|
||||
|
||||
It is possible to overwrite existing data policies. Assigning policies to data points is done using regular expressions applied to channel names (see: [Pattern](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html), more precisely using [Matcher.find()](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html#find--)) whereas a longer match sequence is considered superior to a shorter match sequence (i.e., matching channel name 'SINDG01-RCIR-PUP10:SIG-AMPLT' to the pattern '^SINDG' and '^SINDG01' results in match sequences '**SINDG**01-RCIR-PUP10:SIG-AMPLT' vs. '**SINDG01**-RCIR-PUP10:SIG-AMPLT' and thus pattern '^SINDG01' is considered superior). It is also possible define a data policy for a specific channel by using the channels exact name. In case several files define the same pattern, the one defined in the first file (given by the natural ordering of the file system) will be used.
|
||||
It is possible to overwrite existing data policies. Assigning policies to data points is done using regular expressions applied to channel names (see: [Pattern](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html), more precisely using [Matcher.find()](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Matcher.html#find--)) whereas a longer match sequence is considered superior to a shorter match sequence (i.e., matching channel name 'SINDG01-RCIR-PUP10:SIG-AMPLT' to the pattern '\^SINDG' and '\^SINDG01' results in match sequences '**SINDG**01-RCIR-PUP10:SIG-AMPLT' vs. '**SINDG01**-RCIR-PUP10:SIG-AMPLT' and thus pattern '\^SINDG01' is considered superior). It is also possible define a data policy for a specific channel by using the channels exact name. In case several files define the same pattern, the one defined in the first file (given by the natural ordering of the file system) will be used.
|
||||
|
||||
#### General Rules (Words of Care)
|
||||
|
||||
@@ -89,47 +89,47 @@ Using regular expressions to assign data policies to data points should assist u
|
||||
|
||||
- Do not use wildcards '.*' at the beginning or end of a pattern as this would always result in match sequences covering the complete channel name, making overwrites impossible (Example 3 and 4 explain why).
|
||||
- Use *or* combinations with care.
|
||||
- Do not use complex regular expressions (things difficult to understand like '((^|, )(part1|part2|part3))+$'.
|
||||
- Do not use complex regular expressions (things difficult to understand like '((\^|, )(part1|part2|part3))+$'.
|
||||
|
||||
|
||||
### Example Overwrites
|
||||
|
||||
#### Example 1 (Dos)
|
||||
|
||||
Lets assume the channel 'SINDG01-RCIR-PUP10:SIG-AMPLT' is applied to pattern '^SINDG' and '^SINDG01'. This results in the match sequences:
|
||||
Lets assume the channel 'SINDG01-RCIR-PUP10:SIG-AMPLT' is applied to pattern '\^SINDG' and '\^SINDG01'. This results in the match sequences:
|
||||
|
||||
- '^SINDG': '**SINDG**01-RCIR-PUP10:SIG-AMPLT'
|
||||
- '^SINDG01': '**SINDG01**-RCIR-PUP10:SIG-AMPLT'
|
||||
- '\^SINDG': '**SINDG**01-RCIR-PUP10:SIG-AMPLT'
|
||||
- '\^SINDG01': '**SINDG01**-RCIR-PUP10:SIG-AMPLT'
|
||||
|
||||
and thus the data policy of '^SINDG01' will be applied to the channel.
|
||||
and thus the data policy of '\^SINDG01' will be applied to the channel.
|
||||
|
||||
#### Example 2 (Dos with care)
|
||||
|
||||
Lets assume a user is responsible for channels starting with 'SINDG' or 'SINOG' or 'SINUG'. This user defines a base data policy for all these channels by using the pattern '^SINDG|^SINOG|^SINUG'. Lets further assume this user wants to temporary overwrite the data policies for all channels starting with 'SINDG01' (e.g. because the machine shows unexpected behavior and channels starting with 'SINDG01' help to identify the problem). This is possible by defining a new data policy with the pattern '^SINDG01'. Lets apply channels 'SINDG01-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:SIG-AMPLT' to these patterns:
|
||||
Lets assume a user is responsible for channels starting with 'SINDG' or 'SINOG' or 'SINUG'. This user defines a base data policy for all these channels by using the pattern '\^SINDG|\^SINOG|\^SINUG'. Lets further assume this user wants to temporary overwrite the data policies for all channels starting with 'SINDG01' (e.g. because the machine shows unexpected behavior and channels starting with 'SINDG01' help to identify the problem). This is possible by defining a new data policy with the pattern '\^SINDG01'. Lets apply channels 'SINDG01-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:SIG-AMPLT' to these patterns:
|
||||
|
||||
- '^SINDG|^SINOG|^SINUG': '**SINDG**01-RCIR-PUP10:SIG-AMPLT' and '**SINOG**01-RCIR-PUP10:SIG-AMPLT'
|
||||
- '^SINDG01': '**SINDG01**-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:SIG-AMPLT'
|
||||
- '\^SINDG|\^SINOG|\^SINUG': '**SINDG**01-RCIR-PUP10:SIG-AMPLT' and '**SINOG**01-RCIR-PUP10:SIG-AMPLT'
|
||||
- '\^SINDG01': '**SINDG01**-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:SIG-AMPLT'
|
||||
|
||||
and thus the data policy of '^SINDG01' will be applied to 'SINDG01-RCIR-PUP10:SIG-AMPLT' and the policy of '^SINDG|^SINOG|^SINUG' to 'SINOG01-RCIR-PUP10:SIG-AMPLT'.
|
||||
and thus the data policy of '\^SINDG01' will be applied to 'SINDG01-RCIR-PUP10:SIG-AMPLT' and the policy of '\^SINDG|\^SINOG|\^SINUG' to 'SINOG01-RCIR-PUP10:SIG-AMPLT'.
|
||||
|
||||
|
||||
#### Example 3 (Don'ts)
|
||||
|
||||
Lets assume the channel 'SINDG01-RCIR-PUP10:SIG-AMPLT' would be applied to pattern '^SINDG.*' and '^SINDG01.*'. This would result in the match sequences:
|
||||
Lets assume the channel 'SINDG01-RCIR-PUP10:SIG-AMPLT' would be applied to pattern '\^SINDG.*' and '\^SINDG01.*'. This would result in the match sequences:
|
||||
|
||||
- '^SINDG.*': '**SINDG01-RCIR-PUP10:SIG-AMPLT**'
|
||||
- '^SINDG01.*': '**SINDG01-RCIR-PUP10:SIG-AMPLT**'
|
||||
- '\^SINDG.*': '**SINDG01-RCIR-PUP10:SIG-AMPLT**'
|
||||
- '\^SINDG01.*': '**SINDG01-RCIR-PUP10:SIG-AMPLT**'
|
||||
|
||||
as the pattern matches the full channel name. In this case, ties could be broken by considering the length of the pattern where longer patterns are considered superior to shorter patterns (giving precedence to '^SINDG01.*'). Example 4 shows why this does not work in all cases.
|
||||
as the pattern matches the full channel name. In this case, ties could be broken by considering the length of the pattern where longer patterns are considered superior to shorter patterns (giving precedence to '\^SINDG01.*'). Example 4 shows why this does not work in all cases.
|
||||
|
||||
#### Example 4 (Don'ts)
|
||||
|
||||
Lets assume the channels 'SINDG01-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:SIG-AMPLT' would be applied to patterns '^SINDG.*|^SINOG.*|^SINUG.*' and 'SINDG01.*'. This would result in the match sequences:
|
||||
Lets assume the channels 'SINDG01-RCIR-PUP10:SIG-AMPLT' and 'SINOG01-RCIR-PUP10:SIG-AMPLT' would be applied to patterns '\^SINDG.*|\^SINOG.*|\^SINUG.*' and 'SINDG01.*'. This would result in the match sequences:
|
||||
|
||||
- '^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'
|
||||
- '\^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* combinations 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* combinations 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.
|
||||
|
||||
|
||||
## Example Policies
|
||||
|
||||
Reference in New Issue
Block a user