dijous, 30 de maig de 2013

MyQuery per a Windows Phone

L'aplicació ja està en marxa!!!!
Treballant en un projecte nou, desenvolupament oficial per a terminals amb windows phone.  En projecte MyQuery: poder executar consultes SQL a qualsevol servidor MySQL, sent necessaris(alguns són obvis) els següents paràmetres:
  • Servidor de base de dades
  • usuari
  • password
  • Consulta SQL
  • base de dades
Pròximament i possible:
  • Xifrat
  • Altres servidors que no siguen MySQL

L'aplicació consistirà posar els paràmetres de connexió, introduïr la consulta (bé siga select, insert, alter..) i es mostrarà el resultat de forma tabular.












Òbviamnet no hi ha drivers de mySQL per a windows phone, ni trobe què per a cap dispositiu mòvil, per tant he havut d'utilitzar un servidor intermediari que farà les connexions i l'aplicació rebrà el resultat. L'aplicació es gratuïta i a veure si es pot traure algo (si pagara el servidor ja em pegaria amb un canto en les dents) mitjançant adds. Estic platejant-me una aplicació que costé (pocs) diners MyQuery+ amb els següents afegits:
  • Sense publicitat
  •  Xifrat
  • el límit de la consulta a 2000 caràcters, ara està en 1024
  • Connexió a altres servidors SQL
  • Algun trigger que t'avise quan es cumplisquen certes condicions (cert camp aplegue a un valor determinat)
  • ...

dilluns, 13 de maig de 2013

Per fi!, tema dominat: mysql asincron en node.js

Escoltant marea (no té res a veure, però així indique preferències musicals ;)), he trobat la solució al problema dels posts anteriors. Resulta que la funció query del paquet és asíncrona, és a dir que no se pot saber quan s'executarà, però serà quan s'acabe la funció que la crida. Aleshores el que hem de fer és no retornar la resposta fins que no s'execute el callback. I així ens evitem el problema, si has estat seguint el post entendràs la consulta i tot:


function fservidor(request, response){
var resXML="<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?><resposta>";
function frequeston(){
  // El codi 200 vol dir què la petició ha segut correcta, i enviem la resposta en text pla.
   response.writeHead(200, {
         'Content-Type': 'text/plain'
      }); //end writehead
 }//end frequeston

request.on("end", frequeston);
 var client = mysql.createConnection('mysql://'+user + ':'+pass+'@'+server+'/'+database);
 client.query("select * from personatges",function (err,result){
   resXML+="<personatges><personatge><id>" + result[0].id + "</id></personatge></personatges>";
   resXML+="</resposta>";
 response.end(resXML);
  }//callback query
 );//query


}

var servidor = http.createServer(fservidor);
servidor.listen(10000);



Si ens fixem la línia en roig, (la resposta), està fins el callback, per tant ens assegurem que no es retornarà la resposta al client fins que no s'execute el callback. Això és així per què el servidor node.js té un únic fil, (al contrari, com per exemple php, que cada petició és un nou fil), i per cada petició s'execute una vegada fservidor() fins que acaba. Si mysql fora síncrona, i fora una consulta llarga (per exemple), el servidor quedaria colapsat fins que la petició a la base de dades es realitzara i no estaria realitzant cap procés. Així, retorna el control i pot atendre les següent peticions. Recordem node.js és un servidor orientat a events.
La resposta en l'exemple, òbviament no té molt de sentit lògic però si ilustratiu:

<?xml version="1.0" encoding="ISO-8859-1"?>
<resposta><personatges><personatge><id>1</id></personatge>
</personatges></resposta>



dilluns, 6 de maig de 2013

L'estotèric abast de les variables en node.js

Com ja comentava en l'anterior post, ja duc un temps barallant-me amb handlers i demés malea del node.js. Crec que he descobert un altre problema de node.js. L'abast de les variables. Si jo definisc una variable en una funció, les modificacions fetes en la variable en les funcions definides dins no quedaran guardades. Trobe què és molt més fàcil veure-ho amb un exemple, si jo tinc el següent codi paregut als exemples anteriors (recordem la taula de personatges del joc de rol simple):

var resXML="<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?><resposta>";
   var i=0;
   client.query(action, function getSQL(err,result,fields){
     //console.log(fields);
     if (err){
       console.log("Error: " + err);
     }//if
     resXML = resXML + "<" + fields[0].table + ">";
     for(i=0;i<result.length;i++){
             resXML = resXML+"<"+fields[i].name+">" + i + "<" + fields[i].name + "/>";
     }//for
     resXML = resXML+"<" + fields[0].table + "/>";
     console.log(resXML);
   } //end getSQL
   );//client.query
   resXML =resXML+"</resposta>";
  console.log(resXML);


