Post by Uncle Buddy on Jan 13, 2021 18:05:28 GMT -8
Treebard has a unique entity called "role". A role is a two-part entity. It has a role type such as "witness" or "bridesmaid" and the person who performs that role. The role is attached to an event such as a wedding or a funeral.
For example, John Smith and Mary Jones get married. In that event, the bride and groom are equal participants in the event, so partnership events like marriage, betrothal, divorce, annulment, separation, business partnership, wedding, etc. get special treatment. You don't want the user to enter the event twice, so code has been written to link one event to two people and enable accurate and complete querying of the stored data.
But what do you do with the flower girls? Or the ninongs and ninangs? I live in the Philippines where my fiancee worked at City Hall for a long time, so when we got married she got fifty local bigwigs to be our "wedding sponsors" or godparents for the wedding event. How would those people be recorded in a database if someone wanted to? Roles. Mrs. Salvacion is input as a ninang and Mr. Salvacion is input as a ninong. Roles go into the same people table as family members, because somewhere down the road, it might be found that the "boarder" Anton Czechworth who was born in Greece and lived with John and Mary Smith in Poughkeepsie in 1880 was actually Mary's favorite nephew. Since Treebard keeps role people in the same table as family members, it will be no problem to elevate Anton's status to nephew. And they'll be easy to find, unlike adjunct people recorded only in notes.
Treebard feels that neighbors, friends, foster mothers, arresting officers, witnesses, etc. can play an essential role in a person's life. For those genealogists who want to tell a story, who want to put flesh on the bones of their ancestors instead of just collecting a bunch of boring dates, names and places, roles are an important addition to the menagerie of genieware entities.
I've been working on the roles dialog for a long time. The current incarnation of that gizmo has existed since at least October of 2020. I took a month off coding for the Christmas season and when I got back to the roles dialog, it had magically turned to spaghetti code on me while I was looking the other way. The nature of spaghetti code is to take on a life of its own while you're feverishly making it worse and worse, solving problems every which way, fixing stuff on a per-error basis. Then when you're almost finished, suddenly the code is completely unmanagable. You can't believe you wrote it yourself, it looks like a trained chimpanzee did it wearing a blindfold. Fixing one thing breaks two other things. Every problem takes three days to solve.
Spaghetti code cannot be fixed. It's not a first draft, it's a practice run, a random stab in the dark. The only real solution is to start over. That's what I'm doing, for the nth time, with the roles dialog. I'm encouraged by the swift and smooth progress since I know what I do and don't want by now, after several inital stabs at it. And best of all, I took the time (since I now know what's involved) to create a flow chart of all the tendrils so the tendrils don't get tangled this time. It's coming along nicely.
In general the past couple years have been about finishing the events table on the main (current person) tab. At this point it's a bit like pulling teeth but a lot more fun. It looks good and works well but each column (event type, date, place, particulars, age,kin, roles, notes, and sources) has to be tackled one at a time, now that I know how everything is supposed to look, to get that data in and out of the database. In a way that is easy and useful for the user. Since each column contains very different data, each one requires a custom procedure to make data storage work right. For example, the place column is an autofill entry which I already know how to do, but quite some time ago I realized that in order to store nested places accurately, a place had to be able to have more than one parent place. Cities don't get up and move much, but their containing township and county names and boundary lines used to change all the time. I decided to leave this column till last when I was researching how to write a many-to-many recursive query. I didn't give up. Not forever.
Speaking of places, can someone tell me what zip codes are doing in genealogy databases??? I'm just a young whippersnapper of 64 and 3/4, but even I'm older than zip codes. Please don't tell me that my great-grandma lived at 13676, because she did not. She lived in Potsdam, thank you very much.
For example, John Smith and Mary Jones get married. In that event, the bride and groom are equal participants in the event, so partnership events like marriage, betrothal, divorce, annulment, separation, business partnership, wedding, etc. get special treatment. You don't want the user to enter the event twice, so code has been written to link one event to two people and enable accurate and complete querying of the stored data.
But what do you do with the flower girls? Or the ninongs and ninangs? I live in the Philippines where my fiancee worked at City Hall for a long time, so when we got married she got fifty local bigwigs to be our "wedding sponsors" or godparents for the wedding event. How would those people be recorded in a database if someone wanted to? Roles. Mrs. Salvacion is input as a ninang and Mr. Salvacion is input as a ninong. Roles go into the same people table as family members, because somewhere down the road, it might be found that the "boarder" Anton Czechworth who was born in Greece and lived with John and Mary Smith in Poughkeepsie in 1880 was actually Mary's favorite nephew. Since Treebard keeps role people in the same table as family members, it will be no problem to elevate Anton's status to nephew. And they'll be easy to find, unlike adjunct people recorded only in notes.
Treebard feels that neighbors, friends, foster mothers, arresting officers, witnesses, etc. can play an essential role in a person's life. For those genealogists who want to tell a story, who want to put flesh on the bones of their ancestors instead of just collecting a bunch of boring dates, names and places, roles are an important addition to the menagerie of genieware entities.
I've been working on the roles dialog for a long time. The current incarnation of that gizmo has existed since at least October of 2020. I took a month off coding for the Christmas season and when I got back to the roles dialog, it had magically turned to spaghetti code on me while I was looking the other way. The nature of spaghetti code is to take on a life of its own while you're feverishly making it worse and worse, solving problems every which way, fixing stuff on a per-error basis. Then when you're almost finished, suddenly the code is completely unmanagable. You can't believe you wrote it yourself, it looks like a trained chimpanzee did it wearing a blindfold. Fixing one thing breaks two other things. Every problem takes three days to solve.
Spaghetti code cannot be fixed. It's not a first draft, it's a practice run, a random stab in the dark. The only real solution is to start over. That's what I'm doing, for the nth time, with the roles dialog. I'm encouraged by the swift and smooth progress since I know what I do and don't want by now, after several inital stabs at it. And best of all, I took the time (since I now know what's involved) to create a flow chart of all the tendrils so the tendrils don't get tangled this time. It's coming along nicely.
In general the past couple years have been about finishing the events table on the main (current person) tab. At this point it's a bit like pulling teeth but a lot more fun. It looks good and works well but each column (event type, date, place, particulars, age,kin, roles, notes, and sources) has to be tackled one at a time, now that I know how everything is supposed to look, to get that data in and out of the database. In a way that is easy and useful for the user. Since each column contains very different data, each one requires a custom procedure to make data storage work right. For example, the place column is an autofill entry which I already know how to do, but quite some time ago I realized that in order to store nested places accurately, a place had to be able to have more than one parent place. Cities don't get up and move much, but their containing township and county names and boundary lines used to change all the time. I decided to leave this column till last when I was researching how to write a many-to-many recursive query. I didn't give up. Not forever.
Speaking of places, can someone tell me what zip codes are doing in genealogy databases??? I'm just a young whippersnapper of 64 and 3/4, but even I'm older than zip codes. Please don't tell me that my great-grandma lived at 13676, because she did not. She lived in Potsdam, thank you very much.
