RFC: quantmod::getSymbols.MySQL

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: quantmod::getSymbols.MySQL

Joshua Ulrich
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

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

gsee
Hi Josh,

As you probably noticed, I updated getSymbols.FI() to use options a
couple weeks ago, but instead of using a single option that is a list,
I made a separate option for each function argument.  This allows two
things:  1) you can have different default values set for the "from"
argument (for example) of different getSymbols.*() methods. 2) It
doesn't change the old defaults.  i.e. getOption("someOption",
"2014-01-01") will return the value of the option if it is set, or
"2014-01-01" if not.

With your list structure, the default value has to be determined
inside the function, I suppose.

Here's the formal argument list for getSymbols.FI

> args(getSymbols.FI)
function (Symbols, from = getOption("getSymbols.FI.from", "2010-01-01"),
    to = getOption("getSymbols.FI.to", Sys.Date()), ..., dir =
getOption("getSymbols.FI.dir",
        ""), return.class = getOption("getSymbols.FI.return.class",
        "xts"), extension = getOption("getSymbols.FI.extension",
        "rda"), split_method = getOption("getSymbols.FI.split_method",
        c("days", "common")), use_identifier =
getOption("getSymbols.FI.use_identifier",
        NA), date_format = getOption("getSymbols.FI.date_format"),
    verbose = getOption("getSymbols.FI.verbose", TRUE), days_to_omit =
getOption("getSymbols.FI.days_to_omit",
        c("Saturday", "Sunday")), indexTZ = getOption("getSymbols.FI.indexTZ",
        NA))


Garrett

On Wed, Oct 29, 2014 at 7:25 AM, Joshua Ulrich <[hidden email]> 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
>
> _______________________________________________
> [hidden email] 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.

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Mark Knecht
In reply to this post by Joshua Ulrich
On Wed, Oct 29, 2014 at 5:25 AM, Joshua Ulrich <[hidden email]> 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
>

Hi Josh,
   I'd lobby for adding 'host' and (I think) 'port' parameters also.
This allows you to get across the network to get the data.

   As an individual user type this is OK. Not great, but OK. I'd
probably add the code above into a file I source in most of my
programs and it would get run. Over time I'll forget where this is
though and will need to find it when I create new databases or change
passwords.

   In a more corporate setting (which isn't me these days) I'm not
sure it's very good. Standard usage (on Linux anyway, not sure about
Windows) is to have a .my.cnf file:

mark@c2RAID6 ~ $ cat .my.cnf
[client]
user = josh
password = secret
host = localhost

[beancounter]
user = josh
database = beancounter
password = secret
host = localhost

mark@c2RAID6 ~ $

If MySQL needs a password that's where it looks first. There are no
security issues with the R code this way. If I change my password in
MySQL then this is the one place I change it for all my programs (R or
otherwise) that use MySQL to work. This is how I was doing it prior to
the change with Defaults. I have no idea how much MySQL is used by
corporate R users but I suspect they'd prefer this if it's possible.

Thanks,
Mark

_______________________________________________
[hidden email] 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.
markknecht@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Zachary Mayer
Hi Mark,

It'd be a little cumbersome, but couldn't you also source() an R script at
the start of your session that loads the parameters from .my.cnf and passes
them to options()?

Alternatively, maybe getSymbols.MySQL could look for a cnf_file option, and
then if that is not present look for a username and password?

-Zach

On Wed, Oct 29, 2014 at 9:00 AM, Mark Knecht <[hidden email]> wrote:

> On Wed, Oct 29, 2014 at 5:25 AM, Joshua Ulrich <[hidden email]>
> 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
> >
>
> Hi Josh,
>    I'd lobby for adding 'host' and (I think) 'port' parameters also.
> This allows you to get across the network to get the data.
>
>    As an individual user type this is OK. Not great, but OK. I'd
> probably add the code above into a file I source in most of my
> programs and it would get run. Over time I'll forget where this is
> though and will need to find it when I create new databases or change
> passwords.
>
>    In a more corporate setting (which isn't me these days) I'm not
> sure it's very good. Standard usage (on Linux anyway, not sure about
> Windows) is to have a .my.cnf file:
>
> mark@c2RAID6 ~ $ cat .my.cnf
> [client]
> user = josh
> password = secret
> host = localhost
>
> [beancounter]
> user = josh
> database = beancounter
> password = secret
> host = localhost
>
> mark@c2RAID6 ~ $
>
> If MySQL needs a password that's where it looks first. There are no
> security issues with the R code this way. If I change my password in
> MySQL then this is the one place I change it for all my programs (R or
> otherwise) that use MySQL to work. This is how I was doing it prior to
> the change with Defaults. I have no idea how much MySQL is used by
> corporate R users but I suspect they'd prefer this if it's possible.
>
> Thanks,
> Mark
>
> _______________________________________________
> [hidden email] 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.
>

        [[alternative HTML version deleted]]

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Joshua Ulrich
On Wed, Oct 29, 2014 at 8:38 AM, Zachary Deane-Mayer
<[hidden email]> wrote:
> Hi Mark,
>
> It'd be a little cumbersome, but couldn't you also source() an R script at
> the start of your session that loads the parameters from .my.cnf and passes
> them to options()?
>
Better yet, put that in your .Rprofile.

> Alternatively, maybe getSymbols.MySQL could look for a cnf_file option, and
> then if that is not present look for a username and password?
>
As I replied to Mark, this would be new functionality and it would be
low priority for me.

> -Zach
>
> On Wed, Oct 29, 2014 at 9:00 AM, Mark Knecht <[hidden email]> wrote:
>>
>> On Wed, Oct 29, 2014 at 5:25 AM, Joshua Ulrich <[hidden email]>
>> 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
>> >
>>
>> Hi Josh,
>>    I'd lobby for adding 'host' and (I think) 'port' parameters also.
>> This allows you to get across the network to get the data.
>>
>>    As an individual user type this is OK. Not great, but OK. I'd
>> probably add the code above into a file I source in most of my
>> programs and it would get run. Over time I'll forget where this is
>> though and will need to find it when I create new databases or change
>> passwords.
>>
>>    In a more corporate setting (which isn't me these days) I'm not
>> sure it's very good. Standard usage (on Linux anyway, not sure about
>> Windows) is to have a .my.cnf file:
>>
>> mark@c2RAID6 ~ $ cat .my.cnf
>> [client]
>> user = josh
>> password = secret
>> host = localhost
>>
>> [beancounter]
>> user = josh
>> database = beancounter
>> password = secret
>> host = localhost
>>
>> mark@c2RAID6 ~ $
>>
>> If MySQL needs a password that's where it looks first. There are no
>> security issues with the R code this way. If I change my password in
>> MySQL then this is the one place I change it for all my programs (R or
>> otherwise) that use MySQL to work. This is how I was doing it prior to
>> the change with Defaults. I have no idea how much MySQL is used by
>> corporate R users but I suspect they'd prefer this if it's possible.
>>
>> Thanks,
>> Mark
>>
>> _______________________________________________
>> [hidden email] 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.
>
>


--
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Mark Knecht
In reply to this post by Zachary Mayer
On Wed, Oct 29, 2014 at 6:38 AM, Zachary Deane-Mayer
<[hidden email]> wrote:

> Hi Mark,
>
> It'd be a little cumbersome, but couldn't you also source() an R script at
> the start of your session that loads the parameters from .my.cnf and passes
> them to options()?
>
> Alternatively, maybe getSymbols.MySQL could look for a cnf_file option, and
> then if that is not present look for a username and password?
>
> -Zach

Hi Zach & Josh,
   Yes, I'm sure there's lots of ways to do this, and as an individual
user just working by myself I'll be happy for anything that works.

   That said, the nice security feature about the way it was done
before was TTBOMK the R environment never saw the MySQL username &
password. That was previously all done completely outside of R. R Asks
MySQL to get some data from a specific database. MySQL wasn't given a
username and password so it automatically accesses .my.cnf which is
secure. If it finds an entry with the right database name, then it
gets username and password from that file, gets the data from the
database and gives it back to R. If the username/password aren't there
the user can pass them explicitly (as I'm doing with this recent
change) or else he doesn't get access to that database.

   But going beyond that model consider a C++/GTK application that
links calls to R under the hood using the Rinside package. (Something
I'm just starting to play with now.) I'm in a GTK-based GUI, using C++
code that runs R functions one of which is accessing MySQL to get
price data. The results are loaded by R, indicators are calculated and
I see them in my GTK GUI. Now, I send the compiled app to a friend.
How would MySQL work in that case? Today he just puts an entry in
.my.cnf on his machine and he's good to go. (NOTE: I'm not looking for
an answer to this specific issue. In my specific case I may access
MySQL from C and pass the data to R as it appears to be a lot faster.)

   Anyway I don't think this is really a new feature. It's the
standard MySQL security model. It used to work and was broken by the
recent change to defaults. All that said I'll of course use what ever
gets supported. I'm just pointing out the issue, not trying to create
work for anyone.

Cheers,
Mark

_______________________________________________
[hidden email] 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.
markknecht@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Paul Gilbert-2


On 10/29/2014 10:36 AM, Mark Knecht wrote:

> On Wed, Oct 29, 2014 at 6:38 AM, Zachary Deane-Mayer
> <[hidden email]> wrote:
>> Hi Mark,
>>
>> It'd be a little cumbersome, but couldn't you also source() an R script at
>> the start of your session that loads the parameters from .my.cnf and passes
>> them to options()?
>>
>> Alternatively, maybe getSymbols.MySQL could look for a cnf_file option, and
>> then if that is not present look for a username and password?
>>
>> -Zach
>
> Hi Zach & Josh,
>     Yes, I'm sure there's lots of ways to do this, and as an individual
> user just working by myself I'll be happy for anything that works.
>
>     That said, the nice security feature about the way it was done
> before was TTBOMK the R environment never saw the MySQL username &
> password. That was previously all done completely outside of R. R Asks
> MySQL to get some data from a specific database. MySQL wasn't given a
> username and password so it automatically accesses .my.cnf which is
> secure. If it finds an entry with the right database name, then it
> gets username and password from that file, gets the data from the
> database and gives it back to R. If the username/password aren't there
> the user can pass them explicitly (as I'm doing with this recent
> change) or else he doesn't get access to that database.

Not being a user of the packages under discussion, other than RMySql
(and assuming it is RMySQL you are talking about underneath), I am a bit
confused about why you think this has been broken by changes to
defaults? If anything, it seems to depend on R not doing anything, and
letting the driver handle it. I still use this approach in my own
packages that use RMySQL. I think it is the default if
host/user/password are not explicitly specified in another way. I also
believe it is generally considered the most secure approach because
sensitive information is not left sitting around in more viewable
places. Am I missing something (as usual)?

Paul

>
>     But going beyond that model consider a C++/GTK application that
> links calls to R under the hood using the Rinside package. (Something
> I'm just starting to play with now.) I'm in a GTK-based GUI, using C++
> code that runs R functions one of which is accessing MySQL to get
> price data. The results are loaded by R, indicators are calculated and
> I see them in my GTK GUI. Now, I send the compiled app to a friend.
> How would MySQL work in that case? Today he just puts an entry in
> .my.cnf on his machine and he's good to go. (NOTE: I'm not looking for
> an answer to this specific issue. In my specific case I may access
> MySQL from C and pass the data to R as it appears to be a lot faster.)
>
>     Anyway I don't think this is really a new feature. It's the
> standard MySQL security model. It used to work and was broken by the
> recent change to defaults. All that said I'll of course use what ever
> gets supported. I'm just pointing out the issue, not trying to create
> work for anyone.
>
> Cheers,
> Mark
>
> _______________________________________________
> [hidden email] 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.
>

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Mark Knecht
On Wed, Oct 29, 2014 at 12:30 PM, Paul Gilbert <[hidden email]> wrote:

>
>
> On 10/29/2014 10:36 AM, Mark Knecht wrote:
>>
>> On Wed, Oct 29, 2014 at 6:38 AM, Zachary Deane-Mayer
>> <[hidden email]> wrote:
>>>
>>> Hi Mark,
>>>
>>> It'd be a little cumbersome, but couldn't you also source() an R script
>>> at
>>> the start of your session that loads the parameters from .my.cnf and
>>> passes
>>> them to options()?
>>>
>>> Alternatively, maybe getSymbols.MySQL could look for a cnf_file option,
>>> and
>>> then if that is not present look for a username and password?
>>>
>>> -Zach
>>
>>
>> Hi Zach & Josh,
>>     Yes, I'm sure there's lots of ways to do this, and as an individual
>> user just working by myself I'll be happy for anything that works.
>>
>>     That said, the nice security feature about the way it was done
>> before was TTBOMK the R environment never saw the MySQL username &
>> password. That was previously all done completely outside of R. R Asks
>> MySQL to get some data from a specific database. MySQL wasn't given a
>> username and password so it automatically accesses .my.cnf which is
>> secure. If it finds an entry with the right database name, then it
>> gets username and password from that file, gets the data from the
>> database and gives it back to R. If the username/password aren't there
>> the user can pass them explicitly (as I'm doing with this recent
>> change) or else he doesn't get access to that database.
>
>
> Not being a user of the packages under discussion, other than RMySql (and
> assuming it is RMySQL you are talking about underneath), I am a bit confused
> about why you think this has been broken by changes to defaults? If
> anything, it seems to depend on R not doing anything, and letting the driver
> handle it. I still use this approach in my own packages that use RMySQL. I
> think it is the default if host/user/password are not explicitly specified
> in another way. I also believe it is generally considered the most secure
> approach because sensitive information is not left sitting around in more
> viewable places. Am I missing something (as usual)?
>
> Paul

Hi Paul,
    Yeah, I may be talking out of my arse at this point. Looking back
at my code here's the changes that we've had to make due to the
defaults stuff getting taken out:

if (UseMySQL){
  if (MyAdjust) { dbName = paste0(dbName, "Adjust")}
  dbc = dbConnect(MySQL(), dbname=dbName)
#  setDefaults(getSymbols.MySQL, user="myName", password="myPassword",
dbname=dbName)
}

if (DownloadNewData){
  if (!UseMySQL){
    for (i in 1:length(TestSym)){
      print(paste("From ",SymbolSrc," -- ",TestSym[i]))
      getSymbolsCont(TestSym[i], from = DataStart, to = DataEnd,
adjust = MyAdjust, src=SymbolSrc)
    }
  } else {
    for (i in 1:length(TestSym)){
      print(paste("From MySQL -- ",TestSym[i]))
#      getSymbols(TestSym[i], src="MySQL")
      getSymbols(TestSym[i], src="MySQL", user="myName",
password="myPassword", dbname=dbName)
      assign(TestSym[i], get(TestSym[i])[paste0(DataStart,"/",DataEnd)])
    }
    dbDisconnect(dbc)
  }
}

I guess it doesn't matter where I set the name & password. I'm
confusing this whole thing with a different thread.

Sorry,
Mark

_______________________________________________
[hidden email] 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.
markknecht@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Mark Knecht
In reply to this post by Mark Knecht
On Wed, Oct 29, 2014 at 7:36 AM, Mark Knecht <[hidden email]> wrote:

> On Wed, Oct 29, 2014 at 6:38 AM, Zachary Deane-Mayer
> <[hidden email]> wrote:
>> Hi Mark,
>>
>> It'd be a little cumbersome, but couldn't you also source() an R script at
>> the start of your session that loads the parameters from .my.cnf and passes
>> them to options()?
>>
>> Alternatively, maybe getSymbols.MySQL could look for a cnf_file option, and
>> then if that is not present look for a username and password?
>>
>> -Zach
>
> Hi Zach & Josh,
>    Yes, I'm sure there's lots of ways to do this, and as an individual
> user just working by myself I'll be happy for anything that works.
>
>    That said, the nice security feature about the way it was done
> before was TTBOMK the R environment never saw the MySQL username &
> password.

I've gone back and looked at my code only to find that R has never
TTBOMK looked at .my.cnf. I've confused this whole thing with an
earlier request that never gained traction.

My apologies for the noise.

- Mark

_______________________________________________
[hidden email] 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.
markknecht@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Paul Gilbert-2
In reply to this post by Joshua Ulrich


On 10/29/2014 08:25 AM, Joshua Ulrich 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")
>    )
> )
What I do is something like this, but default to user/password/host
equal "" or NULL, in which case  I assume the .my.cnf file will be used
and make the connection without specifying user/password/host.

Paul

>
> Should I consider another option structure?  Should additional
> arguments be supported?  Anything else I'm missing?
>
> Thanks,
>

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Joshua Ulrich
In reply to this post by Joshua Ulrich
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 <[hidden email]> 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

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Mark Knecht
On Thu, Jan 1, 2015 at 9:48 AM, Joshua Ulrich <[hidden email]> 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 <[hidden email]> 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
>
> _______________________________________________
> [hidden email] 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:

[1] "From MySQL --  SPY"
Error in (function (classes, fdef, mtable)  :
  unable to find an inherited method for function ‘dbConnect’ for
signature ‘"character"’

Thanks,
Mark

_______________________________________________
[hidden email] 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.
markknecht@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Joshua Ulrich
On Tue, Apr 28, 2015 at 8:25 AM, Mark Knecht <[hidden email]> wrote:

> On Thu, Jan 1, 2015 at 9:48 AM, Joshua Ulrich <[hidden email]> 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 <[hidden email]> 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
>>
>> _______________________________________________
>> [hidden email] 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.
https://github.com/joshuaulrich/quantmod/issues/45

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.

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

_______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: quantmod::getSymbols.MySQL

Mark Knecht
On Tue, Apr 28, 2015 at 6:51 AM, Joshua Ulrich <[hidden email]> wrote:
<SNIP>

>> 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.
> https://github.com/joshuaulrich/quantmod/issues/45
>
> 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.
>
> Best,
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
> R/Finance 2015 | www.rinfinance.com

OK, well as an acknowledged dummy, in RStudio I see that quantmod-0.4-4 is
installed and nothing newer is showing up as a package update. I suspect I'd
need to either wait a bit longer or else install quantmod from some
other location
using some other method?

_______________________________________________
[hidden email] 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.
markknecht@gmail.com