Question

Photo of Eric Connor

0

best practice for saving/tracking Person

2

Hello -

We've created a set tables of our own for workflow/volunteer protection purposes and are confirming that we are using correct fields for saving/retrieving.

When saving Person records should we use:

1) PersonAlias.Id (same as Person.PrimaryAliasId)

or

2) PersonAlias.AliasPersonId (Person.Id)

We're curious if better to keep track of the Alias table record or to maintain the actual Alias Id for the person.  I (think) I see both being used in Rock core code and am wondering if any pitfalls with one direction or the other.

Or 3) should we be standardizing on the Guid because that is the easiest to get to via a workflow.  For example --> {{ Workflow.Requester_unformatted }}

Thanks for any thoughts around this -

Eric

  • Photo of David Turner

    5

    Not sure I completely follow what you are asking but here's some thoughts.  If you are creating your own model/table and want a foreign key relationship to a person, you should be using PersonAlias.Id ( you would never use PersonAlias.AliasPersonId ). This way you always have a valid way to get to selected person, even if the person is merged with another person. If you are wanting to store a reference to a person in a workflow attribute, that would be the PersonAlias.Guid. (Which is exactly what get's stored when using a Person type attribute).

    Understanding what happens to Person and PersonAlias records when two people are merged might help also.  Consider this example of two people that are added to database and then merged...

    Before Merge

    Person models

    Id = 1
    FirstName = David
    LastName = Turner

    Id = 2
    FirstName = Dave
    LastName = Turner

    PersonAlias models

    Id = 1
    PersonId = 1
    AliasPersonId = 1

    Id = 2
    PersonId = 2
    AliasPersonId = 2

    After Merge

    Person models

    Id = 1
    FirstName = David
    LastName = Turner

    PersonAlias models

    Id = 1
    PersonId = 1
    AliasPersonId = 1

    Id = 2
    PersonId = 1
    AliasPersonId = 2

    Notice that after the merge one of the person records has been deleted, and it's associated personalias record's PersonId points to the new record (but the AliasPersonId keeps a history of it's original person id)

    Does that help at all?

    • Scott Conger

      Scott Conger

      David, do you see an issue if our team decide to standardize on PersonAlias.Guid, instead of PersonAlias.Id? Two reasons: 1) Clearer to new developers, instead of saying with workflows use guid but with C# code use id. 2) A guid would never get mismatched. If a dev saves PersonAlias.Id but accidentally tries to retrieve directly from Person.Id, it might actually pull up a person. Most likely the wrong person but a person non-the-less. Meaning during testing, they might not notice a bug. If we save the guid as the foreign key, it will be immediately obvious, if they retrieve it incorrectly because that guid would never be associated with a person. It is 100% unique to that PersonAlias row. No person would ever have that guid. Meaning during testing, it would clearly fail.

      • David Leigh

        David Leigh

        Great answer David! This also helped me to get a better understanding of how the Person Alias process works, thanks.

      • Photo of Eric Connor

        0

        Thanks David - very helpful and saw the follow up with Scott.  Appreciate your time!