Bonjour,
bon faire un  crud sur l exmple du blog ok
mais apres qd on a des cardinalites entre table j'suis perdu
ex tt bete une bibliotheque
une table livres une table emprunts une table usagers
 
alors j ai fait mon script sql et j ai donc ma base dans oracle
jusque la ok
deja si je parts comme ca et que j utilise donc pas le db migrate je vais avoir des pbs?
 
apres dans le model je fais 3 classes livre, emprunt et usager avec les cardinalites has_may, belongs_to
 
j ai fait mon controller pour livre qui m affiche les livres et la je voudrais simplement pouvoir cliker sur le livre et afficher sur la meme page le contenu de la table emprun et usager lié a l identifiant de ce livre
mais c'est la que je suis plus...
 
si vous avez du code source sur une application assez simple je suis preneur merci

J'ai strictement rien compris.
Tu peux t'exprimer en français, en expliquant tranquillement et clairement ce qu pose problème, etc..?

Déjà ne pas utiliser les migrations, c'est (très) mal partir. Ensuite Oracle et Rails c'est pas très courant.
 
Pour le reste ça serait quelque chose comme:
@books = Book.find(:all, :joins => :user)
 
Puis il faudrait poster un minimum de code sinon on peut pas aider.

lol alors pour oracle en j ai pas le choix ca m est imposé
 
j ai trouvé find_by_sql qui m aide bien a resoudre mes pbs
 
mais ce qu il me faudrait ca serait les sources d un mini projet genre une connexion admin
ca me permettrait de comprendre vraiment le baba  
ca serait super cool MERKI

find_by_sql ne doit PAS être utilisé, sauf si on fait des choses particulièrement exotiques pour qu'elles ne soient pas supportées par Rails , ce qui n'est absolument pas ton cas.
 
Ensuite, comme l'a dit igarimasho, si tu pars sans utiliser les migrations, t'es déjà très mal barré. Apprend à les utiliser, ça peut être très utile.. Surtout que c'est vraiment pas sorcier.
 
Si j'ai bien compris (mais là c'est limite deviner parce que tu n'as toujours pas expliqué ton problème en français) :
 
Tu as plusieurs livres. Chaque livre correspond à 1 utilisateur mais chaque utilisateur peut avoir plusieurs livres ( relation 1-n  ), idem pour emprunts (un livre peut être emprunté par un seul utilisateur, mais chaque utilisateur peut avoir plusieurs emprunts à son nom) ?
 
C'est ça ?
 

A mes débuts je suis aussi passé par la case find_by_sql et j'ai amèremment regretté. Il faut utiliser Rails dans la manière dont ça a été prévu, sinon aïe.
 
Come exemple de code, tu as Railscasts: c'est simple, clair et ça ne cherche pas à bypasser la magie de Rails.

Heureusement dans mon livre de Rails il y avait bien écrit ça, donc je ne suis pas tombé dans le piège

en gros j essaie de faire un exemple tout bete pour comprendre avec genre une connexion, et sinon pour les tables les cardinalites sont:
 
j ai pas utilisé le db migrate quel est l interet de l utiliser????

donc la ce sont mes models:
 
class Livre < ActiveRecord::Base
  has_many :emprunts
end
 
class Emprunt < ActiveRecord::Base
  belongs_to :livre
  belongs_to :usager
end
 
class Usager < ActiveRecord::Base
  has_many :emprunts
end
 
comme controller:
 
 
class LivresController < ApplicationController
  def index
    @livres = Livre.find(:all)
 end
end
 
et comme view ds le rep livres un index.html:
 
<h1>Listing livres</h1>
 
<table>
  <tr>
    <th>Title</th>
    <th>Body</th>
  </tr>
 
<% for livre in @livres %>
  <tr>
    <td><%=h livre.nom %></td>    
</tr>
<% end %>
</table>

voila mes kestions j en ai des millions lol
mais genre j aimerais lister les usagers ki ont emprunter ce livre?
et j y arrive qu avec  find_by_sql

D'accord on comprend déjà mieux  ... (Même si tu pourrais mettre le code entre balises "code=ruby" pour la coloration)

Donc là ce qui te manque, c'est précisément les foreign keys qui se font très facilement avec les migrations. Prend un manuel de Rails, regarde le chapitre sur les migrations et comment créer des foreign keys (y a un plugin qui peut simplifier la vie ( http://www.redhillonrails.org/fore [...] tions.html ).

Une fois que tout sera en place, tu pourras très simplement afficher ta liste avec :

<% for emprunt in livre.emprunts %>
  <%=h emprunt.usager.nom %>
 <%end%>

