There is a filter called “Probably Alive” that allows filtering and exporting of just those people that were alive on a given date.
Do you use that feature?
This filter is one that can take a long time (25 seconds on a tree of 100k people). So, we are looking to see if it is worth making changes to make it faster (reduce time to less than a second).
Don’t do “Probably” so my vote is for Not Required
phil
Personally, No!
I look at individual records and have no need to consider… This filtered list of people were probably alive…
Never used it either.
Could really use a Family filter that finds family records that do or do not have children attached. It would be nice to be able to select on how many children. E.g. >1 or <3
Making a list, and checking it twice. Added to wish list. (It occurs to me we could expose the proposed enhancements for next Gramps so you could do your own filters like that. Do you think “len(family.child_ref_list) == 1” would be too hard for user to understand and write?)
I really like the power of the various filters I use, however where I struggle is with the syntax having no great python experience
would these be documented anywhere. Just thought about this now when the message came up.
phil
The help file would need lots of examples.
Yes, I often use it on my database of 20000 people
There’s already another (stagnant) rule request list thread. Unfortunately, you could could get buried in infinite rule request work. There’s another request that asks for a tutorial on creating Rules. But that might be sidestepped with the SQL supprt … since there are so many tutorial in existence on building those queries. (Although something intoductory about the Gramps database model might help.)
However, @Davesellers has a point about the existing filter rules being a bit thin in the Families category. Both in finding families that match criteria and in finding secondary objects of specific families.
Merging interactively could be greatly steamlined if there was an (efficient!) winnower of objects related to a family.
Say that there was a rule to find the Families (both as a child and parent) of the Active Person.
Then a matched set of Family Rules for each object type:
<object type> under [family] (where [family] could be a list of IDs)<object type> under <family filter] (which be an Active Family filter)And where these rules had options to include:
Essentially, the (full drill-down including Family and Personal secondary objects) Rules would work with the same subset of objects that are already exported for a selected person. So the winnowing functionality already exists elsewhere.
So… with the families of active Person filtered in the Families, you could walk through selecting the merging all the duplicate families within 1 degree of separation. Then step through each category, merging the duplicate people of the active family, then all the duplicate Events, Places, Repositories, Sources, Citations, Media, Notes.
Doing this step through Person-by-Person would be massively more cycles (and error prone) than Family-by-Family.
I don’t, but I understand that it is useful for people who generate static web sites.
The GitHub user CameronD73 made quite a few enhancements to it in the last release.
A complication about an ever expanding set of custom filters is discovering whether the Filter already exists.
This may be one of the situations where an AI librarian (overseeing a catalog of queries) could become necessary.
I’ve always wondered what methods programmers, data scientists and mathematicians use for keeping their code snippets, queries, and formulae “findable”.
Thanks for the list of filter requests. That will be useful.
[There are over 50 in that list, and there are already 250 in Gramps. One problem is that these have to be added in a new version as they would be enhancements. If a user can construct their own dynamically, then that would solve three issues: 1) You need a filter, 2) someone has to write it, and 3) it won’t be available until next version.]
[I think you are describing a new way of using/handling filters. If important, please make a ticket and explain as best you can what you are describing. But this thread is a survey on Probably Alive].
I’m not a programmer and not the best at putting together query strings. However, before I retired, I had an application (can’t remember the name) that allowed me to build SQL queries just by dragging and dropping items onto a query edit page. Once you connected to the DB you could see the tables and elements and then form the query you wanted and then build the report you wanted.
That is the kind of enhancement that would get rid of many of the 250 queries and allow users to create their own. It would take some work. Is there something like that already in the public domain?
ps. It built the complex sql in the background which you could also see if needed.
You are probably thinking about something like Crystal Reports, but we are taking this thread off-topic again.
Perhaps command-completion will be a good start? It certainly helps me remember what is available. [@DavidMStraub Another need for type hints on primary objects and their attributes.]
I had to mull over why this might be anything new to the use or handling of filters.
My original thought was just additional rules that would be more viable with multi-stage filters with the increased efficiency. (If the view re-filtering is applied between every merge, then a filter that takes 45 seconds to run is not viable if there with be 80 separate merge operations. It would add an hour of overhead. But if the filters only took 1/10 as long, then it only adds 6 minutes. That’s tolerable.)
But are you thinking that a whole new level of efficiency being achieved by only applying the filter to the changed records? So the deleted record(s) would be removed from the view and only the surviving record(s) needs to be retested against the filter criteria. So the “partial” view filter refresh might change to a fraction of a second?
I hadn’t even considered that possibility! I was still thinking of the brute force approach simply being faster.
The original survey question was to help prioritize work on the Probably Alive filter. However, in looking at it further, I don’t think it can be sped-up much.
However, in working with a 100k person test tree, my recommendation is the following flow:
Using the tag is much faster (reduced from 25 seconds down to about 3 seconds in Gramps 6.0).
NOTE: if you edit people that could change the estimates of whether someone is alive or not, you’ll have to repeat the above.
Could I ask why there is all this discussion about a totally flawed
concept, if this is intended for use when you wish to publish a tree
then the concept should be Provably Deceased.
My Rules for this are
I think “probably alive” would be better named “possibly alive”, if its purpose (e.g. when exporting) is to conservatively treat people as still living (for privacy reasons) if they are not provably deceased. A person born 100 years ago is possibly alive, but probably not alive.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.