Simone ha scritto:
-> Io non ho accesso al nuovo (vecchio) db con lo storico di tuttui gli uotd del team, quindi non posso convertire i timestamp
e comunque non vorrei distruggere qualcosa... Anche io ci metterei una vita a scrivere una query che modifica il campo della data...
in ogni caso ne ho già creata una copia per sicurezza
-> Questione screenshot: creare dinamicamente un'immagine da html, a quanto sono riuscito a capire oggi, è abbastanza impossibile... bisogna installare programmi o librerie sul server e non mi pare il caso... Proporrei invece di salvare sul server le pagine uotd.php (esempio questa www.ufluids.net/uotd.php) dei vari progetti (4KB di dati) per i soli utenti di boinc.italy. Non avremmo l'immagine jpg, ma il sorgente html della pagina. Questo è sicuramente più fattibile dell'immagine. Se volete (= se serve) domani posso provare a scrivere una funzioncina che fa questo lavoro salvando css e immagine.
Non credo abbia senso memorizzare il sorgente html della pagina perché nel tempo i riferimenti a testi, immagini o altro possono cambiare alterando il risultato finale.
Lo screenshot è (era) una sorta di "prova" dell'elezione che però ora non serve a questo scopo dato che l'elezione è rilevata automaticamente dal tuo codice. Rimane come ricordo di un evento e possiamo lasciare ai singoli utenti la scelta se farlo o meno, postandolo sul forum.. che ne dite?
-> Gli user_id mi servono per caricare l'immagine del profilo. Mettere un numero a caso non mi pare il caso... lasciamo lo zero e metto giù 2 righe di codice che toglie questi 3 casi...
OK
-> Riguardo il tuo dubbio amletico, se si vuole, dato che il parametro più costante è il cpid, si può aggiornare ad adesso il cpid di tutti gli uotd vecchi così compariranno come uno stesso utente nelle statistiche... Però il problema si ripresenta quando uno cambia cpid: come uniamo i due cpid diversi?????? Ma perchè il cpid cambia????? Come fanno boinstats et alii ad aggiornare il cpid???
Credo che per i siti di statistiche il problema non sussista. Per ogni progetto ho un solo nick, un solo user_id e un solo CPID. Posso estrarre i dati aggregati attuali per ognuno di questi tre valori e i risultati possono anche essere diversi.
Qui invece si memorizzano i valori ad ogni singola elezione e questi valori possono variare nel tempo. E' difficile aggregare i dati se questi variano. Bisognerebbe fare ogni volta il controllo a ritroso: se in passato il CPID era diverso per quel user_ID, che non cambia, allora si modifica anche il CPID. Ma la vedo rognosa come cosa (se poi un utente si re-iscrive con uno user_ID diverso addio...)
NOTA BENE: Teniamo le due tabelle divise vero?? Evitiamo tanti problemi così... E' inutile attaccarle assieme che poi devo modificare tutte le mie query...
E' questo il punto.
Se le uniamo diventa tutto più uniforme e nelle tue query va posto solo un limite di data per le classifiche, tranne quella interna (una rottura certo, ma non credo sia così grave).
Se le teniamo separate abbiamo una sorta di doppione e se si lasciano troppe cose da fare a mano c'è il rischio che con il tempo nessuno segua più la cosa.
Credo vada trovata una soluzione intermedia, ma non so bene quale. Sicuramente un codice unico