Deploiement Apache2.2 + Mongrel

Jean-François wrote the following on 12.01.2007 17:12 :

apparaissent lorsqu’on n’utilise pas les contraintes d’intégrité
référentielle.

Voir à ce sujet, l’optimist et le pessimist locking. Peut-être
pas la panacée, je ne suis pas un spécialiste de la question.

Ca ne résoud pas le problème des race-conditions sur les références. Ca
aide beaucoup sur les modifications concurrentes d’un même objet (encore
que cela ne fait que réduire la taille de la fenêtre temporelle pendant
laquelle un accès concurrent n’est pas détectable à un point où en
pratique il est très peu probable qu’on ne le détecte pas :
théoriquement il y a encore un défaut).

Sinon, il faut bien voir que si Rails n’encourage pas l’utilisation
de contraintes d’intégrité référentielle, il ne les interdit pas non
plus.

C’est clair ! Ce n’est pas pour rien que professionnellement je ne fais
que du dev Rails depuis presque un an :slight_smile: Rails est suffisamment souple
pour qu’on contourne très facilement ses limitations à l’aide de
contributions externes ou de “monkey patching” personnels.

Et oui, il y a des manques dans ActiveRecord, comme le
Two-Phase commit distribué (là encore, pas spécialiste).

J’ai eu de longues discussions sur le sujet avec plusieurs personnes
familières du sujet et ce qu’il en sort c’est que :
1/ On est dans des cas où on ne maîtrise pas totalement l’archi (sinon
on aurait fait une seule base). Donc on rentre dans du spécifique.
2/ Il existe souvent des solutions de contournement applicatives (la
conservation de plusieurs versions des objets en base permet souvent
d’éliminer des problèmes solutionnés par le Two-Phase commit).
3/ J’ai des doutes sur le fait que le Two-Phase commit soit sans faille
(à la lecture de la théorie je vois encore une faille au moment de la
deuxième phase de commit, et je n’ai encore jamais rencontré un
spécialiste qui a pu me démontrer que c’était effectivement robuste).

Personnellement le point 1/ fait que je ne me sens pas trop concerné :
mon domaine n’est pas l’intégration mais la conception. Ca peut gêner
d’autres profils que le mien par contre.

Lionel.

Lionel :

référentielle.
Voir à ce sujet, l’optimist et le pessimist locking. Peut-être
pas la panacée, je ne suis pas un spécialiste de la question.

Sinon, il faut bien voir que si Rails n’encourage pas l’utilisation
de contraintes d’intégrité référentielle, il ne les interdit pas non
plus.

Et oui, il y a des manques dans ActiveRecord, comme le
Two-Phase commit distribué (là encore, pas spécialiste).

-- Jean-François.

La philosophie de Rails est de ne pas gérer la fonctionnalité “clé
étrangère” du côté de la base de données, mais du côté de applicatif.

Cependant, tu peux toujours utiliser la méthode “execute” dans ta
migration pour exécuter une commande SQL arbitraire.

Il y a des exemples par ici :
http://wiki.rubyonrails.com/rails/pages/UsingMigrations

++

yk

Richard HALLIER a écrit :

Le jeudi 11 janvier 2007 à 18:31 +0100, Frédéric Logier a écrit :

    +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 :slight_smile:

ça tombe bien, je connais un peu Unix :slight_smile:

Au depart, j’avais attribuer les droits comme ceci :

chmod -R 500 mon_appli
chmod -R 700 mon_appli/log
chmod 555 mon_appli
chmod -R 555 mon_appli/public

Avec cette config de permissions, le serveur me retournait une erreur
500

La seule config de permissions qui a fonctionné dans mon cas est chmod
-R 755 mon_appli

Donc, tout mon repertoire d’application est en 755…je sais bien que
c’est pas terrible mais cela ne fonctionne pas autremant…
Une solution ?