Sto costruendo il motore di backup per Clerk, dovrà esportare la
struttura del db in xml, sql e codice ruby.
Chiaramente il backup non si porta dietro i campi id ma rigenera tutto,
in questo modo è possibile gestire sistemi multisito.
Qualcuno ha creato qualcosa del genere?
Alessandro S. wrote:
Sto costruendo il motore di backup per Clerk, dovrà esportare la
struttura del db in xml, sql e codice ruby.Chiaramente il backup non si porta dietro i campi id ma rigenera tutto,
in questo modo è possibile gestire sistemi multisito.Qualcuno ha creato qualcosa del genere?
Una parte del problema è risolta usando rake db:schema:dump che mette in
db/schema.rb una migrazione che ricostruisce la struttura del db. Non so
se eventuali foreign key sopravvivono, ma ne dubito conoscendo
l’avversione di Rails alla loro definizione.
Il dump dei dati è tutta un’altra storia. Da quel che scrivi immagino
che non usi gli id come foreign key, altrimenti ignorarli sarebbe un
problema.
Personalmente per i backup uso sempre i sistemi di backup interni al db
che uso, PostgreSQL o MySQL che sia. Funzionano da anni e fanno bene il
loro lavoro.
Paolo
Personalmente per i backup uso sempre i sistemi di backup interni al db
che uso, PostgreSQL o MySQL che sia. Funzionano da anni e fanno bene il
loro lavoro.
Il sistema di backup che devo realizzare permette ad esempio di
esportare i dati da un applicazione e importarli in un altra senza
creare problemi di chiavi duplicate, viene in pratica eseguito il dump
degli oggetti e dei loro collegamenti, il processo inverso è quindi la
ricreazione dei dati su db piuttosto che un semplice ripristino
Alessandro S. wrote:
Io userei RDF, che rende facile creare relazioni fra oggetti senza
portarsi appresso id numeriche dipendenti dal DB:
<rdf:RDF
xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:cd=“http://www.example.com/person#”>
<rdf:Description rdf:ID=“Mickey_Mouse”>
person:firstNameMickey</person:name>
person:lastNameMouse</person:lastName>
<person:spouse rdf:resource=“#Minnie_Mouse”>
…
</rdf:Description>
<rdf:Description rdf:ID=“Minnie_Mouse>
person:firstNameMinnie</person:name>
person:lastNameMouse</person:lastName>
<person:spouse rdf:resource=”#Mickey_Mouse">
…
</rdf:Description>
Come puoi vedere, alla fine dei conti puoi considerarlo XML, con poche
regolette in più. Quello che conta è che se un nodo ha un attributo
rdf:ID, puoi creare una relazione usando un attributo rdf:resource. In
ogni caso qualsiasi libreria RDF per Ruby che tu possa usare capisce da
sola questa relazione.
Ciao,
Andrea
2009/8/31 Andrea C. [email protected]:
ricreazione dei dati su db piuttosto che un semplice ripristino
Io userei RDF, che rende facile creare relazioni fra oggetti senza
portarsi appresso id numeriche dipendenti dal DB:
ma si porterebbe dieteo id numeriche provenienti dallo url, che è la
stessa cosa.
Comunque imo se usa la serializzazione N3 o N-TRIPLES di RDF è meglio
che rdfxml:
#Minnie_Mouse person:firstName Minnie.
#Minnie_Mouse person:lastName Mouse.
#Minnie_Mouse person:spouse #Mickey_mouse.
etc
Ma dovrebbe definirsi il vocabolario, e verificare se una libreria per
RDF qualunque in ruby sa gestire volumi di dati grossi.
My 2C: il vecchio plugin ar_fixtures permette di fare un dump in yaml
del db, che p0uò essere ricaricato con i tool standard di rails per le
fixture. Ma secondo me è meglio il dump con i tool del db, usando CSV
(o TSV) l compatibilità è garantita con qualunque cosa.
gabriele renzi wrote:
esportare i dati da un applicazione e importarli in un altra senza
stessa cosa.
Non sono sicuro di capire cosa intendi…
Io il restore lo farei facendo:
Con un minimo di attenzione non rimangono id in giro.
Comunque imo se usa la serializzazione N3 o N-TRIPLES di RDF è meglio
che rdfxml:
#Minnie_Mouse person:firstName Minnie.
#Minnie_Mouse person:lastName Mouse.
#Minnie_Mouse person:spouse #Mickey_mouse.
etc
De gustibus 
Certo è un filo più compatto, ma a parte questo, rdfxml è trattabile con
qualunque tool XML, quindi più flessibile in caso di processamenti
intermedi.
Ma questa è una discussione vecchia quanto RDF, quindi meglio non
entrarci
Ma dovrebbe definirsi il vocabolario, e verificare se una libreria per
RDF qualunque in ruby sa gestire volumi di dati grossi.
Il vocabolario non è un gran problema; basta usare il nome del model
come tipo e il nome dell’attributo come nome del predicato.
ActiveRDF fa così, ad esempio.
Il fatto che le librerie funzionino bene… certo, è tutto da vedere.
Sicuramente le librerie che sono frontend su Jena e/o Redmine non hanno
problemi a riguardo.
My 2C: il vecchio plugin ar_fixtures permette di fare un dump in yaml
del db, che p0uò essere ricaricato con i tool standard di rails per le
fixture. Ma secondo me è meglio il dump con i tool del db, usando CSV
(o TSV) l compatibilità è garantita con qualunque cosa.
Dipende se lo scopo è un backup di cui farai il restore sullo stesso
tipo di DB e sulla stessa istanza di server, oppure un export
“trasportabile”. A me sembra che lui voglia la seconda, per cui la
seconda soluzione non sarebbe applicabile, e la prima ti lega comunque a
rails (che potrebbe non essere un problema).
Andrea
2009/8/31 Andrea C. [email protected]:
Io userei RDF, che rende facile creare relazioni fra oggetti senza
portarsi appresso id numeriche dipendenti dal DB:ma si porterebbe dieteo id numeriche provenienti dallo url, che è la
stessa cosa.Non sono sicuro di capire cosa intendi…
intendevo che se come uri usano lo url si porta probabilemnte dietro
la info del db. Se ha già una chiave univoca e la usa con to_param
allora tanto vale usare cone uri lo url , che però probabilmente avrà
direttamene l’id numerico. Se non usi questa informazione, e usi i
blank node (alla _:1 etc) tanto vale usare gli id numerici del db
penso.
Io il restore lo farei facendo:
- per ogni risorsa creo il model, ignorando i predicate che hanno
riferimenti ad altre risorse- mi salvo in un hash URI → id
- una volta create tutte le risorse, faccio un altro giro e aggiorno i
predicate che hanno riferimenti ad altre risorse
si, ma rimane: che id usi per il nodo?
qualunque tool XML, quindi più flessibile in caso di processamenti
intermedi.
si ma N-TRIPLES è trattabile con File.readlines.map &:split 
Ma questa è una discussione vecchia quanto RDF, quindi meglio non
entrarci
dehe
Ma dovrebbe definirsi il vocabolario, e verificare se una libreria per
RDF qualunque in ruby sa gestire volumi di dati grossi.Il vocabolario non è un gran problema; basta usare il nome del model
come tipo e il nome dell’attributo come nome del predicato.
ActiveRDF fa così, ad esempio.
funziona ancora ActiveRDF? uno degli autori (renaud delbru) lavorava
con me e so per certo che non ci mette mano da due anni, un altro paio
hanno cambiato centro di ricerca e io diffido dei ricercatori
Il fatto che le librerie funzionino bene… certo, è tutto da vedere.
Sicuramente le librerie che sono frontend su Jena e/o Redmine non hanno
problemi a riguardo.
la mia preoccupazione era su com è fatto il wrapping: e.g. se mette
tutto in memoria per semplicità, se ha leak. Ho visto una dozina di
progetti che funzionavano fino a che un input in xml non superava una
certa dimensione per poi collassare perché si tenevano tutto in
memoria invece di fare processing streaming.
My 2C: il vecchio plugin ar_fixtures permette di fare un dump in yaml
del db, che p0uò essere ricaricato con i tool standard di rails per le
fixture. Ma secondo me è meglio il dump con i tool del db, usando CSV
(o TSV) l compatibilità è garantita con qualunque cosa.Dipende se lo scopo è un backup di cui farai il restore sullo stesso
tipo di DB e sulla stessa istanza di server, oppure un export
“trasportabile”. A me sembra che lui voglia la seconda, per cui la
seconda soluzione non sarebbe applicabile, e la prima ti lega comunque a
rails (che potrebbe non essere un problema).
colpa mia che mi esprimo male: suggerivo YAML properio perché si può
ricostruire un oggetto ruby facilmente e poi può farci quel che vuole,
indipendentemente da AR, con il vantaggio che può fare il dump
facilmente.
attualmente pensavo di generare un file .rb (l’applicazione da cui si
esporta/importa/ripristina è sempre la stessa solo che possono essere
diverse istanze su diverse macchine) in cui esplicitare la creazione
degli oggetti, era anche in studio la generazione del xml per creare la
possibilità di esportare i dati su altre applicazioni.
Non avevo pensato al doppio passaggio per rigenerare il db (a cercare di
ottimizzare a volte si finisce per complicare e basta 
) … in
effetti semplifica un sacco le cose, sostituendo i riferimenti a id del
db a dei riferimenti a id xml con due passaggi dovrei poter ricostruire
facilmente tutto il db…!
Grazie del brainstorming!!
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs