Exploring 6.0.1 on Win10 and have been testing the filters.
Tried using the custom filters carried over from 5.2 and was seeing strange results so scrapped that custom_filter file and started from scratch.
After creating a new set of filters, I wanted to create one final filter that combined people from the 4 other filters. There are a lot of overlap between these filters.
I needed the sibling side filters because I know of 4 endline grandparents with a known sibling but still do not know the parents. I suppose I could add them as individuals to the family filter. But I like the concept of a universal filter. In 5.2 I run it off of the active person filter. Unfortunately, it is not working in 6.0. In 5.2 I can select an individual and filter for their complete family including all immediate in-laws and any step children.
By the way, Did you test it and are you seeing the same results?
Just imported the Example.gramps from the 6.0.1 files and ran the set of filters I sent you.
Using our matryed hero Lewis Anderson Garner von Anderson as the test, I entered his ID into filter āFilter 1a: Ancestors ofā¦ā.
āFilter 1a: Ancestors ofā¦ā returned 7 people
āFilter 1b: Siblings of Ancestorsā returned 18
āFilter 1c: Descendents ofā¦ā returned 93
āFilter 1d: Find the Spoucesā returned 46
Now running the filterā¦
āFamily 1A: The Family and their Spoucesā returned 0
Filter 1Aās code
<filter name="Family 1A: The Family and their Spouces" function="or">
<rule class="MatchesFilter" use_regex="False" use_case="False">
<arg value="Family 1a: Ancestors of..."/>
</rule>
<rule class="MatchesFilter" use_regex="False" use_case="False">
<arg value="Family 1b: Siblings of Ancestors"/>
</rule>
<rule class="MatchesFilter" use_regex="False" use_case="False">
<arg value="Family 1c: Descendents of..."/>
</rule>
<rule class="MatchesFilter" use_regex="False" use_case="False">
<arg value="Family 1d: Find the Spouces"/>
</rule>
</filter>
It seems that there might be an issue with the new Optimizer class in Gramps 6.0.
Not sure why but this workaround seems to help: add a line in the method apply_logical_op_to_all in the file gramps/gen/filters/_genericfilter.py (around line 149) as follows:
optimizer = Optimizer(self)
handles_in, handles_out = optimizer.get_handles()
if not handles_in: handles_in = None # add this line
I added the line to _genericfilter.py but am not seeing any change in the results on my database.
I had tried the same set of filters on the Example database using LAGvZ as the base person. Before the modified code, zero (0) people were returned. With the applied code, 137 people were returned. This 137 number appears to be correct.
Running the exact same set of filters on my 5.2.4 database returned 165,278 people.
Running it, with the altered _genericfilter.py, returned 114.
I see a potential issue. Can someone check to see what handles_in is before you set it to None. (Iām guessing it is an empty set). If so, we can fix this without this workaround.
<filter name="Family 1A: The Family and their Spouces" function="or">
<rule class="MatchesFilter" use_regex="False" use_case="False">
<arg value="Family 1a: Ancestors of..."/>
</rule>
<rule class="MatchesFilter" use_regex="False" use_case="False">
<arg value="Family 1b: Siblings of Ancestors"/>
</rule>
</filter>
As @DaveSch says, using the example tree, the partial results are:
āFilter 1a: Ancestors ofā¦ā returned 7 people
āFilter 1b: Siblings of Ancestorsā returned 18
For some reason the optimizer.get_handles method is applying an and condition handles_in = intersection([handles_in] + selected_handles)
handles_in is length 7, selected_handles is length 18 which looks correct. The intersection has length 0, rather than 25
@dsblank we have two sub-filters, each of which has the āandā condition. The combined filter then uses the āorā condition. Therefore, I donāt think that the code should even be applying an intersection at this point. It looks to be applying the condition from the sub-filter rather than the condition that should apply to the combined filter.
If I modify the two sub-filters to use the āorā condition, then the expected result of 25 people is returned.
@dsblank I wasnāt quite sure where you meant so this might be more detail than you need
In Optimizer.get_handles, self.all_selected_handles contains the results of the two sub-filters. These appear to be correct, having the expected length.
Each of the sub-filters contain only a single rule but have the logical operator āandā (which obviously has no meaning given there is only a single rule). The top level filter has the condition āorā
In the initial loop
for inverted, logical_op, selected_handles in self.all_selected_handles:
if logical_op == "and" and not inverted:
LOG.debug("optimizer positive match!")
if handles_in is None:
handles_in = intersection(selected_handles)
else:
handles_in = intersection([handles_in] + selected_handles)
In the first iteration logical_op is āandā and we set handles_in to intersection(selected_handles). handles_in` has length 7.
In the second iteration, logical_op is āandā again and we set handles_in to intersection([handles_in] + selected_handles). handles_in now has length 0 i.e. there is no intersection. Logically this is correct - you would not expect an intersection between a persons siblings and ancestors.
handles_out also has length 0 and the method returns two sets, each of length 0
execution return to GenericFilter.apply_logical_op_to_all where the following log entries are generated
2025-04-25 08:35:58.879: DEBUG: _genericfilter.py: line 150: Optimizer handles_in: 0
2025-04-25 08:36:19.234: DEBUG: _genericfilter.py: line 154: Optimizer handles_out: 0
Iām not sure that it is using the correct logical_op. It appears to be using the logical_op from the second sub-filter to determine how to combine the results of the first and second sub-filter. It seems that it should be using the logical_op of the parent filter (āorā) which would result in handles_in being None.
If I force handles_in = None after the first loop in Optimizer.get_handles then I get the expected result, with the log entries:
2025-04-25 08:46:27.479: DEBUG: _genericfilter.py: line 150: Optimizer handles_in: None
2025-04-25 08:46:28.044: DEBUG: _genericfilter.py: line 154: Optimizer handles_out: 0
After installing your changes (and remembering to revert back to the original _genericfilter.py), I am getting the expected number of returns. Tested it on the example database and LAGvZ had the expected 137 family members.
