Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
Jérémy :
J’ai vérifié les droits d’accès aux répertoires et fichiers de
l’application et j’en ai profité pour passer l’application en production en
modifiant config/environement.rb en décommentant ENV[‘RAILS_ENV’] ||=
‘production’ (c’est la bonne solution ?)
Non on passe par la variable d’environnement RAILS_ENV=production
ou si on utilise mongrel_rails par l’option -e production.
t’es sûr que t’as donné les bons droits à user=mongrel, group=mongrel ?
РJean-Fran̤ois.
Merci J-F. dans mon cas, j’utilise l’option -e production.
Bon ça marche !!
J’ai pas tout compris, j’ai supprimé les fichiers log/mongrel*.pid et
j’ai faits plusieurs fois:
sudo /etc/init.d/mongrel_cluster stop
sudo /etc/init.d/mongrel_cluster start
En tout cas maintenant mon serveur est opérationnel 
je suis prêt
pour 2007 !
Le jeudi 11 janvier 2007 à 13:56 +0100, Jean-François a écrit :
Ladies & gentlemen,
Désolé si cette question a déjà été posée, mais je voulais savoir comment
faire pour ajouter une contrainte Foreign Key dans une classe migration
?
Ex:
create_table :ecritures do |t|
…
t.column :user_id, :integer, :null => false
end
Puis ici ajouter une insruction pour créer physiquement la contrainte clé
étrangère entre la pk user_id et la table user
Merci
Richard
Commentaires en dessous
heu… je pense que ce serait le pire comportement à avoir
!!! si la base ne le supporte pas, du coup on a une
fonctionnalité qui saute, comme ça, gratuitement ?
La plupart des bases de données sérieuses implementent les contraintes
foreign key, donc les intégrer dans la classe migration, puis à l’execution,
les créer si la base les supportent, ca me paraît pas hallucinant. C’est
quand meme mieux que rien, plutot que de zapper completement la
fonctionnalité, non ?
le check sur les foreign_key est “facile” à faire avec les
outils RoR (notamment les filtres).
Etant nouveau dans le monde RoR, je reconnais pas avoir analysé beaucoup
d’applis, mais pour ce que j’en ai vu, j’ai pas trouvé ton check une seule
fois dans les applis
Curieux …
ce que je trouverais plutot curieux, c’est que la
fonctionnalité n’existe pas nativement dans ActiveRecord, et
qu’il faille passer par des plugins (ou se le coder à la mimine).
Alors là, tout a fait d’accord avec toi !
En reprenant le cas suivant :
create_table :ecritures do |t|
…
t.column :user_id, :integer, :null => false
end
On pourrait imaginer par convention que la migration créé directement la
clef étrangère si la base ciblée la supporte :
user_id, on en déduit la table USER, donc on pourrait générer l’instruction
sql pour créer automatiquement cette contrainte clef étrangère !
Soyons fou, on pourrait aller plus loin et faire sauter la ligne
suivante :
Class Ecriture
belongs_to :user
…
Elle serait déduite de la contrainte clef étrangère ! Meme plus besoin de
coder les relations …
2007/1/11, Jérémy Dierx [email protected]:
Autre question concernant la mise en production :
Actuellement, le repertoire de mon application en production est en chmod
-R 755. Faut-il protéger davantage certains répertoire ou fichier ?
Existe-il des failles de sécurité connues dans mongrel ? dans RoR ?
Bref, comment sécurisé au mieux un serveur apache2+mongrel+RoR ?
déjà donner les droits lecture et execution à tout le monde comme
l’indique
ton 755 c’est moyen. Pour sécuriser il faut donner les droits qu’au
process
Mongrel. Bref faut connaitre un peu Unix 
man chmod
man chown
Richard HALLIER wrote:
http://seb.box.re/articles/2006/07/29/foreign-key-and-rails-migration
Etant l’auteur de cet article je voudrai juste ajouter qu’il faut bien
lire tous les commentaires, il semble y avoir beaucoup d’informations
très utile dedans.
Bonne lecture 
–
Sébastien Grosjean - ZenCocoon
[email protected] - zencocoon.com
Je suis arrivé à la même conclusion à la suite de la lecture de cet article.
Pourquoi ne pas utilisé les proc stoc, les triggers, … ? Pour rendre nos
applis database-independent, c’est un atout technologique non négligeable,
surtout si l’on s’appuie déjà sur un ORM.
Pourquoi utiliser de manière systématique les contraintes clefs étrangères ?
Pour garantir un excellent niveau d’intégrité relationnelle de la base de
données. Combien de fois cela m’est arrivé qu’une vérification de
suppression possible d’une entité soit mal implémentée au niveau code
(surtout sur les delete en cascade) et que cela lève une erreur d’intégrité
au niveau base. Les cas sont nombreux, et je passe les cas
d’accès fortement
concurrenciel, je pense réalistement qu’on ne peut pas faire l’économie des
contraintes clés étrangères.
Bonjour,
Il va te falloir utiliser un plugin pour ça.
Du style : http://www.agilewebdevelopment.com/plugins/araddconstraint
Il y en a d’autres qui tentent de créer automatiquement les clés
étrangères
par exemple :
http://www.agilewebdevelopment.com/plugins/foreign_key_migrations
Je n’ai testé personnellement ni l’un ni l’autre de ces plugins.
Stéphane.
Le 11/01/07, Guillaume B.
[email protected]
a écrit :
Ouuch, quelle mauvaise philosophie … Ca tient pas 2 secondes en
entreprise
ca, pétage de plomb garantie par le DBA.
Là je crois qu’il y a une lacune que je dois pas etre le seul à noter, bon,
pour ceux que ca intéresse, outre les plugins proposés par Stéphane, j’ai
trouvé un lien qui m’a fait descendre ma tension
http://seb.box.re/articles/2006/07/29/foreign-key-and-rails-migration
Il est curieux que n’est rien prévu dans le support de la classe Migration
pour gérer les foreign key, ca me semble pas la mer à boire, surtout que si
la base ne le supporte pas, et bah on le zappe …
Curieux …
Richard
Le jeudi 11 janvier 2007 à 18:52 +0100, Frédéric Logier a écrit :
erreur 500Et je suppose que le propriétaire des fichiers et rep de ton appli est
le même que celui avec lequel tourne mongrel ?
oui :
chown -R mongrel mon_appli
chgrp -R mongrel mon_appli
Bon j’ai trouvé, il faut donner tout les droits au proprietaire
(mongrel) sur le répertoire tmp de manière récursive : chmod -R 700 tmp/
Le reste peu être verrouillé comme expliqué plus haut.
Puis ici ajouter une insruction pour créer physiquement la contrainte clé
étrangère entre la pk user_id et la table user
il me semble que c’est pas possible, car certains SGBD n’ont pas cette
fonctionnalité… le concept de clé étrangère
resterait donc dans “l’intelligence” du modèle.
gUI
–
Pour la santé de votre ordinateur, préférez les logiciels libres !
Guillaume B. : (05 61) 19 40 65 / bureau 602N
2007/1/11, Frédéric Logier [email protected]:
déjà donner les droits lecture et execution à tout le monde comme
l’indique ton 755 c’est moyen. Pour sécuriser il faut donner les droits
qu’au process Mongrel. Bref faut connaitre un peu Unix
en plus ton chmod est récursif, donc tu as rendu executable tous les
fichiers de ton application …
Jean-François wrote the following on 12.01.2007 12:56 :
Je me demande s’il réalise qu’au niveau applicatif il n’a aucun moyen de
se protéger contre la palanquée de “race conditions” entre les
différents processus qui accèdent à la base qui apparaissent lorsqu’on
n’utilise pas les contraintes d’intégrité référentielle.
Je comprends (et même partage son point de vue) sur les procédures
stockées, les triggers, les vues et les clefs composites, mais en ce qui
concerne les contraintes d’intégrité référentielle, je pense que c’est
carrément se tirer une balle dans le pied que de les écarter (d’ailleurs
DHH dit lui-même que c’est la ‘moins-pire’ des fonctionnalités des
SGBDR). J’en veux pour preuve les exceptions renvoyées par une de mes
applis lors d’accès concurrents à la base. Si je n’avais pas mis de
contrainte d’intégrité référentielle, l’exception n’aurait pas été
levée, la référence vers un objet inexistant créée et ma base serait
vérolée au lieu d’avoir une action utilisateur qui échoue
(potentiellement avec un message utilisateur de type ‘accès concurrent :
des données relatives à l’action que vous venez de tenter ont été
modifiées par un autre utilisateur’).
DHH est un excellent concepteur, mais il n’a pas forcément raison sur
tout et apparemment la gestion du parallélisme n’est pas son fort.
Lionel.
2007/1/11, Jérémy Dierx [email protected]:
La seule config de permissions qui a fonctionné dans mon cas est chmod -R
755 mon_appliDonc, tout mon repertoire d’application est en 755…je sais bien que
c’est pas terrible mais cela ne fonctionne pas autremant…
Une solution ?
Et je suppose que le propriétaire des fichiers et rep de ton appli est
le
même que celui avec lequel tourne mongrel ?
Oh my god, c’est du Database Driven Development
Ils ont osé poussés le concept DRY jusqu’au bout, des vrais dingos,
c’est
génial
De : [email protected]
[mailto:[email protected]] De la part de Stéphane
Thibaudeau
Envoyé : vendredi 12 janvier 2007 12:31
À : [email protected]
Objet : Re: [RailsFr][Migration] Foreign Key
Soyons fou, on pourrait aller plus loin et faire sauter la ligne
suivante :
Class Ecriture
belongs_to :user
…
Elle serait déduite de la contrainte clef étrangère ! Meme plus besoin
de
coder les relations …
Certains sont déjà allés plus loin comme tu dis ;o)
Soyons fou, on pourrait aller plus loin et faire sauter la ligne suivante
:Class Ecriture
belongs_to :user
…Elle serait déduite de la contrainte clef étrangère ! Meme plus besoin de
coder les relations …
Certains sont déjà allés plus loin comme tu dis ;o)
Guillaume :
Curieux …
ce que je trouverais plutot curieux, c’est que la fonctionnalité
n’existe pas nativement dans ActiveRecord, et qu’il faille passer
par des plugins (ou se le coder à la mimine).
Pour comprendre pourquoi AR n’implémente pas les contraintes par
défaut, le mieux c’est de lire DHH dans le texte :
http://www.loudthinking.com/arc/000516.html
On peut bien sûr ne pas être d’accord avec son point de vue, et
si on ne le partage pas et qu’on veut cette fonctionnalité, dans
la mesure du possible, on le code soi-même ou on passe par
un plugin codé par une tierce personne.
Donc non, pas de contraintes, pas de procédures stockées,
pas de triggers, pas de vues, pas de clés composites
dans le framework même…
Opiniated software…
РJean-Fran̤ois.
surtout que si la base ne le supporte pas, et bah on le zappe …
heu… je pense que ce serait le pire comportement à avoir !!! si la base
ne le supporte pas, du coup on a une
fonctionnalité qui saute, comme ça, gratuitement ?
le check sur les foreign_key est “facile” à faire avec les outils RoR
(notamment les filtres).
Curieux …
ce que je trouverais plutot curieux, c’est que la fonctionnalité n’existe
pas nativement dans ActiveRecord, et qu’il
faille passer par des plugins (ou se le coder à la mimine).
gUI
–
Pour la santé de votre ordinateur, préférez les logiciels libres !
Guillaume B. : (05 61) 19 40 65 / bureau 602N