The upcoming nm_join_bayes() function in bbr.bayes, which uses nm_join() underneath, needs to know which columns in the result came from the data file and which came from tables. bbr.bayes can repeat some of the same logic to figure that out (and already has a compatibility fallback), but it'd be more reliable and future-proof if nm_join() provided that information.
Update nm_join() to track the origin of each column and store that map as an attribute of the return value.
Instead of using an attribute, we could avoid exposing this information to other callers by adding an internal layer to nm_join() for bbr.bayes to use. However, an attribute is fairly tucked away, it seems likely that some other caller may find this information useful, and it's not much for nm_join() to commit to compatibility-wise.
The upcoming nm_join_bayes() function in bbr.bayes, which uses nm_join() underneath, needs to know which columns in the result came from the data file and which came from tables. bbr.bayes can repeat some of the same logic to figure that out (and already has a compatibility fallback), but it'd be more reliable and future-proof if nm_join() provided that information.
Update nm_join() to track the origin of each column and store that map as an attribute of the return value.
Instead of using an attribute, we could avoid exposing this information to other callers by adding an internal layer to nm_join() for bbr.bayes to use. However, an attribute is fairly tucked away, it seems likely that some other caller may find this information useful, and it's not much for nm_join() to commit to compatibility-wise.
Re: https://github.com/metrumresearchgroup/bbr.bayes/pull/106