Edit : On t'as dit à 2 de ne pas utiliser find_by_sql, qui est la meilleure manière pour démolir ton application en mélangeant présentation,métier et persistance, outre qu'en introduisant des failles potentielles comme des SQL injections.

j ai fait un db migrate sous aptana et on dirait qu il m a rapatrié ma base, j ai desormais un fichier schema.rb qui contient:

j ai desormais une erreur plus encouragente
 
OCIError: ORA-00904: "EMPRUNTS"."LIVRE_ID" : identificateur non valide: SELECT * FROM emprunts WHERE (emprunts.livre_id = 2)

Tu peux nous lire, stp , ce qu'il y a marquer en commentaire avant tout ça? C'est pas marqué qqch du style "DO NOT EDIT THIS FILE" ?
 
Tu peux m'expliquer pourquoi tu ne veux pas écouter des gens qui ont plusieurs développements Rails à leur actif et tu continues à faire tout à ta guise? Parce que si nos remarques/conseils te dérangent, on peut très bien partir de ce topic et te laisser continuer tout seul hein ..

Tu peux nous lire, stp , ce qu'il y a marquer en commentaire avant tout ça? C'est pas marqué qqch du style "DO NOT EDIT THIS FILE" ?  
???
 
euh j essaie des trucs car je suis perdu c'est pas que je veux pas mais je comprends pas tout dsl  

Tu te prends pas du n+1 dans la tête avec cette requête si dans la view tu mets une boucle? Regarde le SQL envoyé. Sinon il faudra que tu ajoutes un :include ou un :joins selon le résultat voulu: livre.nom ou livre.usager.nom
 
Et sinon les noms de variable en français perso je peux pas.
 
Les migrations ça va te forcer à ne pas bricoler la DB à la main, et ça t'évitera te flinguer le serveur de production qui sera totalement désynchronisé de ta machine de dévelopment. Je parle d'expérience personnelle  
 
EDIT: schema.db, LE fichier essentiel sous Rails à ne pas toucher. Expérience personnelle encore    Sinon à chaque migration, Rails va mettre à jour ce fichier tout seul donc c'est normal, mais ne commence pas à jouer avec, c'est "for your eyes only".

 
Premières lignes de mon schemas.rb  
 

 
Donc comme te l'a dit igarimasho => Pas touche. Pour la dernière fois (si tu reviens sans l'avoir fait, je ne peux plus rien pour toi, et tu ne recevras plus d'aide de ma part) prend un livre/tutorial/... de Rails et lit le chapitre sur les migrations. Ton problème peut être résolu en 10 min une fois que tu auras compris comment marchent les migrations et les foreign keys (en plus je t'ai déjà écrit le code )
 
Igarimasho > Pas besoin de join ou include dans ce cas. S'il définit comme il faut les foreign keys dans son fichier de migration et que le modèle est bien configuré (là ça semble correcte), Rails écrira directement la bonne requête quand il appellera le bout de code que j'ai écrit... C'est assez cool parce que une fois que tu as défini les relations entre tes tables, tu te casses plus la tête à savoir ce que tu dois joindre avec quoi, rails s'en occupe..

C'est bon ça. C'est apparu quand? Parce que j'avais pris l'habitude de systématiquement mettre mes propre :joins à cause de ça, sauf que pour gérer les named scope c'est un peu plus pénible du coup.
 
Et Rails insère forçément un :include? Il y a quand même une bonne différence de perf je trouve.

