sfcpc / housing-dashboard

4 stars 0 forks source link

How to handle projects linked together after they both get a uuid? #12

Closed sbuss closed 4 years ago

sbuss commented 4 years ago

As discussed here: https://github.com/sbuss/housing-dashboard/pull/8#discussion_r372051146

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?

sbuss commented 4 years ago

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.