Discussion :

[Roland_F]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
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" depuis l'ordinateur où la base est installée, en local donc.
Les tables se créent bien, aucun problème.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
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 !

[titoumimi]

Bonjour et bienvenue

à titre d'information, le fichier config/database.yml est correctement configuré sur les deux postes ?

[Roland_F]

Je pense oui, étant donné qu'une permière table à été créée dans la base. Cela signifie bien que database.yml est configuré correctement je pense?

Quand le fichier est mal configuré, nous avons un message d'erreur concernant la conexion à la base.

Je ne pense donc pas que le problème vienne de là, mais je vous donne quand même les deux codes :

Sur le poste où se trouve la base MySQL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
development:
  adapter: mysql
  database: cd_development
  username: root
  password:
  socket: /tmp/mysql.sock

Sur l'autre poste du reseau (où le problème survient ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
development:
  adapter: mysql
  database: mesCDs
  username: benjamin
  password:
  host: 192.168.0.1

Dans le deuxième cas, nous n'avons créé qu'une seule base, pas les trois (développement, test, production), mais je ne crois pas que cela change beaucoup de choses ?
Une inconnue reste le Socket (mysql.sock) dont je n'ai pas bien compris le rôle ?
Merci de votre intérêt !

[titoumimi]

juste pour confirmer...

Vous utilisez chacun une base différente, bien que stoquée sur le même serveur ?

Sinon, je ne suis pas sûr non plus de l'utilisation de "socket", une IP aurait suffit je pense

Petite question facultative... Le serveur MySQL a été configuré pour autoriser la création de tables depuis un poste "distant" ? (autre que localhost quoi)

[Roland_F]

Oui exactement nous utilisons chacun une base différente, l'une est cd_development, et l'autre mesCDs, toutes deux sur le même serveur mySQL.

Pour le socket, peut-être n'est-ce pas necessaire en effet, mais c'était configuré comme cela par défault...Quand j'ouvre ce fichier dans le terminal, il est cependant totalement vide, et pèse...0 octets...

Pour configurer mySQL, nous avons édité le fichier my.cnf, (/etc/my.cnf) où il fallait apprarement desactiver la ligne skip-networking (mais qui était déjà commentée par défault...) ainsi que la ligne bind-address=127.0.0.1 (qui n'existe pas dans notre fichier...)
Dans tout les cas, une table (schema_info) a été créée, même si la migration à planté. Cela ne prouve-t-il pas que le base est accessible depuis le reseau ?

Merci

[Zfred]

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.

Oui, les 2 manips dont tu as parlé :
- Modifier le fichier database.yml et mettre host: 192.168.0.1 (ip du serveur)
- Commenter la ligne bind-address=127.0.0.1 dans le fichier my.cnf afin que le serveur écoute sur tout le réseau.

Chez moi je n'ai fait que ça pour que ça marche...
Et je n'ai jamais vu ton message d'erreur...étonnant.
Le probleme est ailleurs.
Peut etre les versions de rails, rake ou les gems qui ne sont pas les memes sur les postes...

[Roland_F]

Bonjour à tous.

Merci pour ceux (Titoumimi, Zfred et surement d'autres) s'étant creusé la cervelle pour résoudre notre problème, nous avons finalement trouvé.

Il s'agit, comme souvent, d'une boulette qui, je pense, est 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é, et faisait ainsi planter la migration. 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 !