Aiuto per debug - Problema incomprensibile.

[}gu|do[z]{®©]

Cerco di farla breve ma è un po' lunghina.

Sto lavorando per un istituto di ricerca che si occupa di biologia computazionale e robetta simile.

Nell'ambito della creazione di un webservice, ho creato uno script PHP di importazione dati che, dopo aver verificato se l'istituto che rilascia questi dati li ha aggiornati rispetto alla versione importata precedentemente, scarica un file dati (una sorta di CSV, ma con il tab come separatore), e li importa nel nostro database.

Quello che accade è, per quanto sembri assurdo a me stesso, che il processo di importazione sul file già scaricato in precedenza (dallo stesso script, o scaricato "a mano") va a gonfie vele, mentre il processo di importazione che scarichi da capo il file abbia sempre lo stesso identico problema e non inserisca gli ultimi 9 record (su 104.000 e rotti).

Non si tratta di un problema di timeout e credo neanche di memoria, nè di file corrotto in qualche modo (lo stesso file che non viene importato completamente appena scaricato, viene importato ad un secondo tentativo, commentando la parte che scarica i dati e lasciando quella che li importa).

L'errore restituito da mysql sulle righe fatali è un "Column count doesn't match value count", per cui ho subito pensato ad un problema nell'esplodere i campi dalla riga-record.
Per verificare la cosa ho estratto da shell le ultime righe del file (quelle problematiche) e aprendo il file con un editor ed evidenziando i caratteri nascosti sembrava esserci in ognuna delle righe "difettose" un tab diverso dagli altri (con lo stesso simbolo degli altri tab ma con in più dello spazio subito dopo, che in realtà non è un carattere di spazio... era tutto un unico carattere),che avrebbe poruro magari farmi esplodere male (un campo in più o in meno al moemnto dell'inserimento nel database)

Perplesso dalla cosa ho visualizzato in esadecimale una riga "non buona", ma tra il tab e il carattere successivo non c'era niente.

Ricordandomi che la prima volta avevo due script separati per download e import, e tutto era andato bene, ho fatto allora un po' di test: ho fatto almeno 15 test su 3 distinte macchine e, per quanto sembri assurdo da qualsiasi punto di vista, tutte le volte lo stesso identico file viene correttamente importato dallo stesso identico codice, se isolato, ma non nel processo completo download+import (prima resetto il database in modo che lo script trovi un file "aggiornato", poi lancio lo script completo che si blocca sempre con lo stesso errore sulla stessa riga, poi mantengo il file scaricato nella prova precedente ma commento tutta la parte di verifica aggiornamento e download, e quello stesso file viene importato).

Poichè questo script andrà in un crontab non posso spezzare la cosa in due fasi (non saprei quando il primo script ha finito il download, e qualsiasi scelta di tempificazione per lanciare l'import, fosse anche ad un giorno di distanza, sarebbe arbitraria. Probabilmente con un lungo intervallo funzionerebbe, m sarebbe arbitraria ed indeterministica, e questa non sarebbe cosa buona e giusta :P


Aggiungo che se dirotto le query su un file esterno, rifaccio il test con download e senza download e poi confronto i due file generati con diff, quello che ottengo è questo:

104285c104285,104293
< INSERT INTO `ssgi_test2` VALUES ('TC407206','','','','homologue to Cluster: PREDICTED: similar to s');
---
> INSERT INTO `ssgi_test2` VALUES ('TC407206','','','','homologue to Cluster: PREDICTED: similar to serine carboxypeptidase 1 precursor protein; n=1; Equus caballus|Rep:,  partial (44%)','GGAATAAGTTGGATATGATCATCTTCTAATCCGTTCCCATTCCCAAGTCCTTGCACGTGTGGCTCCTGGC');
> INSERT INTO `ssgi_test2` VALUES ('TC407207','','','','similar to Cluster: Putative uncharacterized protein; n=1; Plasmodium vivax|Rep: Putative uncharacterized,  partial (2%)','TAAGTAGTACAGTCTATCATTCAGCTTATCACTTAATACATAGGTCTGCACTAGAGCCTGTTTTTTGTTT');
> INSERT INTO `ssgi_test2` VALUES ('TC407208','','','','similar to Cluster: PREDICTED: similar to koyt binding protein 1 isoform 1; n=1; Equus caballus|Rep: PREDICTED:,  partial (60%)','AGTCCTAGGCAGACCTAAAGGAAAAGCTCCTTAAACACCCTCTTCTACATCAGGGATAGGAAAGAAATAT');
> INSERT INTO `ssgi_test2` VALUES ('TC407209','','','','weakly similar to Cluster: Putative MHC class I related antigen; n=1; Sus scrofa|Rep: Putative MHC class I related,  partial (6%)','TACTGTTCAAGAGTCCTATAGTATGAGGCTTTCCTCTTAACTTTCAGCAAGATCTGTCTGTTAAATTGGG');
> INSERT INTO `ssgi_test2` VALUES ('TC407210','','','','similar to Cluster: Endonuclease reverse transcriptase; n=1; Bos taurus|Rep: Endonuclease reverse,  partial (15%)','');
> INSERT INTO `ssgi_test2` VALUES ('TC407211','','','','weakly similar to Cluster: PREDICTED: similar to LINE-1 reverse transcriptase homolog; n=1; Canis lupus familiaris|,  partial (10%)','TTGCAGTTTTCTGTGTATAGGTTCTGCATCTGCACATTCAACCAACATGAATGGTATAGTACTGTAGTAT');
> INSERT INTO `ssgi_test2` VALUES ('TC407212','','','','homologue to Cluster: Putative uncharacterized protein; n=1; Borrelia garinii|Rep: Putative uncharacterized,  partial (16%)','CCTGCTCCTTATTGTTATATTTAAAAATCTCCCAGATTCAAGTATCATGTGGAGAAAGAATGGGTAAAGA');
> INSERT INTO `ssgi_test2` VALUES ('TC407213','','','','similar to Cluster: Putative uncharacterized protein; n=1; Lyngbya sp. PCC 8106|Rep: Putative uncharacterized,  partial (3%)','ATCTAAGCCTCTGCCTCCCCGACCTCAGGATTCAGGGGACAAAGCCAGTCCAAACGACTCAGGGGACAAG');
> INSERT INTO `ssgi_test2` VALUES ('TC407214','','','','similar to Cluster: Putative uncharacterized protein; n=1; Pichia stipitis|Rep: Putative uncharacterized,  partial (3%)','AGGCCAGGATTTTTATAATTTACACAGCAATCAGGACTAAAAGGGAAAAGGTTCAGGTTAAAGCCTAACT');

insomma sembra proprio che ad una certa riga (sempre quella) la query venga troncata... tra l'altro in un punto in cui non c'è proprio niente di strano...

Non so che pesci prendere... i sospetti si concentrano sulla fase di download, come se in qualche modo il file "a fresco" non fosse ancora "buono".
Vi riporto il codice di download (il download avviene tramite post perchè, non so per quale motivo l'istituto che rilascia questi dati li ha "nascosti" dietro un post.. non sembra esserci un url direttamente accessibile da cui prendere i dati in GET).

    $ch = curl_init();

    curl_setopt($ch, CURLOPT_URL, $url);
    $output = fopen(DATA_FILE,'wb') or die("controllare i permessi");   
    curl_setopt($ch, CURLOPT_FILE, $output);
    curl_setopt ($ch, CURLOPT_POST, 1);
    $data = array(
            'Download' => 'Download',
            'db' => 'pest',
            'gudb' => 'pig',
            'searchby'=> ''
    );
    curl_setopt ($ch, CURLOPT_POSTFIELDS, $data);
   
    curl_setopt($ch, CURLOPT_HEADER, 0);

    curl_exec($ch);
    curl_close($ch); 

qualche idea?

[piero.mac]

nella prima insert hai 5 campi. Nelle altre ne hai 6.

il perche' lo dovresti sapere tu ....

[}gu|do[z]{®©]

Originariamente inviato da piero.mac
nella prima insert hai 5 campi. Nelle altre ne hai 6.

il perche' lo dovresti sapere tu ....

eh no.. ho scritto proprio per quello.. leggi tutto piero, non sono così fagiano

[piero.mac]

Originariamente inviato da }gu|do[z]{®©
eh no.. ho scritto proprio per quello.. leggi tutto piero, non sono così fagiano

nessun dubbio sul fagiano. Ma se ricevi "Column count doesn't match value count"
significa molto semplicemente che il numero dei campi non corrisponde al numero dei valori inseriti. Se conti nella prima select ci sono 5 campi e presumo vada bene, nelle altre i campi che inserisci sono 6. punto.

edit .. oppure viceversa. quella da 5 e' errata e stoppa l'inserimento

[}gu|do[z]{®©]

Originariamente inviato da piero.mac
nessun dubbio sul fagiano. Ma se ricevi "Column count doesn't match value count"
significa molto semplicemente che il numero dei campi non corrisponde al numero dei valori inseriti.

è questo l'ho detto anche io...

se però leggi vedi che il problema non è quello.. ma ricostruivo semplicemente tutte le analisi e i test fatti per arrivare al problema.. che è quello che non trovo


Per riassumerti, le query le faccio a partire da un file che scarico.. se questo file è già stato scaricato prima (a mano o dallo script stesso) viene tutto inserito... se non è stato scaricato prima, lo script lo scarica ma quando lo importa gli viene troncata quella query... e chiaramente, per il problema che hai detto tu ed anche io, non viene importata... tanto che avevo indagato su eventuali problemi di formattazione interna di quel file che però non sembrano esserci.

Il punto quindi è: perchè le colonne non matchano a file "appena scaricato" e poi matchano se lo stesso codice prova a importare lo stesso file una volta scaricato?

Per favore, leggi tutto

L'unica cosa che ora mi sembra in qualche modo plausibile è che sia un problema di buffering del file che scarico, per cui al momento dell'importazione "a caldo" ancora non è stato scritto tutto, e nell'importazione a freddo invece sì. Però se anche così fosse sarebbe molto curioso che avviene sempre nello stesso punto...

Lunedì (quando avrò una connessione sufficientemente veloce da scaricare i dati) farò qualche altro test... mi sa che ho scordato di mettere un fclose esplicito e questo potrebbe c'entrare col discorso appena fatto vista la grossa dimensione del file... se avete altre idee intanto..

[piero.mac]

Volevo dire che mysql ha ragione perche' gli risulta un campo in meno. Potrebbe essere un problema di buffer? ma anche no se il file e' disponibile.

Non e' che carichi un file come fosse in "streaming" per cui a volte il download non e' sufficientemente veloce... ma mi pare di dire una cavolata. Un file da caricare sul db lo devi scaricare TUTTO, eventualmente verificarlo e poi caricarlo sul db. Non vedo modi alternativi.

l'ideale sarebbe anche fosse certificato almeno con un MD5.

[}gu|do[z]{®©]

purtroppo l'unica verifica che posso fare sul file è forse il numero delle righe (via shell, sennò sta 'na vita ) pechè non so manco la dimensione attes... non c'è proprio nell'header
(mentre dalla pagina da cui lo scarico in effetti ho il numero di record, che non corrispondono esattamente al numero di righe ma dovrebbero esservi legate in odo biunivoco)

Vabbè, comunque grazie a sto post ci ho ragionato meglio sopra mi è venuto in mente sto discorso del buffer e del fclose mancante... ormai sono quasi certo possa essere quello, altrimenti non mi spiegherei la cosa


Lunedì saprò per certo

....mannaggia alle cattive abitudini cui php ti abitua