Ouverture de session

Commentaires récents

Syndication
Flux XML

Echec de migration vers une base Mysql distante

Echec de migration vers une base Mysql distante
Posté par Roland FRACK le Jeudi, 20 Septembre, 2007 - 2:10pm. Linux/Unix & MacOS X

Bonjour à tous,

Nous rencontrons un petit problème avec Ruby on Rail et MySQL
Nous avons deux postes Mac OS X Tiger en reseau local, poste à poste. Une base MySQL est installée sur l'un des deux postes, et Ruby on Rails est installé sur les deux (avec Locomotive). Nous faisons le même projet sur chacun de nos postes, mais en utilisant le même serveur Mysql.

Notre problème est le suivant : nous avons suivi un tutoriel pour la création d'une application basique de gestion de bibilothèque de CD. Nous définissons la première table dans le fichier "001_create_cds.rb" comme ci dessous :

class CreateCds < ActiveRecord::Migration
def self.up
create_table :cds do |t|
t.column :title, :string
t.column :author, :string
t.column :description, :string
end
end

def self.down
drop_table :cds
end
end

Nous faisons alors un "rake db:migrate" dans le terminal.
Les tables se créent bien, aucun problème.

Mais quant on essaye de faire la même chose depuis l'autre ordinateur, en ayant ecris le MEME fichier et en ayant suivi les même étapes avant, le terminal nous renvoi :

rake aborted!
./db/migrate//001_create_cds.rb:1: syntax error, unexpected ':', expecting '\n' or ';'
endndrop_table :cdsescription, :stringion

Quant on regarde dans la base, grace à phpmyadmin, la première table "shéma_info" à bien été créée pendant cette dernière manip malgré le message d'erreur, mais pas notre table "cds". La base a donc quand même été manifestement atteinte.
Nous avons vérifié, le code est STRICTEMENT identique dans nos deux fichiers .rb.

Il semble donc qu'il faille réaliser une manipulation spécifique pour pouvoir utiliser RoR en liaison avec une base mysql installée sur un autre ordinateur du reseau.
Quelqu'on aurait-il la solution à ce probèlme ?
Merci !



[ Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | sujet précédent | sujet suivant | envoyer par email ]

Options d'affichage des commentaires
Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder" pour activer vos changements.

Sujet: 
Problème résolu...
Auteur: 
Roland FRACK
Date: 
Mar, 02/10/2007 - 08:20

Bonjour à tous.

Merci pour ceux s'étant creusé la cervelle pour résoudre notre problème, nous avons finalement trouvé.

Il s'agit, comme souvent, d'une boulette classique: l'éditeur de texte, avec lequel on codait sur l'ordinateur où la migration ne marchait pas, était apparement mal configuré. Le format de texte devait être mal interpreté. On s'en ait rendu compte quand on a copié le fichier "001_create_cds.rb" d'un ordinateur à l'autre sans le réécire, et que cette fois la migration marchait...Cela explique le message d'erreur comportant des mots bizarres tels que "stringion" qui doivent être le résultat d'une mauvaise interprétation du texte.

Nous utilisons maintenant des éditeur spécialisés (TextMate) et tout marche à merveille.

Désolé de vous avoir fait chercher pour une babiole pareille, mais ça nous a quand même pris du temps pour le résoudre !


[ Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | envoyer par email ]

Sujet: 
Jamais eu ce genre de
Auteur: 
dam5s
Date: 
Jeu, 20/09/2007 - 15:52

Jamais eu ce genre de probleme pourtant notre serveur http de prod est séparé du serveur de la bdd et cela ne pose pas de problème lors des mises en production...

N'hésitez pas à nous montrer vos fichiers database.yml et la migration des fois que le fait d'être la tête dans le problème vous fasse rater qqchose... ca arrive souvent malheureusement et à tout le monde :'(

Damien


[ Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | envoyer par email ]

Sujet: 
Oui effectivement on est
Auteur: 
Roland FRACK
Date: 
Ven, 21/09/2007 - 09:32

Oui effectivement on est jamais à l'abri d'une "boulette" !
Voici nos configuration database.yml (nous ne travailons qu'en mode développement pour l'instant)
Sur l'ordiateur possédant le serveur MySQL :

development:
adapter: mysql
database: cd_development
username: root
password:
socket: /tmp/mysql.sock

Sur l'autre (là où se situe le problème) :

development:
adapter: mysql
database: mesCDs
username: benjamin
password:
hodt: 192.168.0.1

Pour ce dernier nous n'avons créé qu'une seule base, (mesCDs) et pas les trois (dev, test, prod), mais cela ne pose pas de problèmes particuliers n'est-ce pas ?
Sinon, nous n'avons pas bien compris le rôle du socket (mysql.sock), le problèle pourait-il venir de là ?

En tout cas la connexion à la base semble bien se faire, puisque une première table (schema_info, je ne sais pas à quoi elle correspond) à été créée ?

Merci de votre intérêt !


[ Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | envoyer par email ]

Sujet: 
Le fait de ne créer qu'une
Auteur: 
dam5s
Date: 
Ven, 21/09/2007 - 10:24

Le fait de ne créer qu'une base ne change rien effectivement.

Je n'ai jamais utilisé de socket pour me connecter. Vous devriez peut-être essayer d'utiliser tout simplement la variable "host". Sait-on jamais :)

La table schema info est la table qui contient le numéro de la version de la dernière migration effectué. Donc au départ la valeur doit-être zéro. Et à chaque migration vers une version il va partir du numéro de version indiqué par la table schema_info.

Si vous avez fait un copier/coller de la deuxieme config il y a une faute de frappe à hodt. Mais je pense plutôt que c'est en écrivant ici que la faute est parvenu ^^

Je ne vois vraiment pas d'où peut venir l'erreur... à part la connection par socket éventuellement.

Damien


[ Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | envoyer par email ]

Sujet: 
L'ordinateur se connectant
Auteur: 
Roland FRACK
Date: 
Ven, 21/09/2007 - 11:09

L'ordinateur se connectant par le socket est celui où il y a la base, et où on a donc pas de problème. C'est l'autre configuration qui pourrait éventuellement poser problème.

Pour la table schema_info, c'est que vous venez de m'apprendre est interessant puisque cela veux dire que l'application s'est véritablement connecté à la base distante avant d'annoncer l'erreur, et à eu le temps et les droits de creer cette table. Je pense que les paramètres de connexion sont donc bon.

Pour la faute, c'est effectivement une faute de frappe, pardon.

Merci d'avoir pris le temps de me répondre, je vais continuer à chercher.


[ Vous devez vous connecter ou vous enregistrer pour écrire des commentaires | envoyer par email ]

Nouveaux liens

Sondage
Lorsque je développe avec Ruby on Rails c'est principalement sous:
Linux
36%
Mac OS X
30%
Windows
32%
(Free|Open|Net) BSD
1%
Autre...
1%
Nombre de votes: 368

Qui est en ligne
Il y a actuellement 1 utilisateur et 71 invités en ligne.

railsfrance.org - communauté francophone des utilisateurs de Ruby on Rails
[ Hébergement et ressources techniques gracieusement fournis par la SSLL Nuxos Group ]