Hi - It would be great to have membership in groups updated when a new person is added or edited that meets or no longer meets the criteria for groups. It appears membership is automatically updated for groups when Saved criteria is used as the Type and is changed. But if you add a new person to the database that meets one or more group’s criteria, it isn’t added to the group. It’s the same situation if you edit an existing person so that they fall within or outside the criteria for one or more groups.
It make sense not to automatically add or remove people from group memberships if the criteria Type is Free-Form as this is manually selecting people.
PS (I didn’t readily see a dedicated area for enhancement requests so I am posting to this forum. Let me know if there’s a better place to post a suggestion for RM product features. )
It would be great, however this is a request that goes back several versions and has yet to be implemented. There have been other automatic update things requested, such as relationships. I believe the reasoning is that such background updating would slow Rootsmagic down.
As much as I have wanted some of RM’s tools to be more dynamic for decades, I’m not supportive of a truly automated updating of groups when new individuals are added or edited. I think doing so would slow RM to a crawl. I’m content with the “refresh” icon on People List View when People List View is filtered by group.
The only thing I would like added there is that the “refresh” icon on People List View doesn’t show the number of people in the group. If I do a refresh from the actual Groups screen, the refresh does show the number of people in the group. So sometimes I do the refresh the hard way by going into the Groups screen, just so I can see the number of people in the group change when I do the refresh.
Not likely unless RM is really poorly written. That has, however, been their excuse for some time now. There are many programs out their that dynamically update lists and displays and such. Rootsmagic has competitors that do automatically update certain things based on actions taken. Of course that program appears to be written in a decent language, and no, I don’t consider Delphi a decent language.
Of course this also assumes that you are using a computer that was put together sometime in the last 10 of 15 years. Sure, RM has used the excuse that they are being conscientious of people with older hardware. If people are using hardware THAT old, they probably need to stop using computers and content themselves with piddling apps on their mobile phone.
Is RM9 a cpu hog on Windows? On Mac it idles at 12-15% M2 chip 24GB which I have blamed on Intel only code requiring Rosetta translation. All other programs use less than 1% including FTM. If this really reflects poor coding the less capable X86 chips must really struggle.
I agree with @kfunk. While poorly written code on a lousy development platform could cause that bad result, if the code dynamically writes and executes the applicable sql queries for each group, the well-coded sqlite engine would speedily complete each update.
That said, if there are dozens of criteria groups, there would be some cumulative delay and I would want manual refresh to remain with the added option of opting in or out of auto-refresh.
This would seem the ideal solution – and probably set by each group – which dynamically update and which do not. (which then could be manually updated at anytime).
Maintaining the manual refresh is probably a sensible thing. I do believe we have pretty much determinned RM is a single threaded application. Any delay could be mitigated by changing this rather outdated behavior and actually making use of the multitude of cores and threads available to any modern processor. However, I can’t picture anything really causing a large cumulative delay, at least not short of importing very large datasets into your database. Even if one did this, you are looking at a delay of less than 30 seconds, if that. Since most people do not import huge files, they likely wouldn’t notice much delay. Those that do such stuff would simply need to get used to a slight delay.
There are definitely multiple threads. But I suspect that they are used primarily for WebHints and things of that sort that can and should run asynchronously from user activity. But I suspect that RM’s processing in response to user activity is pretty much synchronous and single threaded.
Even with the new RM9 improvements in performing Advanced Searches and and creating and updating groups, updating a single group can require several seconds on my machine, depending on the complexity of the search or group criteria. So suppose it takes 5 seconds for 1 group and suppose I have 10 groups that each take the 5 seconds. Without multithreading, that’s 50 seconds. Every Edit Person could trigger the refresh for every group. Multithreading can help, but it’s not a total solution. Or suppose it’s really much faster, such as 1 second per group and I have 30 groups. That’s 30 seconds without multithreading. And so it goes.
A great deal depends on the size of your database and the power of your computer. Some users have tens of thousands or hundreds of thousands of people in their databases. Some criteria can be very complicated, for example requiring RM to look at all citations for all facts for all persons in the database. So no, I can’t see it really being fast enough in the general case.
Not sure where those numbers came from but I am not seeing them as very realistic, especially if this is being done in a background thread. I don’t see that any queries actually have to be ran. If you have a saved query for a group, then you have some parameters, such as birth before 1900 and birthplace is Tennessee. These parameters are stored somewhere, so instead of running an queries, the system can walk through each group query and drop it if the new information fails. For example, Tom Smith was born in 1910. Boom! End of working that group. Move to the next one.
I think of this as a big IF/THEN block. If any of the tests fail, then drop out and move on. For someone entering a person one at a time, this will be pretty fast. Yes, it will be much slower if someone drags a thousand people from one file to their working file, but that is a price those people pay for doing as they are, and I suspect this use case happens maybe 10% of the time.
Here’s a video that’s 0:56 in length to illustrate the time concern. It’s a very simple group with only six members at the present time. I didn’t formally time it, but it seems like the refresh is in the range of 5 to 6 seconds. My database has about 40,000 people. RM 9.1.3.0, Windows 10, 16GB memory, fast SSD disk.
That video isn’t relevant to the discussion. You are refreshing a group which means it has to run your query against 40K people to see if any new people meet the full set of criteria and update them if they do.
Auto-refresh means you are running one person against one set of criteria in this case. You are not querying against any other persons when you add a new person to your database. Using your example, you check to see if the newly added person has color coding set to Red. If they don’t have color coding then your out, if they do then check to see if it is the chosen color set, if not, you are out. If they do then you move on and check to see if they have any sources, if not, your out, else you check the sources for the $. If they meet all the above, then you update the DB with their new group. you will have several very small and specific queries that will take literally micro-seconds to complete.
If you import 10K more people, then this will indeed take a little more time and definitely should be shuffled off to its own thread.
So you are trying to compare apples to oranges here.
I was making the assumption that a full refresh of all the groups would take place.
Your assumption is that the newly added or edited person would be tested against each of the existing criteria groups.and would either be added or removed or continue not to be a member or continue to be a member. The performance could clearly be completely acceptable with your approach. It’s just like when you delete a person, the person has to be deleted from any groups of which they are a member. That performance clearly is already quite acceptable.
No, it’s not. When a person is deleted, nothing needs to be changed in the table of who is included in each group. The RIN no longer exists so, even if it is still a member of the group, nothing is outputted for it. There is no group process when a person is deleted.
One more issue for the mill-
It is my impression that the RM schema has too few indexes.
Search times increase very slowly when checking against an index so if properly indexed, a database search shouldn’t slow down much with more records.
I ran a little experiment using SQLite to compare selecting all the people who meet a criteria set such as Jerry’s versus whether a given person did on a database of 190k people and 360k citations and citation links. There were 42 meeting the criteria for the whole group and that took somewhere between 300ms and 1.4s. The test on the given person took ~0.5ms or no more than 1/60th of the time to select the whole group. Of course, that test does not include any time taken in updating the Group table.
The duration of the single-person test is very small and probably should be for many criteria. What we do not know is whether RM does group eligibility testing solely or largely in SQLite or whether it simply retrieves data for such processing in the application program language which may be less efficient. There are things that act slower than desired in RM9 - is it merely the delay of display processing or inefficient data processing?
Thanks to everyone who added comments and ideas. Providing a choice of dynamic or manual refresh at an individual group level makes sense to me as well.
Another idea to consider:
Only trigger the relationship-based membership rules if a new person is added or a fact that affects relationships is modified. So if an individual had a death date added, it wouldn’t trigger checking dynamic relationship rules. However, if a marriage fact were added to the same person, the dynamic relationship rule would be checked.
@rzamor1 - Has this feature already been requested in the past and a decision made not to add it? Thanks for any info you can provide.
The death date wouldn’t effect relationships, but it certainly could affect a criterion group if one of the criteria involved the person’s death date, like “people who died before 1940” or something like that.
