Feature/connection dataset

[jefferis]

@romainFr do you want to take a quick look at this? It means that you can specify a default dataset for a connection. I think this will make it easier to use two connections at the same time (e.g. test and public servers). However it also now makes it an error to have a bad dataset specification (rather than just ignoring it).

[romainFr]

Thanks @jefferis , that looks very useful. I'm getting some odd behavior when switching back and forth which I believe might have to do with caching. Let's say I have two connection objects,

newConnection <- neuprint_connection()

oldConnection <- neuprint_connection(server="https://emd.../",token = "e...k",config=httr::config(ssl_verifypeer=0L),dataset="hemibrain:vXX")

test2 <- neuprint_queryXXX()
## Results from newConnection

test2 <- neuprint_queryXXX(conn=oldConnection)
## Results from oldConnection

test2 <- neuprint_queryXXX()
## Results from oldConnection

test2 <- neuprint_queryXXX(conn=newConnection)
## Results from newConnection

###### SUPRISING TO ME
test2 <- neuprint_queryXXX()
## Results from oldConnection : it does not switch back to newConnection

In other words, the default does not switch more than once, I see the same behavior when trying to switch with neuprint_login. Am I misunderstanding the expected behavior?

[jefferis]

The default is currently to use the last connection added to the connection cache when none is specified. Connections are added to the connection cache when logging in to the server for the first time. Therefore what you see is the expected behaviour right now.

To be honest, the only 100% reliable way to deal with two (or more servers) is to make connection objects to both and specify them explicitly for each query.

conn1=neuprint_login('https://first.com')
conn2=neuprint_login('https://other.com')

Anything else relies strongly on the order of operations. You can make the order a bit safer by doing Force=T when you make the connections since this will cause server login to happen and ensure that they are (re)-added to the connection cache.

[romainFr]

Ah yes, that makes sense. It's ready for merge from my perspective (except that rhubarb should never trigger errors!).

[jefferis]

OK. Thanks @romainFr! Just a note that neuprint_connection makes a connection but does not login. neuprint_login does that. So if you do want to be sure about the order in which connections are added to the cache you may want to do

newConnection <- neuprint_login(Force=T)
oldConnection <- neuprint_login(server="https://emd.../",token = "e...k",config=httr::config(ssl_verifypeer=0L),dataset="hemibrain:vXX", Force=T)