Merge error message - whaaaaa?

LegacyUser

joe martel said: This process has been in place since the cutover to FamilyTree form nFS. There have been refinements to the algorithm so that errors in performing the Merge are now much less common. 

There is no one root cause as it is an aggregation of many different database (db) fields and db relationships to other data that causes the software to tell you to switch. If it didn't the Merge would likely fail (like out-of-bounds, stack overflow) because it would exceed the capacity of db memory. (remember IOUS from nFS). So rather than fail it tells you what you need to do to accomplish the Merge.  It doesn't matter if it's a member, what sex,  locked PID, ... on which person is the survivor.

All software/hardware impose constraints - like with only 16 bits you can't represent 64k unique values. Also realize that this is built on a db that is more of a NoSQL design (Cassandra for you techies) and the objects defined have a journal from which the current object is constructed. It's like a change log. That journal may also come into play in which PID needs to be the survivor to move on.

No merge is allowed which would affect a locked PID, including their relationships.

You can't predict which PID should be the survivor, nor should the user need to. The software will tell you if it runs into that constraint. So if you want to do the Merge where a switch is required, switch it. Otherwise you can't do the Merge.

LegacyUser

Justin Masters said: Thank you for taking the time to explain Joe.

LegacyUser

Adrian Bruce said: Thanks Joe - no single root cause then, but umpteen possible capacity issues might cause it. In which case it sounds like FSFT can't be any more specific with the error message. Fair enough.

LegacyUser

Paul said: Brett

Firstly, I hope Joe's comments (below) will help in your accepting that, if you want to complete a merge, this might be the only way of doing it - i.e. switching the records so the surviving ID is not the one of your choice.

Secondly, as far as the general issue goes, when you say, "...the User/Patron SHOULD ALWAYS be the one to choose who is the "Surviving" individual/person", I assume you do consider the possible wishes of the user who created the "deleted" ID. I'm sure you do and are just wanting users to have more control than a piece of computer programming. But my thoughts when undertaking a merge are always that I would not want to upset another user by making their well-researched ID disappear in order to preserve the one I had created, say, earlier in the day. So, unless it is riddled with errors, I always try to keep the older ID on the left-hand side.

LegacyUser

Brett said: Paul

I do not have to, either, accept; or, care for, the/any "... software imposed requirement ...".

If the "System" does run into a "Constraint" (regarding the individuals/person, either, from "New.FamilySearch"; and/or, "Family Tree"); then, advise us what the "Constraint" IS; so that, we can address/fix the "Constraint"; before, we "Merge"/"Combine" the individuals/persons in the way we want for a particular individual/person is the "Surviving" individual/person - or, if necessary, raise a 'Support' Case.

It is not that I want to 'upset' another User/Patron; but, (1) an older recorded individual/person in "Family Tree" (formerly, "New.FamilySearch") should always be able to take precedence over a newer recorded individual/person in "Family Tree" (formerly, "New.FamilySearch"), no matter how well "Documented" and "Sources" the newer recorded individual/person is; and, (2) for Members of the Church, the "Surviving" individual/person MUST always be that of the official individual/person from Church Membership Records, rather that a formerly "Living" (or, "Deceased") "Duplicate" individual/person added by another User/Patron, no matter how well "Documented" or "Sourced" the "Duplicate" is.

I am sorry; but, in regard to the latter, I want the other Six (6) "Known" (as well as, any other) "Duplicates" of ME to be subordinate to that of the "Original" ME in "Family Tree", that was created by the "System", from MY Church Membership Records, that I had "Control" over while I was "Living". And, that should hold true for any new subsequent "Duplicates" of ME that are created in the future - the "Duplicates" should be subordinate.

Brett

ps: If those "Constraints" include problems/issues with other Family members, that need to addressed/fixed first before the "Merge"/"Combine" is effected, then so be it.

LegacyUser

Tom Huber said: Brett, you are not paying attention to what we've been told. It is a data issue -- " it is an aggregation of many different database (db) fields and db relationships to other data that causes the software to tell you to switch. If it didn't the Merge would likely fail (like out-of-bounds, stack overflow) because it would exceed the capacity of db memory."

There is not anything a user can do the fix a stack overflow issue. With the complexity of the data and where it comes from (we're talking about not only the Family Tree database, but also the Temple Ordinance database, the historical index database(s), the inter-relational links, and so on) and for any of us to actually be able to "fix" whatever is the problem would take far more than the average (and likely you and me -- even with 50+ years in the computer industry) user could handle.

I don't care what I have to do to merge two records together, as long as the merge takes place and no data is lost.

That you care is obvious. If FamilyTree does not meet your needs because you disagree with how it works, that is fine. You are more than welcome to design your own system.

Admittedly, some of the shortcuts developers have taken (such as grouping by event type in Family Tree records) was the easiest route, but it was shortsighted, given the nature of future requirements.

The best we can hope for in this situation (of allowing the user to have the final decision of which way to merge two records) is that at some future date, the root cause(s) may be identified and resolved. But in the meantime, we have what we have, whether it satisfies our sensitivities or not.

LegacyUser

Tom Huber said: As Adrian pointed out: "no single root cause then, but umpteen possible capacity issues might cause it. In which case it sounds like FSFT can't be any more specific with the error message."

LegacyUser

Adrian Bruce said: Brett - it's not just the users who can't fix it, there is no reason to assume that Support could fix it either. You cannot, as they say, get a quart into a pint pot. In this instance, it seems to me that no one knows that it's a pint pot until the pouring attempt takes place. Fortunately, in this instance the measurements take place before the overflow. I strongly suspect as well that what fits today might not fit tomorrow and vice versa.

As for retaining one particular PID for "you", firstly the rare incidence of this message suggests it is unlikely to be an issue. But if it does happen then Support might be able to fix it by removing data and relationships from the profile with that PID so that it fits in the pint pot. Somehow I doubt that this would be acceptable to you. Justifiably so.

No, all the stuff that I'm reading suggests that this error condition is triggered as a last resort, one which it would be grossly negligent to ignore. I've written code like it myself. You test for all the known errors and respond to the user to allow them to fix it. But you also have to cater for the unknown unknowns.

LegacyUser

iLoveMyLife02 said: I noticed that this message seemed to appear for very "lopsided" merges -- where one person was well-described and the other had only 3 or 4 very generic Vitals, no children, no parents, etc. Thanks for the explanation, joe, now I'll be able to get some sleep tonight! ;-)