Forum: Rails France models commun entre deux projets rails

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
00e465ac55490fb5e1344b29cd35341a?d=identicon&s=25 Emilien Taque (Guest)
on 2009-03-19 18:48
(Received via mailing list)
Bonjour à tous,
Je cherche de la doc et des bonnes pratiques pour le partage des modèles
entre deux projets Rails. Avez-vous ça dans vos favoris, ou un avis sur
le
sujet ?

Merci
Emilien
2d49805fbc99dd2d82935006dd6d675a?d=identicon&s=25 Alban Peignier (Guest)
on 2009-03-19 19:34
(Received via mailing list)
Emilien Taque wrote:

> Je cherche de la doc et des bonnes pratiques pour le partage des modèles
> entre deux projets Rails. Avez-vous ça dans vos favoris, ou un avis sur
> le sujet ?

Bonjour Emilien,

J'ai "croisé" récemment un projet Rails qui utilisait Desert pour cela
(http://github.com/pivotal/desert).
--
Alban Peignier - alban.peignier@free.fr
http://people.tryphon.org/~alban
64cefc5969da4ae702d86c9f26cb8733?d=identicon&s=25 philippe lachaise (Guest)
on 2009-03-19 19:48
(Received via mailing list)
m'semble que les "engines" rescucités dans la 2.3 permettent ça de façon
standard :
http://guides.rubyonrails.org/2_3_release_notes.ht...

(pour les modèles ça demande à être creusé, mais il me semble qu oui...)
00e465ac55490fb5e1344b29cd35341a?d=identicon&s=25 Emilien Taque (Guest)
on 2009-03-20 14:49
(Received via mailing list)
En effet, les Rails Engines semblent faire le boulot, cf railscast  :
http://railscasts.com/episodes/149-rails-engines

Ca reste assez vague sur la manière de synchroniser l'appli "importée"
et le
app/ du plugin, peut-être à coup de rsync ?

2009/3/19 philippe lachaise <philippe.lachaise@gmail.com>
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2009-03-20 16:37
(Received via mailing list)
> Je cherche de la doc et des bonnes pratiques pour le partage des modèles
> entre deux projets Rails. Avez-vous ça dans vos favoris, ou un avis sur le
> sujet ?

Veux-tu partager la base de données en plus des modèles, ou simplement
le code des modèles et des migrations ?

-- Thibaut
00e465ac55490fb5e1344b29cd35341a?d=identicon&s=25 Emilien Taque (Guest)
on 2009-03-20 16:45
(Received via mailing list)
Partager la base de donnée et les modèles, effectivement : je suis dans
le
cas du front-office et du back-office placés sur des serveurs
différents.

2009/3/20 Thibaut Barrère <thibaut.barrere@gmail.com>
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2009-03-20 17:06
(Received via mailing list)
> Partager la base de donnée et les modèles, effectivement : je suis dans le
> cas du front-office et du back-office placés sur des serveurs différents.

Une question se pose: est-ce que tu as la main pour redéployer les
applis en même temps quand le schéma évolue ? Ou es-tu contraint (car
ça coute plus cher) à faire évoluer l'un un jour, puis l'autre
quelques jours plus tard ? (cad nécessité de gérer une phase de
transition, avec les données additionnelles en nullables par exemple)

Dans les deux cas une possibilité (proche de ce que je fais dans un
cas un peu analogue) est d'utiliser le back-office en
"maitre" (référence), et un "piston import" d'un répertoire dédié aux
modèles dans l'autre application.

-- Thibaut
54421c0fe10a968fd36fc1ece7c0b1a0?d=identicon&s=25 JD (Guest)
on 2009-03-20 17:15
(Received via mailing list)
Salut,

Le vendredi 20 mars 2009 à 16:45 +0100, Emilien Taque a écrit :
> Partager la base de donnée et les modèles, effectivement : je suis
> dans le cas du front-office et du back-office placés sur des serveurs
> différents.

J'ai peut-être lu un peu vite les postes mais...

Pourquoi ne pas réunir le front et le back dans la même appli et la
déployer sur les deux serveurs ?
La base ne pourrait-elle pas se trouver sur l'un des deux serveurs et
chaque serveur son database.yml pour pouvoir y accéder (host configuré
local pour l'un et host configuré distant pour l'autre) ?

La différenciation entre back et front (alors que l'appli est la même)
ne pourrait-elle pas se faire soit par fonctionnalité en testant le
hostname (%X(hostname)) quand nécessaire soit par routage en déployant
un routes.rb différents par serveur (ou les deux).

Si besoin, mettre en place un partage nfs entre les deux serveurs ?

Ne serait-il pas facile de mettre cela en place avec capistrano
(obligation de déployer simultanément bien-sur pour rester cohérent) ?

Un seul projet c'est quand même plus facile à maintenir que deux.

L'inconvénient bien-sûr est de ne partager que la base et le code (voir
les fichiers), pas l' espace d'adressage...mais là c'est un autre
problème... erlang ?


J.
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2009-03-20 17:36
(Received via mailing list)
> Pourquoi ne pas réunir le front et le back dans la même appli et la
> déployer sur les deux serveurs ?

Si c'est possible, c'est l'idéal...

-- Thibaut
00e465ac55490fb5e1344b29cd35341a?d=identicon&s=25 Emilien Taque (Guest)
on 2009-03-23 11:30
(Received via mailing list)
Je confirme que ce n'est pas envisageable dans mon cas de réunir les
deux
applis sur un même serveur. Des histoires de certif... Thibaut, comment
as-tu géré le "piston" ?


2009/3/20 Thibaut Barrère <thibaut.barrere@gmail.com>
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2009-03-24 09:59
(Received via mailing list)
Hello,

> Thibaut, comment as-tu géré le "piston" ?

Piston est un outil qui permet d'importer le contenu d'un repository
distant (ex: le repository de ton appli maitre) dans un autre
repository (ex: celui de ton appli secondaire), tout en retenant les
infos (ex: numéro de révision) sur lesquelles tu t'es basé pour faire
cet import.

Tu peux réaliser des "updates" périodiques (réimporter le maitre), les
passer en revue (tests etc) avant commit.

Tu peux voir une intro pour un autre type d'usage sur mon blog:
http://blog.logeek.fr/2008/1/4/how-to-use-piston-t...

Plus d'infos sur le site: http://piston.rubyforge.org/

Nb: la version publique fonctionne avec SVN. Si tu as besoin de SVN +
GIT, voir la version 2.0 dispo sur github:
http://github.com/francois/piston/tree/master

-- Thibaut
00e465ac55490fb5e1344b29cd35341a?d=identicon&s=25 Emilien Taque (Guest)
on 2009-03-24 10:26
(Received via mailing list)
Intéressant, je ne connaissais pas. Merci !

2009/3/24 Thibaut Barrère <thibaut.barrere@gmail.com>
This topic is locked and can not be replied to.