ciao a tutti
mi capita spesso di dover lavorare in locale per aggiornare un sito o implementare nuove funzionalità. così faccio il backup del sito remoto e lo copio in locale.
ora ho due copie identiche, però il sito remoto continua a funzionare, magari il cliente lo usa e ci mette cose nuove, magari si registrano nuovi utenti alla newsletter, ecc.
come fare per poi riportare le modifiche sul sito da locale a remoto senza perdere quello che è cambiato in remoto nel lasso di tempo?
se volessi magari copiare solo i dati (articoli, commenti) ma non il resto, che tabelle devo backupare?
grazie
Mi associo alla domanda di Maurino.
Sto studiando Database Scripts, perche' il quarto spunto:
sembra una buona strada...
Qualcuno ha qualche esperienza da condividere?
John
Più imparo, più dubito.
Non ho ancora una risposta, ma vi aggiorno sulle mie ricerche. Spero che questo fa scattare qualche idea in piu'. Tutto in inglese, purtroppo.
Hell of a problem...
John
Più imparo, più dubito.
Per il momento, la soluzione è scrivere degli script che ripetano le azioni che hai fatto in locale e le riproducano sul server. Altrimenti, ti appunti tutte le modifiche e le riproduci passo passo.
Ciao Pinolo,
Per chi non hai capito - non stiamo parlando della schema, mi sembra di capire che il meccansimo di
.installfa quel lavoro un po' simile a Ruby Migrations, solo che manca il rollback. Quindi bisogna fare un backup del database prima. Correggimi se sbaglio.Il problema (e forza) di Drupal e' che si puo' manipolarlo solo cambiando un gran numero di diciamo proprieta', quale tema, tipi di nodi, editor di testo, la lista e' lungha. Ma questi proprieta' vanno nel database. E anche i dati tipo contenuto del nodo (title e body al minimo). E tanti moduli creano le loro tabelle proprio. E ci sono tanti, ma proprio tanti moduli. Sigh.
Io mi sono avvicinato a Drupal proprio perche' si puo' fare tanto senza programmare una riga di codice,
settings.phpescluso dove (forse) devi cambiare il valore di una variabile.E si. Parliamo di Script SQL presumo - o qualcosa piu' esoterico?. Solo che io non voglio scrivere script a mano. Non sono cosi bravo o ben organizzato. Ma come Maurino ha spiegato, bisogna capire essattamente cosa e' stato cambiato, e poi come replicarlo nel database di produzione.
Il modello che sto pensando, basato su quei riferimenti sopra, e in stile Version Control. E sicuramente una vecchia problema, e non ho visto soluzioni elegante ne' in ambiente Ruby on Rails, ne' con i varie ORM Java - Hibernate, per esempio. Dubito che ci sara' qualcosa in PHP: PDO per Drupal 7. Ma forse c'e' speranza con Drupal, perche' ha delle rigide regole per scrivere codice, accedere al database, ecc.
Certo che si potrebbe anche fare script in PHP, magari interfacciandosi col Drupal, stile Drush, ma non ho trovato niente del genere, e non mi l'aspettavo.
No quello no, ti prego. Adesso mi vuoi non solo organizzato ma anche metodico. Non ho speranza.
Fino ad adesso mi piace l'idea dei autoincrement/sequenze odd/even per staging/produzione o qualcosa di simile. Almeno cosi' non ci possono essere conflitti di identificatori tipo primary key. Per il resto le soluzioni si dividono in tre campi:
Il mio voto (per il momento) va alla seconda categoria...
In tanto ho fatto un po' di pulizia in casa: adesso ho PHPEclipse/Xdebug funzionante, e sto giocerellando con kCachegrind ed il plugin firefox per Xdebug. Cosi' non posso piu' dare la colpa ai tools mancante...
John
Più imparo, più dubito.
Quando parlo di script, parlo di codice che va inserito nel file .install e che viene eseguito tramite update.php.
In pratica, crei un modulo che potresti chiamare "aggiornamenti" e ogni volta che devi riprodurre le modifiche in produzione, programmi un update che riproduca nel database, tramite delle chiamate alla API o tramite query dirette nel DB, le modifiche che hai fatto in locale o sul server di sviluppo.
Installando e aggiornando il modulo, farai girare lo script update.php che implementerà le modifiche.
Non so se tu conosca sistemi più efficienti (anche su altre piattaforme), io che non sono proprio un super-programmatore non ne conosco e cerco di essere metodico quanto possibile. In questo, aiuta molto anche il non fare mega-aggiornamenti, ma lavorare in modo rapido su piccole parti dell'applicazione. In questo modo è molto più facile riprodurre i passi eseguiti.
Grazie della risposta,
Si, potrei indicare qualche potenziale problema nel fare questo, ma penso che le conosce gia' - soprattutto con un progetto open-source, e quindi sempre in movimento. Ma e' sicuramente una soluzione, ed immagino ben testato "in battaglia". Mi piacerebbe sentire la tua opinione piu' e contro questo metodologia.
Si, ci sono solo 24 ore in un giorno, e bisogna pur dormire, almeno un po'. Comunque la domanda innocente di Maurino (ci sei?) mi ha stuzzicato, Fino ad adesso non ho dovuto fare grande cambiamenti, dopo che l'applicazione e' andato in produzione, ma sono sicuro, man mano che i progetti crescono in dimenzione, che quel fatidico giorno arrivera'...
Anche qui, mi sembra che il tuo approccio e' equilibrato. Quante volte, in un team di quattro, ho fatto un commit nel CVS venerdi' pomeriggio, che causava un crash totale sul database (condiviso per l'altro - pessimo idea). Mai piu'. Il venerdi' mi dedico a leggere forum, ponderare domande innocente, e correggere i disastri del commit nel CVS di giovedi' pomeriggio. Almeno cosi' posso godermi il weekend.
Il sistema piu' piacevole per me e' sicuramente Hibernate, perche' astratta completamente gli oggetti dal database. (Si puo' sempre scrivere un po' di SQL, ma 90% del tempo lui lo fa meglio). Da' immenso soddisfazione a creare un oggetto, aggiungere qualche altro oggetto nuovo a questo come figli, poi mandarlo a Hibernate con un bel
persist(oggetto);. Una tecnologia magica, se dimentichi una tonnellata di XML di configurazione per mappare gli oggetti al database, il code injection a livello bytecode, ed altri misteri del mondo Java. Il Java Persistent API sta sempre avvicinando al suo livello.Ma 'pesa' oltre 3MB di codice bytecode, forse 5 MB di codice sorgente Java. E drupal pesa quanto? 2MB di codice sorgente? Va beh, non sara' mai un front end per una banca, ma puo' fare tante altre cose.
Il weekend sta arrivando, quindi ti lascio con l'idea che sto formulando - se c'e' un fallo, fammi sapere, cosi' risparmio tempo.
Vapourware Marketing S.p.A - Gruppo Enron/Lehmann Brothers: Immagini un sistema che registra l'attivita' di modifica del database. Ma solo sul sistema di sviluppo/staging (nel mio piccolo, io combino le due cose insieme). In piu' come un version control, posso fare un tag in un qualunque momento. Dal log dei query, posso tirare fuori tutte le modifiche fatto da un tag al altro, in SQL. Questo poi lo fiondo sul server di produzione, e' se non ho cambiato il file system, sono sicurisimo di avere lo stesso dati anche sul sito produzione. Lo metto volentieri nel tuo file
.installVantaggi:
Svantaggi:
Sembra che non vedo l'ora di infrangere le regole, ma questa volta non vedo alternative. Mi spiego. Per un INSERT, e quasi sicuro che l'identificatore primary key viene generato (auto_increment/sequence) dal RDBMS, ed io devo conoscere quel numerino. Quindi ho bisogno di due 'hook' uno pre_db_query_execute, ed uno post_db_query_execute. Il primo per conoscere la query - e' un INSERT?, la seconda per conoscere l'identificatore usando db_last_insert_id (che non c'e' in D7 fra parentesi).
Ma (c'e' sempre un ma) questi hook non esistono. Devel, che e' nel core, salva l'SQL e basta - dopottutto deve solo visualizzarlo in fondo alla pagina, quindi la soluzione del staging module non basta.
Posso estrare il field giusto chiedendo la metadati dal database (vedi _backup_migrate_get_table_structure_sql).
Se pensi che il ragionamento fila, forse potremmo sviluparlo con le altri qui, su DrupalItalia? Credo che imparero' molto di piu' con l'aiuto di chi, come te, conosce Drupal e $P->H->P meglio di me. Scusa, ma PHP non e' uno dei miei linguaggi preferiti (non chiedermi perche' - OK programmavo in C e C++ - ma oddio i $ e le frecce ->), riesco a leggerlo, ma lo scrivo come scrivo italiano...
Buon weekend
John
Più imparo, più dubito.
E' fallita Vapourware Marketing S.p.A., e con buon motivo...
Ho trovato questo: "The identity crisis in replication". Interessante, specialmente la sezione "Manual identity range management solutions".
Ampliando, se faccio un modulo che gestice le identificatori cosi:
Chi Seed URLprod 0 www.example.com
svil 1 svil.example.com
test 2 test.example.com
Con incremento di 3 in questo caso.
Posso amalgamare i database
prod + test + svilin locale, e spedire indietroprod + svil. Okay, non e' cosi' semplice, ma e' un inizio.Come? Uhm...
SELECT TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'drupal_database' AND EXTRA = 'auto_increment'Vedi http://dev.mysql.com/doc/refman/5.4/en/columns-table.html
+---------------------+-------------+| TABLE_NAME | COLUMN_NAME |
+---------------------+-------------+
| access | aid |
| accesslog | aid |
| actions_aid | aid |
| authmap | aid |
...
| menu_links | mlid |
| node | nid |
| node_revisions | vid |
| permission | pid |
| role | rid |
| term_data | tid |
| term_relation | trid |
| term_synonym | tsid |
| users | uid |
| views_view | vid |
| vocabulary | vid |
+---------------------+-------------+
32 rows in set (0.10 sec)
Poi salvo i record di ogni tabella dove
(tabella.colonna MOD 10) = SEEDOkay, okay, devo tenermi conto delle tabelle secondario - sembra che non usano constraints. Sigh. Hmmm.
C'e' un po' di convenzioni nella nomina delle tabelle.
O faccio l'inverso, cancellando i nodi in
test.http://drupal.org/project/delete_all
http://www.stonemind.net/blog/2009/01/20/headless-drupal-using-drupals-a...
Per tutte le altre tabelle che non hanno identificatori (e quindi faranno collisione) prendo magari l'ultimo nella lista:
prod +svilSe distinguo fra record di configurazione (view, webform) e record di dati (page, story, comment), forse il mecchanismo diventa sufficientemente semplice da implementare.
Niente core hacking. Magari mi basta un hook_boot e un po' di codice 'rubato' da migrate_backup...
Sembra che devo avere comunque una conoscienza 'al di la' di una query. Vediamo.
Fila il ragionamento? Almeno un po'?
John
Più imparo, più dubito.