[R-sig-DB] RFI on changing behavior in next RMySQL release

[Paul Gilbert]

On 02/04/2014 06:27 PM, Paul Gilbert wrote:
> Jeff
>
> The one thing I would be concerned about is if the (default) behaviour
> of dbGetQuery() in RMySQL deviates much from dbGetQuery() in other DBI
> packages like TSPostgreSQL, TSSQLite, ... . I am using code that is
> generic across all these.

I meant RPostgreSQL, RSQLite, ... . The TS* packages are mine that are 
built on top of these. Paul
>
>  From your description I am not sure if this problem is really specific
> to RMySQL, or also happens with other engines, so, whether your proposed
> change will make things more similar or less similar. (I have not been
> using dbSendQuery() so may have just been luck.)
>
> Paul
>
> On 02/03/2014 11:46 AM, Jeffrey Horner wrote:
>> Hi,
>>
>> A situation has been brought to my attention by two RMySQL users who have
>> posted their issues on github.
>>
>> As followers of this mailing list, most will be familiar with the two
>> ways
>> in which SQL queries are executed and results obtained via the DBI:
>>
>> 1. users execute dbSendQuery(), get back a result set object and use
>> subsequent functions dbHasCompleted(), fetch(), and possibly
>> dbClearResult() act on the result set.
>>
>> 2. users execute dbGetQuery() to perform just one function to execute the
>> SQL, gather the result set, and return to the user.
>>
>> In RMySQL, connection level options can be set that affect the work done
>> for the duration of the connection only. For instance, one user sets the
>> connection level character set to ensure that all results are transferred
>> in UTF8.
>>
>> The issue is that RMySQL will create temporary connections unbeknownst to
>> the user during a call to dbGetQuery() if the user has previously
>> performed
>> a dbSendQuery() without getting rid of the returned result set object. In
>> essence, this is a user who has not been enlightened on exactly what's
>> going on, they didn't fully read and comprehend the documentation.
>>
>> I'd like to get rid of the temporary connection feature, let's call it
>> cloning the connection as that's the name of the low level mysql C
>> function
>> that takes care of creating the temporary connection, but I'd like to
>> make
>> this change in a way that doesn't place too much stress on the user.
>>
>> So, here are some options I've come up with to alter dbGetQuery() and the
>> other functions that create temporary connections, but I'd like to get
>> the
>> list users opinions on this before I release:
>>
>> A) Do I silently remove the pending result set objects altogether,
>> B) Do I do A but with a warning,
>> C) Do I throw an error and let the user fix his/her code,
>> D) Do I add a dbConnect() connection argument called 'clone' that tells
>> whether or not to allow temporary cloning of the connection, and what
>> should the default argument value be, TRUE or FALSE?
>>
>> D) was suggested by a github user, so I'm inclined to go with that.
>>
>> Thanks for your thoughts on this.
>>
>> Jeff
>>
>>     [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-DB mailing list -- R Special Interest Group
>> R-sig-DB using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-db
>>