Salut,
Je sais pas depuis quand .. avant le 1.8 en tous cas (c'est là que j'ai commencé à l'utiliser).
 
Donc, j'ai une classe User et Role, qui ont une relation n-n :
 
>> User.find(:all)

 
>> User.find(:first).roles

 
Voilà

Tu veux dire Rails 1.2? La version 1.8 n'a jamais existé sauf pour Ruby
 
Sinon les choses ont changé, parce qu'avant ça crachait une gigantesque jointure avec AS t0_r0, ... AS t1_r1 je sais plus quoi, et c'était ultra lent.
 
Bon ben je vais ré-écrire un peu le code de mes Model avec ça. Merci

1.2 effectivement, sorry
J'espère que l'auteur du topic reviendra et qu'il aura compris comment marchent les migrations

Au fait esox, il y a un named_scope par défaut qui te permet de faire: User.all au lieu de User.find(:all), et idem avec first.
 
Par contre avec User.find(:first).roles, c'est bizarre, pourquoi AR fait un SELECT * FROM users suivi d'une jointure?
 
Il devrait faire 1 requête simple pour trouver le bon user, et à partir du résultat, envoyer le user_id dans une autre requête simple sans jointure. Ou alors faire 1 seule requête avec jointure. Bizarre.

Salut,
 
Comme ça je vois pas trop pourquoi il fait cette requête.. Mais faut dire que je suis pas du tout actif dans le développement de Rails (manque de temps).
 
En ce qui concerne les named scope, je l'ai lu mais je suis pas fan. C'est vrai que c'est plus court, mais je trouve plus facile de m'y retrouver avec le find()

Je crois avoir compris pourquoi il exécute cette requête comme ça
Regarde le temps demandé par chaque requête.. Il exploite le pooling de MySQL, donc en appelant une requête qui, il y a fort à parier, sera utilisé dans la même page (Celle qui prend tous les utilisateurs) il permet à MySQL de rapidiser la requête de jointure .. Et donc au final il n'y perd pas grand chose en perf.

Ouais ça marche sur une petite DB, mais quand elle va grossir, le SELECT * FROM users, il va faire mal.
 
il aurait du faire: SELECT * FROM users WHERE id=1
 
Puis, SELECT * FROM roles WHERE user_id = 1

Tu as tout à fait raison, en fait c'est ma faute, j'ai sorti la mauvaise ligne (je lui avais balancé un User.find(:all)[0] pour voir ce qu'il disait).
Si je fais User.find(:first).roles , il fait un SELECT * from user limit 1

Ok

je regarde par si par la des tutos sur la migration, et je vois un peu comment ca marche mais mon projet futur aura plus d une 20 tables et j ai deja le sql oracle donc j aimerai connaitre le reel interet de creer la base avec la migration plustot que de la rapatrier avec elle?
sachant que de toute facon pour chaque table je vais creer une class dans le modele avec les cardinalite has_many, belongs????
esox_ch... pas taper   prend en compte que je debute vraiment donc faut vraiment me parler simplement et ce qui est evident pour toi ne l est pas du tout pour moi
encore MERCI de votre aide  

Salut,
Donc pourquoi utiliser les migrations ?  
- Parce que ça t'évite de devoir écrire des pages de SQL  
- Parce que lors ce que tu déploies ton site avec Capistrano (l'outil de déploiement) il s'en occupe pour toi.
- Parce que ça rend ton script portable (mes fichiers de migration, que j'utilise avec MySQL, marcheront chez toi, parce que rails les "traduit" en Oracle)
- Parce que ça te permet d'utiliser le plugin dont je parlais plus haut, ce qui t'évitera de faire ce genre d'erreur et te permettra donc d'utiliser le bout de code que je t'ai écrit

en gros c'est pour la portabilité et pour pas etre embetter a cause de nom des foreign key entre autre?
le pb c'est qu on a utilisé dbdesigner qui a géneré l'integralité du code sql oracle donc j ai déja le sql
mais je vais donc faire comme tu m as dit et je vais essayer de le générer via la migration

Tu peux garder tes fichiers SQL si vraiment t'en as envie, mais c'est un peu con parce que c'est beaucoup plus simple avec les migrations..
 
Si t'as d'autres problèmes, n'hésite pas.

Pour ma part, capistrano = beurk. Voir mon post dans le topic blabla@rails
 
Sinon les migrations c'est génial.

Capistrano a du bon, selon moi, si tu as l'impératif d'avoir plusieurs serveur tournant sur exactement la même chose. Dans ce cas c'est effectivement très pratique parce que t'es sur que tout est "bien fait" sur tous les serveurs.
 
Cependant, si tu dois garder à jour 1 seul serveur, là je trouve que ça vaut pas la peine

J'ai commencé à recoder une partie de mes modèles pour en tirer parti, et ça marche super bien  

Tes modèles? Moi c'est dans mes controlleurs que j'utilise ça surtout

Disons que dans mes modèles je créais des custom find avec des :joins histoire de pas saloper mes controlleurs avec trop de code (fat model skinny controller), là du coup j'ai viré ces méthodes j'appelle @article.comments dans mon controlleur (skinny model and skinny controller)

D'accord

<%=h livre.emprunt.usager.nom %>

 

 
Faut bien comprendre ce que t'es en train de faire ... Tu as dit à ActionRecord que Livre possède 1 attribut Emprunt. Donc quand tu tapes livre.emprunt, il va regarder la foreign key nommée emprunt_id dans livre et va te retourner l'emprunt correspondant. Après toi tu veux avoir l'usager correspondant? Bein ça continue de la même manière
 
Edit: Typo

ah lol je venais de trouver lol MERKI qd meme c sympa t as été trop rapide

d

 
Plait-il ? T'as éternué un peu fort?