Eclipse SE offers an easy shorthand to call the results of a previously-executed search, by referencing the search result ID within brackets. This allows users to run several different searches, evaluate the results, and even compare results from multiple previous searches using Boolean logic. If a user saves the results of a search comparing two separate search history items, care needs to be taken to ensure that the saved search is evaluated in the proper order of operations. This can be best illustrated via an example.

For this example, we will use two abstracted search strings:
Search [1] = "A AND B"
Search [2] = "C AND D"

When run distinctly, these searches will return docs that match Condition A as well as Condition B for search 1, and Condition C as well as Condition D for search 2. When both searches are in our recent history, we can create a new search comparing or combining the results sets of both searches, for example "[1] OR [2]." Each history ID is evaluated distinctly, and the results are then compared. In this example, the search represented by [1] is evaluated in its entirety, then [2] is evaluated, and then the results set of each are compared to one another via an OR. This is essentially evaluated as "(A AND B) OR (C AND D)"

When saving a query that references search history, the search result ID is replaced with the conditions that were used to generate those results in the first place. Therefore "[1]" would be replaced by "A AND B," and "[2]" would be replaced by "C AND D." Because of this, the order of search is represented differently, without the same logical order of operations: "A AND B OR C AND D."

These two searches may return different document sets because of the difference in how the Boolean logic is evaluated, and totals may not match compared to when the search was created. This may impact productions especially, or any other workflow based on searches. Fortunately, there is an easy way to resolve this situation: bound each search ID in parens, OR bound each part of the search with parens when first creating it. Examples are below:

Parens at ORIGINAL search part creation:
Search [1] = "(A AND B)"
Search [2] = "(C AND D)"

Parens when saving combined search:
Combined string = "([1]) OR ([2])"

Using either method will force parens around each constituent when saved into the new search, thus forcing those portions to be evaluated separately before the logical OR operation compares the distinct result sets.