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

[Dirk Eddelbuettel]

Hi Tomoaki,

On 5 February 2014 at 11:51, NISHIYAMA Tomoaki wrote:
| Hi Jeff,
| 
| I think A or B is preferred. 
| Cloning feature is of little benefit with large undesired feature.
| When cloning occurs, the transaction state becomes independent, and
| any change made at the other connection may not be visible to the other connection.
| Doing such thing in a hidden scene should be best avoided.
| 
| In RPostgreSQL, I removed the connection cloning about 2 years ago, which perhaps inherited from RMySQL.
| http://code.google.com/p/rpostgresql/source/diff?spec=svn230&r=230&format=side&path=/trunk/RPostgreSQL/R/PostgreSQLSupport.R

Good move, and the guilty party is me as I mentored Sameer for the GSoC /
RPostgreSQL project with RMySQL as a shining example of how to do DBI :)

Luckily we now have you, and all DBI packages could do a lot worse than to
study what you have done to enhance and improve RPostgreSQL. It's a marvel.

Thanks for all your work on this.

Dirk


| Some of the most likely scenario why users do not collect all the data after dbSendQuery(), 
| could that they aren't concerned on the results at all, as they have
| submitted some SET, INSERT, or UPDATE statements. (Although it is better to check for any error.)
| Making this as a error might make them some stress.
| Emitting error would benefit only at a time they try to read the discarded result set.
| 
| D would perhaps make too much complication of the program with little benefit.
| (I really do not see any good reason to *silently* make 
| clone of the connection even as an option.)
| 
| Kind regards,
| Tomoaki
| -- 
| Tomoaki NISHIYAMA
| 
| Advanced Science Research Center,
| Kanazawa University,
| 13-1 Takara-machi, 
| Kanazawa, 920-0934, Japan
| 
| 
| On 2014/02/05, at 8:27, 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.
| > 
| > 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
| >> 
| > 
| > _______________________________________________
| > 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
| 
| _______________________________________________
| 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

-- 
Dirk Eddelbuettel | edd using debian.org | http://dirk.eddelbuettel.com