As illustrated in the examples above, raw value's properties are matched against the input files line-byline. Lines are however not tested in the order they appear but are sorted using an implicit priority. In most of the case, this modified order does not affect the results, but it is good to keep it in mind. Here is a technical example of how it works

Example configuration file:
<text-file path="conf/">
<key-property delete-after-use="false" string-type="sqlpattern">k1</key-property>
<key-property delete-after-use="false" string-type="sqlpattern">k2</key-property>
<key-property delete-after-use="false" string-type="sqlpattern">k3</key-property>
With this data file:
When loading the configuration, the data file is read line by line.
Will be represented internally in a tree like that:

Where each node level is a column from the data file.

Then the second line:

A new path will be created.

Same for third line:
And then the fourth line:

Here is the catch; because the fourth line first column shares the same value as the first line first column, its path is shared with the first line. That way the common expression will only be checked once.

The optimized mode should be used in most cases as it offer more performance. The only cases when we would not use it is when received data may match several lines (using regex or sqlpattern expressions).

Now we receive a value with these properties:

Tree paths are followed step by step:

The first path matched so the new property n1 is created and assigned value A.

Then the second path:

It also matched. So the value of n1 is now D.

Then the third path:

Not matched.

Finally the fourth path:

It also matched. So the value of n1 is now C.

This example exposed a case when the line order in the data file will differ from the processing order using the optimized data processing mode.