[R-SIG-Finance] RFC: quantmod::getSymbols.MySQL

Joshua Ulrich josh.m.ulrich at gmail.com
Tue Apr 28 15:51:11 CEST 2015

On Tue, Apr 28, 2015 at 8:25 AM, Mark Knecht <markknecht at gmail.com> wrote:
> On Thu, Jan 1, 2015 at 9:48 AM, Joshua Ulrich <josh.m.ulrich at gmail.com> wrote:
>> To follow up with the solution I adopted in quantmod_0.4-3 (on CRAN as
>> of 2014-12-15): I moved all the necessary Defaults functionality
>> directly to quantmod.  This did not include Defaults' ability to
>> modify other package's namespaces, since that was a big reason Jeff
>> requested Defaults be archived.
>> This means that getSymbols.MySQL should function as it did when
>> quantmod depended on Defaults.  Also, any packages that depend on
>> quantmod and use the ported Defaults functionality should be able to
>> use quantmod_0.4-3 without losing functionality.  Packages that use
>> Defaults' ability to modify other package's namespaces will need to be
>> patched to work without that functionality.
>> On Wed, Oct 29, 2014 at 7:25 AM, Joshua Ulrich <josh.m.ulrich at gmail.com> wrote:
>>> As many of you know, the Defaults package was removed from CRAN on
>>> 2014-10-03 at Jeff's request.  This broke a fair bit of functionality
>>> in quantmod, most of which I have addressed in recent commits on
>>> R-Forge.
>>> One issue I have not resolved is how to adapt getSymbols.MySQL to the
>>> new no-Defaults paradigm.  I will be taking over as maintainer of
>>> quantmod, so I am soliciting input from getSymbols.MySQL users.
>>> My proposed solution to getSymbols.MySQL is to look for specific
>>> option()s if certain arguments are missing.  I think this is the
>>> cleanest and most obvious solution, but am open to alternatives.  I
>>> would use the option structure below, with only the three arguments
>>> listed.
>>> options(quantmod.defaults = list(
>>>   getSymbols.MySQL = list(
>>>     user="josh",
>>>     password="secret",
>>>     dbname="stocks")
>>>   )
>>> )
>>> Should I consider another option structure?  Should additional
>>> arguments be supported?  Anything else I'm missing?
>>> Thanks,
>>> --
>>> Joshua Ulrich  |  about.me/joshuaulrich
>>> FOSS Trading  |  www.fosstrading.com
>> --
>> Joshua Ulrich  |  about.me/joshuaulrich
>> FOSS Trading  |  www.fosstrading.com
>> _______________________________________________
>> R-SIG-Finance at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
>> -- Subscriber-posting only. If you want to post, subscribe first.
>> -- Also note that this is not the r-help list where general R questions should go.
> Should all of the fixes for these MySQL issues have migrated to CRAN
> by now? I'm still running
> my old code daily without using MySQL due to messages like this:
Yes, all the fixes mentioned above are on CRAN.

> [1] "From MySQL --  SPY"
> Error in (function (classes, fdef, mtable)  :
>   unable to find an inherited method for function ‘dbConnect’ for
> signature ‘"character"’
This is a separate issue caused by changes to the RMySQL API.  I don't
use this functionality, so I've opened an issue and asked for people
to test the proposed solution.

As you can see, there's been one response in the past month from an
anonymous person.  I'd like more feedback before pushing to CRAN.
Feedback quantity doesn't matter as much as quality. I'd be
comfortable with feedback from just one person I know I can trust.

I just pushed the proposed fix to branch RMySQL_45.  Hopefully that
will make it easier for others to test.

Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com
R/Finance 2015 | www.rinfinance.com

More information about the R-SIG-Finance mailing list