Open moodymudskipper opened 2 years ago
A related issue, is that among the pks that we add to the planes
table above there is NA
, because flights$tailnum
can be NA.
If we decide to accept the above (since it somehow "repairs" the dm), we might want to make an exception for NA
and remove those rows ?
I think we should define precise roundtrip conditions in dm_nest_tbl()
and dm_pack_tbl()
, and refer to those definitions from dm_wrap()
. It is okay to be terse in the help pages for the functions, we also want a longer-form article that shows how these functions are applied (based on flights, financial, and perhaps starwars or a real API response).
What is the scope of this issue ?
We see rows of NAs are created for primary keys that didn't exist in the original
planes
tableThe doc says
Should we mention that we can also gain rows if all referential constraints are not satisfied ?
Should we inform the user when wrapping that such thing might happen when unwrapping ?
We could also fail early as some constraints are violated and this might not be the kind of operations we want to do on a dm if it's not tight ?