Open remymoine opened 5 years ago
Faudra qu'on discute des objectifs. A mon sens il faut qu'on fasse un truc cohérent dans ce qu'on développe les uns les autres. Mais l'utilisateur en lui même ne doit pas avoir de requêtes à faire il doit se limiter 1 ses connaissances en R habituelles donc faire ses éventuels tris avec des subset par exemple. A voir ce que tu entends pas construire les requêtes et de qui tu parles ;) nous ou les utilisateurs
Premiers points définis pour la bonne construction des fonctions R :
Les fonctions du package sont préfixées par "gn." gn.getData par exemple pour une fonction d'extraction de données.
La documentation est rédigée en français.
Chaque fonction ouvre sa connexion et la referme (sinon Postgresql nous rejete à la 16eme connexion ouverte, donc à la 16eme fonction jouée):
Pour l'ouverture de connexion, elle s'appuie sur l'objet setupDB créé par la fonction gn.setup() qui doit être jouée en début de session par l'utilisateur. C'est le seul moment où les informations de connexion à la base sont demandées. Les fonctions requêtant sur la base de données doivent donc comporter :
con<-dbConnect(dbDriver("PostgreSQL"), dbname = setupDB$dbname,host = setupDB$host, port = setupDB$port,user = setupDB$user, password = setupDB$pass)
Chaque fonction doit se terminer en refermant sa connexion après avoir fait ses requêtes sur la base :
invisible(dbDisconnect(conn = con))
Les requêtes SQL doivent être envoyées "figées" dans les fonctions type getquery. La solution est donc que la fonction crée un objet "query", qui soit une chaine de caractère créée et "personnalisée" par R en y intégrant les arguments renseignés par l'utilisateur. C'est cet objet query qui est renvoyé dans les commandes getquery.
Une représentation graphique interactive pourrait être une idée, non ?