Creazione di database

secondo voi qual’è il modo più pulito di aggiungere in un progetto rails un
qualche tipo di task che in modo db-independent crei i DBs indicati in
database.yml ?

On 10/24/06, chiaro scuro [email protected] wrote:

secondo voi qual’è il modo più pulito di aggiungere in un progetto rails un
qualche tipo di task che in modo db-independent crei i DBs indicati in
database.yml ?

Sarebbe già bello avere una maniera “non pulita”… il database più
semplice da maneggiare è probabilmente mysql, e già lì per poter
creare un DB devi prima sapere la login e password di un utente con
sufficienti privilegi.

Perché non ci racconti qual è l’applicazione che hai in mente? Magari
a qualcuno viene in mente una maniera elegante di aggirare il
problema!

M

Grazie Matteo,

vorrei semplicemente semplificare il processo di ‘installazione’ di una
nuova app rails. al momento devi andare a costruirti i db a mano e poi
lanciare le migrations o, peggio, gli script sql.

lo trovo veramente inutile per la maggior parte dei casi che servono a
me.
voglio permettere ad altri a cui passo il mio lavoro di poter scrivere
rake
app_install o qualcosa del genere e averei db già pronti.

dato che si tratta di installazioni non di produzione, anche assumere
uid/pwd vuoti mi andrebbe benissimo.

any idea? l’alternativa ugly che mi viene in mente è fare un rake task con
un grosso case con tutti i db imbottito di chiamate SQL.

On 10/24/06, Matteo V. [email protected] wrote:

