You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
Next time a major revision of the MotusRBook is done, it would be great to see at least some cases where the same table name or data.frame is used for a filtered or mutated table removed. I think for most users with big projects this creates problems. Most of us are probably following the examples in the book pretty closely to construct our workflows, especially as major changes happen to motus package code. With this kind of table name re-use, it is easy to end up with very hard to track problems. The alternative (that you have used in several later chapters) is to not re-use the tables and data.frames and to just run code that goes out to the database again. For big projects, this can require a very long wait for a result. It would seem better to use different table names and then, in later examples, use those tables that are already in memory. I realize that some are jumping into the book in the middle, but I think that problem can be solved with a backward reference to the section where the selected/filtered/mutated table was created.
The text was updated successfully, but these errors were encountered:
Next time a major revision of the MotusRBook is done, it would be great to see at least some cases where the same table name or data.frame is used for a filtered or mutated table removed. I think for most users with big projects this creates problems. Most of us are probably following the examples in the book pretty closely to construct our workflows, especially as major changes happen to motus package code. With this kind of table name re-use, it is easy to end up with very hard to track problems. The alternative (that you have used in several later chapters) is to not re-use the tables and data.frames and to just run code that goes out to the database again. For big projects, this can require a very long wait for a result. It would seem better to use different table names and then, in later examples, use those tables that are already in memory. I realize that some are jumping into the book in the middle, but I think that problem can be solved with a backward reference to the section where the selected/filtered/mutated table was created.
The text was updated successfully, but these errors were encountered: