Place update doing hierarchical churning?

Help
1

When adding a new alternative name for a USA State, Gramps spent an enormous amount of time deciding to accept the update. (It has been churning for more than ten minutes when I started this note and is still going.)

Is it touching & trying to update every Record that references this civil division? Every place below it in the Place hierarchy and all the Events using those Places as well as the state? This was my home state and that would involve hundreds of thousands of individual updates.

I don’t understand why it is working so hard.

1 Like
2

You’re right, the higher you are in the hierarchy of places when you make a modification, the longer it takes

1 Like
3

A regression?

1 Like
4

Apparently. And Paul did a patch 2 years ago that addressed the unnecessary churning… and not just in Place updating. It looks like the change never made it to public release.

Rather than pushing a live change to every table, it just makes the view as ‘dirty’ and deferred the refresh to view management. Which is REALLY helpful when you are tweaking all the enclosing civil division breadcrumbs. The current method forces a huge refresh wait at every change. The other would amalgamate them into one refresh at the end… or if you force the issue by changing active views.

However, beyond the regression, I don’t understand why an adding an alternative name needed a refresh AT ALL.

Part of the question traces back to a basic bewilderment about why sometimes an Alternative Name is shown in rather than the Primary Name.

It seems like the Alternative Name should only be displayed if a date range or language setting that would make the Alternative more appropriate to the current condition. (This doesn’t seem to be how it decides. I often find the top-listed Alternative Name displayed in preference to to the primary.)

Adding what I did never had the need to dirty the views. It was only useful for input matching.
{The addition was “Penna” as an abbreviation/abbr alternative name for Pennsylvania… which was the abbreviation before 2-letter abbreviations became the US postal standard in Oct1963. And, although it would be nice if Gramps had a Display mode which used abbreviated equivalents in the “Place format (auto place title)” display preferences, such a capability does not exist.}

1 Like
5

Oh, you are right… not a regression as this has been commited on master branch (enhancement), so for the new major release!

6

why sometimes an Alternative Name is shown in rather than the Primary Name.

Maybe inherited from the “first version” of the alternate “names”, where sometimes searching names was a challenge. I do not remember well the version of the release or branch, but there was also an ugly hack for displaying alternate locations (version1).

Alternative Names (version 2)

1003×479 20.9 KB

You may also still see some “ghost locations” via a second “Alternatives Names” tab on Place Editor! Just for keeping these historical data before a compete migration to the new model.

1 Like
7

That Version 1 pre-dates my adoption of Gramps. So my Place Tree shouldn’t have legacy contamination.

The Alternative displacing the Primary is most seen after using the Place Cleanup addon.

Although I am more likely to notice when Gramps starts showing a different language place name in stead of the my preferred/primary selection (or even the “en” language Alternative Name that matches the en_US.UTF-8 of my OS), occasionally a US Place starts showing the 1st alternative.

The only 2 ways discovered for fixing those is to:

  1. delete ALL the alternative names, or
  2. insert a new Alternative Name at the top of the list that is equivalent to the Primary
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.