independentment del significat del codi (estava fent proves, per tant no en té molt), vegem dos línies de console.log, una en roig i l'altra en blau. La principal diferència és què una està dins de la funció que manipula el resultat i l'altra fora. El resultat aparent deuria de ser què, llevat de l'afegit  "</resposta>" de l'última línia, deuria de ser igual. Doncs no, el resultat és este:
Fora:<?xml version="1.0" encoding="ISO-8859-1"?><resposta></resposta>
Dins:<?xml version="1.0" encoding="ISO-8859-1"?><resposta></resposta><personatges><id>0<id/><nom>1<nom/><classe>2<classe/><personatges/>

És a dir, primer acaba la funció i després realitza el "callback", si analitzem el fora/dins. Això és "lògic", tal i com he comentat este matí en l'anterior post. El problema "greu", és que la variable resXML no ha estat modificada, o almenys no quan acaba eixa funció, cosa que fa que el valor de la variable resXML no valga per a res. Aleshores, en la pràctica, les variables de fora, no es poden modificar dins, i el que veuen és una còpia de "només lectura", tipus els paràmetres dels llenguatges de programació tradicional.
Val a dir que no he investigat tant per saber com és la teoria, ja què és possible que en la teoria diga que si que són modificables, però en la pràctica, almenys en funcions asíncrones, no ho són; ja què, quan puga ser actualitzat el seu valor realment, siga massa tard.

Tot això em fa pensar que he estat perdent el temps (bo, allò que el saber no ocupa lloc, però molt de temps), i podria passar-me  a programar servidors en qualsevol altre llenguatge... per molt que el meu vell amic Jaume Cardona n'estiga d'enamorat, del node.js. Amb PHP possiblement hauria acabat totes les proves ja.

Handlers d'errors en node.js quina bogeria ;)

Després de dos dies tornat-me varilla amb els handlers d'error en node.js, al final, quasi de casualitat he descobert que passa. Imaginem que vull connectar a una base de dades:

function doLogin(){
  var client = mysql.createConnection('mysql://'+user + ':'+pass+'@'+server+'/'+database);
  client.connect();
 }//function doLogin


La funció connect pot fallar en cas que els paràmetres siguen incorrectes, no hi haja connexió... si eixe error no és capturat, tanca el programa (tancant el servidor). Primer proví amb try catch, herència d'altres llenguatges no tant moderns ;) i no, no vaig aconseguir capturar l'error. Per tant vaig llegir que la millor cosa que podia fer en javascript (node.js) era afegir  una funció callback (que s'executa en cas d'error, i passada com a paràmetre). La funció ha de ser algo així:

 function errResult(err,result){
  if (err != null) {
         berror = true;
   }
  else{
       berror = false;
  }
 }//function errResult


on en err estarà el missatge d'error i berror serà una variable d'error que podrem examinar si hi ha havut error o no al login. canviarem el codi de doLogin per:

client.connect(errResult);

i tindrem el codi següent per a veure si s'ha produït el login correctament:

doLogin()
if (!berror) {//login OK
    res= "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?><resposta>OK</resposta>";
  }
  else{//error login
    res = cadena_error_login_ini + error_missatge +cadena_error_login_fi;
  }

La lògica ens dius que quan cridem a doLogin, esta cridarà a errResult i actualitzarà la variable berror en el cas pertinent. Això pensava jo i res més lluny de la realitat. La cosa és que posara les dades que posara sempre em donava OK. Com ja he dit duc un cap de setmana fent proves i no hi ha habut manera. Al final he decidit fer un log de totes les accions a veure que passava:

 function doLogin(){
  var client = mysql.createConnection('mysql://'+user + ':'+pass+'@'+server+'/'+database);
  console.log("Abans de connect");
  client.connect(errResult);
  console.log("Després de connect");
 }//function doLogin


function errResult(err,result){
  if (err != null) {
     error_missatge=err;
     berror = true;
     console.log("Ha havut un error però s\'haurà capturat?");
   }
  else{
    error_missatge = "";
    berror = false;
  }
  console.log(berror);
 }//function errResult


I en la funció del servidor (hi ha més coses però les estic omitint per no fer més llarg el copy & paste):

doLogin();
  console.log("doLogin");
  if (!berror) {//login OK
    res= "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?><resposta>OK</resposta>";
  }
  else{//error login
    res = cadena_error_login_ini + error_missatge +cadena_error_login_fi;
  }

 response.end(res);
console.log("final servidor");





L'eixida de consola deuria de ser:
Abans de connect
Ha havut un error però s'haurà capturat?
 Després de connect
doLogin
final servidor





Però no, resulta ser:

Abans de connect
Després de connect
doLogin
final servidor
Ha havut un error però s'haurà capturat?

Cosa que ens indica que la funció callback de maneig d'error s'execute una vegada ha acabat la funció principal del servidor. Per tant este model no ens val per capturar l'error. Caldrà canviar el model, pròximament posaré la solució al problema ;)