[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

: : i’m a miner : : | therubymine.com

On 10/25/06, Matteo V. [email protected] wrote:

un grosso case con tutti i db imbottito di chiamate SQL.

E se uno ha installato più di un RDBMS, tipo ha sia Oracle che Mysql,
ma vuole installare solo su mysql? Io sarei un po’ sospettoso di fare

con capistrano risolvi il problema :wink:


Michele F.
SeeSaw | Another point of view


[email protected]

non essere criptico :slight_smile:
dicci tutto…

On 10/25/06, Michele F. [email protected] wrote:

[email protected]


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

: : i’m a miner : : | therubymine.com

On 10/24/06, chiaro scuro [email protected] wrote:

Grazie Matteo,

vorrei semplicemente semplificare il processo di ‘installazione’ di una
nuova app rails. al momento devi andare a costruirti i db a mano e poi
lanciare le migrations o, peggio, gli script sql.

Capisco…

any idea? l’alternativa ugly che mi viene in mente è fare un rake task con
un grosso case con tutti i db imbottito di chiamate SQL.

E se uno ha installato più di un RDBMS, tipo ha sia Oracle che Mysql,
ma vuole installare solo su mysql? Io sarei un po’ sospettoso di fare
girare un task che mi pastrocchia i database in una maniera non
chiara.

Perché non fai un dialogo? Chiedi all’utente uno uid, password,
adapter e le altre informazioni. Così eviti di tirare a indovinare
(inaffidabile e pericoloso) e hai la possibilità di spiegare
all’utente che cosa il tuo script sta per fare.

Si potrebbe implementare dentro a rake con una sequenza di puts e
gets, ma sarebbe molto più bello farlo sul browser… il controller di
benvenuto verifica se il db è configurato correttamente, altrimenti ti
ridirige su un controller che gestisce la configurazione con una form
html.

Se lo fai sarebbe carino impacchettarlo come plugin!

M

On 10/25/06, chiaro scuro [email protected] wrote:

non essere criptico :slight_smile:
dicci tutto…

non sono criptico, solo di fretta :stuck_out_tongue:
capistrano in 15 secondi:
*è un DSL per fare deploy ad altro ancora

  • puoi definire dei task (deploy, rollback, migrate, nuke_database,
    etc) da far girare in remoto su più macchine
  • puoi definire dei ruoli (application server, DB1, DB2, web server,
    etc)
  • puoi combinare i due punti precedenti in qualcosa del tipo

task :hello_world, :roles => [:db, :app] do
run “echo Hello, $HOSTNAME”
end

ehh molto altro ancora!

per gli impazienti: http://manuals.rubyonrails.com/read/book/17
per i volonterosi: chi mi intervista la prossima settimana?


Michele F.
SeeSaw | Another point of view


[email protected]

Alle 11:02, mercoledì 25 ottobre 2006, chiaro scuro ha scritto:

Michele F.
SeeSaw | Another point of view
http://www.seesaw.it
[email protected]


Questa è la parte di Nitro-Og che mi piaceva di più rispetto a Rails.
Og, che è l’ ORM (Object Relational Mapper) di Nitro (in pratica il
corrispondente di ActiveRecord) parte dalla classe e non dal database.
Se tu hai una classe di oggetti con determinati attribti Og crea
automaticamente la tabella corrispondente nel database (Prima ti crea il
database ecc. ecc.).
Il contrario di ActiveRecord che va invece a leggersi il database e
modella la
classe di conseguenza.
Io l’avevo provato tempo fa e funzionava bene con mysql mentre con
postgresql
non sempre funzionava correttamente, ma era una vecchia versione.
Probabilmente ora funziona meglio.
Ciao
Francesco L.

On 10/25/06, franz [email protected] wrote:


automaticamente la tabella corrispondente nel database (Prima ti crea il
database ecc. ecc.).

il nocciolo del problema è che negli ambineti di produzione generalmente
non hai grant di livello così alto… e se li hai non hai il problema :stuck_out_tongue:


Michele F.
SeeSaw | Another point of view


[email protected]

Il giorno 25/ott/06, alle ore 11:16, Michele F. ha scritto:

il nocciolo del problema è che negli ambineti di produzione
generalmente
non hai grant di livello così alto… e se li hai non hai il
problema :stuck_out_tongue:

Ho come l’impressione che Chiaroscuro si riferisse ad uno scenario
differente. Non penso ricercasse un sistema di deploy per ambienti
prova, staging, produzione e così via. Chiaro, mi sbaglio?

Penso invece cercasse una soluzione per il deploy di applicazione
rails su “ambienti desktop” con un solo comando. Mi spiego: Chiaro ha
un amico, gli da una chiavetta usb e gli dice di eseguire il comando
“rake fa-ti-fa-ben” e … BOM! Il database è generato e webrik è
partito. Forse sbaglio
però.
Se però non mi sbaglio, ritengo che sia una cosa che vada un po’
contro il concetto di deploy classico di web application e pertanto
che sarà difficile scovare una soluzione ready-to-use. Infatti: io
non ho nessuna idea, ma la via indicata da Matteo mi sembra buona.

Ciao
Jacopo


SeeSaw | Another point of view
www.seesaw.it
[email protected]_______________________________________________
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml

On 10/25/06, David W. [email protected] wrote:

*è un DSL per fare …

Senza riferimenti particolari a questo post, percheadesso tutto in Ruby e un “DSL” invece di un API?

per vendere ?!?!?!?!??!
però giuro che capistrano è davvero un DSL !!!
:smiley: me lo ha detto suo papà
http://weblog.jamisbuck.org


Michele F.
SeeSaw | Another point of view


[email protected]

*è un DSL per fare …

Senza riferimenti particolari a questo post, percheadesso tutto in Ruby e un “DSL” invece di un API?


David N. Welton

Linux, Open Source Consulting

On 10/25/06, Michele F. [email protected] wrote:

per gli impazienti: http://manuals.rubyonrails.com/read/book/17

thanks

per i volonterosi: chi mi intervista la prossima settimana?

tu l’hai detto :slight_smile:

ormai sei un bullet point sulla mia todo list

una DSL è una API, ma non tutte le API sono DSL.

ma qui possiamo andare a discutere su dov’è il confine tra API e DSL.
non te lo so dire formalmente, ma quando vedo una DSL la riconosco :slight_smile:

credo sia una differenza stilistica, come quando chiedi cosa sia una
poesia
o cosa sia l’arte.

On 10/25/06, Michele F. [email protected] wrote:

:smiley: me lo ha detto suo papà
http://weblog.jamisbuck.org


Chiaroscuro

: : i’m a miner : : | therubymine.com

Perché le chiamate alle funzioni non hanno più le parentesi.
:wink:
David W. wrote:

 *è un DSL per fare ...

 Senza riferimenti particolari a questo post, perche` adesso tutto
 in
 Ruby e` un "DSL" invece di un API?

Si, l’interpretazione di jacopo è quella corretta :slight_smile:
voglio facilitare al massimo lo scambio di apps tra i developers.

non sia mai che voglia mettere qualcosa veramente in produzione! :wink:

On 10/25/06, Jacopo M. [email protected] wrote:

Il giorno 25/ott/06, alle ore 11:16, Michele F. ha scritto:

Ho come l’impressione che Chiaroscuro si riferisse ad uno scenario
differente. Non penso ricercasse un sistema di deploy per ambienti
prova, staging, produzione e così via. Chiaro, mi sbaglio?

Penso invece cercasse una soluzione per il deploy di applicazione
rails su “ambienti desktop” con un solo comando. Mi spiego: Chiaro ha
un amico, gli da una chiavetta usb e gli dice di eseguire il comando
“rake fa-ti-fa-ben” e … BOM! Il database è generato e webrik è
partito. Forse sbaglio però.

…e usate il flag -W0 per far tacere il maledetto interprete se ha
qualcosa
da ridire :slight_smile:

On 10/25/06, david [email protected] wrote:

 Ruby e` un "DSL" invece di un API?


“Remember, always be yourself. Unless you suck.” - Joss Whedon


Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml


Chiaroscuro

: : i’m a miner : : | therubymine.com

On 10/25/06, chiaro scuro [email protected] wrote:

Si, l’interpretazione di jacopo è quella corretta :slight_smile:
voglio facilitare al massimo lo scambio di apps tra i developers.

non sia mai che voglia mettere qualcosa veramente in produzione! :wink:

il mio mood systemistico mi ha tradito…


Michele F.
SeeSaw | Another point of view


[email protected]

On 10/25/06, chiaro scuro [email protected] wrote:

tu l’hai detto :slight_smile:

ormai sei un bullet point sulla mia todo list

boccaccia… già, l’ho detto :slight_smile:


Michele F.
SeeSaw | Another point of view


[email protected]

On Oct 25, 2006, at 11:38 AM, David W. wrote:

*è un DSL per fare …

Senza riferimenti particolari a questo post, percheadesso tutto in Ruby e un “DSL” invece di un API?

Beh, mica sono sinonimi…


Stefano C.
[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs