If uuid is already populated, don't keep traversing.
TODO: Was this the right choice? Is this the correct way to handle this?
Can this situation ever happen (and how)? This is done to handle this
situation: a child record is present in a day's data file but its parent
isn't. So we give the child a new uuid. On the next day we get the parent,
but our schemaless file already has a uuid for the child. Now what?
The options are:
1. Continue using the previous day's uuid
2. Use the new parent's uuid
a. Optionally, add a 'old_uuid,<val>' entry in the schemaless file
From @ilakyapal:
1 seems like it makes sense to me -- if you think about uuids as being a project's identifier, then it seems to make sense that whatever uuid was assigned first to anything corresponding to a given project is probably what we should use throughout (regardless of if the first record is actually a child or a parent and when that linkage happens)
And my response:
what happens in the case where both records are present, but then only linked together after they both got assigned a UUID?
This got resolved in #14. Since we no longer put UUID in the main schemaless file, this problem kind of just went away. We always write out the UUID of the parent, even if that parent has changed.
As discussed here: https://github.com/sbuss/housing-dashboard/pull/8#discussion_r372051146
From @ilakyapal:
And my response: