Doing a timing on my research tree of 50,313 people, 18700 families; the subset script ran in 27 seconds and generated 599 segments.
But it was a real pain to use the results. Because SuperTool resets each time the focus changes Category, I could look at how one segment was connected in the Graphs or Relationships. Then when switching back to People, the results had been cleared gone and the script had to be re-run.
I have to find a way to make the 599 rows into a worklist. I can download a CSV of the list. But the Edit Person links are lost. So looking them up again is⌠tedious.
If there was a way to add an selectable Attribute (or calculated) column to views, then users could leverage that column to organize and manage a worklist.
That script of could easily add the Count to a âSegmentâ custom attribute. If the Configurable column could be equal any named Attribute (or other 2ndry object value), then suddenly we have a lot of flexibility.
The script can now add an attribute to each person indicating the subset it belongs to. Additionally there are options to connect people through events, citations and associations.
You note in the README.md that setting the attributes can be quite slow.
Would temporarily disabling signals while setting attributes speed up the processing?
Stopping and starting signals
Signals can be blocked on a per instance basis or they can be blocked for all instances of the GrampsDBCallback class. disable_signals() can be used to block the signals for a single instance and disable_all_signals() can be used to block signals for the class:
Thanks, good idea. However, this had only a small effect.
The real reason for the slowness was that I had my âFulltext searchâ addon active for this database. That catches all database writes and updates its search index accordingly - which is a bit slow. I disabled the fulltext addon and now the whole operation takes only a few seconds (for the sample database).
I think I still leave the disable_signals call in the code.