moodymudskipper / bigbrothr Goto Github PK

https://cloud.google.com/sql/
https://www.freesqldatabase.com/
https://www.freemysqlhosting.net/

First, just have a dB. Ultimately having serverside validation and accounts would be nice, so the data would be seen only by package maintainer, a bit safer than public.

The db would be chosen by the package maintainer. It would be helpful for when the package is used by a limited amount of users and developpers would like instant feedback.

It might be easier to work from there in fact for a start, and maybe forever ? Each maintainer is responsible for their db and we can present a tutorial on how to to set one up.

A package might be developed by a few members of a team or employees of a company, and used by others.
In my case we have a shiny app, used by many people who know nothing about R.
It's useful to keep track of what's being used. Like having code coverage, but with a history of use for a code chunk rather than just a boolean flag covered/not covered.
It might or not be desirable for this history to be anonymous.

This overlaps with flow::flow_run().
With the latter we flag that we enter a logical path, here it is generalised, we could do any action when entering a logical path, including feeding a db.

The current proposed approach in this package is to add logging calls ourselves, but we could also brotherize a full package, either after loading it (editing the namespace) or even at installation time, so it's always brotherized when we use it (with maybe options we can set to turn it off). A problem is the overhead in tight loops, it's a problem with {flow} as well.

Is it reasonable to say that, a for loop that does so little that incrementing a count has significant overhead, is probably not well designed to begin with ? (should have been using low level vectorisation instead)

This should be solved by rstudio/rstudio#8532

Kevin added it to the next milestone, along with litlle less than 100 other issues.

Fingers crossed.