Ciao a tutti...
Vorrei sottoporvi questo piccolo dubbio che mi è venuto!!!
Dovendo aggiornare (sia dal punto di vista grafico che delle funzionalità) uno dei miei siti realizzati con Drupal ho creato sul server una cartella "parallela" nella quale ho copiato il sito, collegandolo ad una copia del mio db. A questo punto ho fatto l'aggiornamento alla versione 6 e ho iniziato a lavorare sul mio sito parallelo, aggiungendo nuovi moduli, rifacendo graficamente tutto il sito ecc...
Il tutto naturalmente lasciando la normale navigazione sul "vecchio" sito.
A questo punto, finito tutto il lavoro dovrei pubblicare il nuovo sito. E qui sorgono i miei dubbi....
Dal momento che sul sito c'è la possibilità di iscriversi dovrò copiare dal db del vecchio sito tutti i nuovi utenti.
Dovrei quindi estrarre le tabelle relative agli utenti, giusto??? Come si chiama??? Ma avendo installato nuovi moduli relativi agli utenti, tipo user relationship, questo potrebbe crearmi dei problemi???
Poi quali altri dati dal vecchio db devo copiare nel nuovo??? Sicuramente i contatti!!! Vi viene in mente altro???
Grazie a tutti!!!
E peggio di quanto pensi. Be very, very afraid: http://www.drupalitalia.org/node/8244
Più imparo, più dubito.
Grazie mille per la risposta JHL!!! Anche se c'ho capito ben poco dal link che mi hai postato...
Dici che è davvero così complessa la faccenda???
Pensavo si potesse fare esportando alcune tabelle dal vecchio db e importarle nel nuovo... tutto tramite il pannello di amministrazione di MySql.
Dici che non potrebbe funzionare così???
Il problema è molto semplice da spiegare quanto difficile da risolvere. E' sei mesi che ci sto dietro con solo parziale successo...
Quindi dato che è semplice - spiego il problema:
Un bel giorno, copiamo il db di produzione in locale per fare aggiornamenti/migliorerie, ecc. Cosi quel fatidico giorno ci troviamo con due db:
prod(sul server) eprod'(in locale). Il tempo passa, gli utenti cambiano data inprod, mentre noi cambiamo dati inprod'. Forse anche la stessa dati (un corpo di un nodo, per esempio).Finito il nostro lavoro, siamo pronti a mettere questi ben collaudati novità in produzione. Quindi dobbiamo:
prod")prodeprod"prod'eprod"Ovviamente il tempo fra 1 e 6 dev'essere molto breve (qualche minuto), altrimenti gli utenti si arabbianno...
Ci sono due scuola di pensieri (o cosi ho capito io) che seguono l'illusivo soluzione a questo problemino; gli db-isti e gli amministratori.
La scuola db-isti dicono che è un problema escusivo del db - quindi cercano soluzioni fra i varie tool del db - che ho citato nel thread precedente.
La scuola amministratori dicono di fare solo modifiche di admin, cioè nuovi viste, cambi di variables, blocchi, ecc. Ma niente cambiamenti ai nodi, commenti, utenti, ecc. Questo si può fare 'registrando' i cambiamenti in codice, non nel db.
Cosi si può trovare soluzione tipo dscripts (prima scuola) o features (seconda scuola).
Io sono più propenso per la prima scuola (ma ci sono dei bei problemi nascosti), ma tengo sempre d'occhio i risultati della seconda scuola - soprattutto features - specialmente dopo i commenti di Pinolo (un Drupalista par excellence) e il talk di Mavimo (altro Drupalista par excellence).
Naturalmente, sono ben disposto ad idee alternativi...Basta che funzionano!
John
Più imparo, più dubito.
Inizio a capirci qualcosina...
Però considera il fatto che i miei utenti possono fare ben poco sul mio sito. Nel senso che oltre che registrarsi, iscriversi alla newsletter, visitrare le pagine, commentare alcuni nodi e inviare mail, non possono fare nient'altro.
Quindi le differenze fra i due ipotetici db prod e prod' dovrebbero essere veramente poche... Migliora la situazione???
Bene. Vuolevo spaventarti un pò, perchè il 'problemino' può essere molto complesso.
Adesso. E domani?
Si, la situazione migliora. Quando fai l'upgrade da sviluppo a produzione (db prod' e prod") bisogna evitare di trasferire le tabelle usati dagli utenti in produzione. Quale sono? Quello devi capire tu.
Ma devi renderti conto che stai costruendo una trappola - per te stesso. Se 'apri' le funzionalità al utente, tipo creare un nodo (potrebbe esserre un forum, o profilo utente avanzato) allora devi aggiustare la lista nera di tabelle da non trasferire svil->prod...
John
Più imparo, più dubito.
Per il momento ho risolto esportando dal vecchio db le tabelle "profile values", "simplynews_subscriptions", "users", "web form submission" e "web form submission date" e importandole nel nuovo db...
Forse non è la soluzione ideale, però almeno non mi ha dato errori e sono riuscito ad aggiornare tutti i nuovi utenti, tutti i nuovi iscritti alle newsletters, tutti i commenti e tutte le mail inviate!!!
Grazie mille comunque John!!! A presto...