J'ai les associations suivantes, je veux fondamentalement, je veux lier via UserID et non l'ID de l'objet.
Cependant, la spécification suivante échoue comme twitter_userid est réinitialisée à l'ID de l'objet P>
it "should return the correct avatar after being saved" do
t = Tweet.new(:twitter_id => 1,
:status => 'Tester',
:userid => 'personA',
:user_profile => UserProfile.new(:twitter_userid => 'personA', :avatar => 'abc'))
t.save!
t.user_profile.avatar.should == 'abc'
end
4 Réponses :
Si la clé primaire de votre dB n'est pas appelée ID, vous voulez faire quelque chose comme ceci: Cependant, je ne suis pas sûr de comprendre totalement la question. Y a-t-il une raison pour laquelle vous voulez sortir des conventions des rails? P> p>
merci, mais mon identifiant est id. Pourtant, pour cette association, je veux utiliser une colonne différente
cite@antiope:/tmp/foo$ script/console
Loading development environment (Rails 2.3.4)
>> t = Tweet.new(:twitter_id => 1,
?> :status => 'Tester',
?> :userid => 'personA',
?> :user_profile => UserProfile.new(:twitter_userid => 'personA', :avatar => 'abc'))
=> #<Tweet id: nil, twitter_id: 1, status: "Tester", userid: "personA", created_at: nil, updated_at: nil>
>> Tweet.set_primary_key :userid
=> nil
>> t.save
Tweet Create (0.4ms) INSERT INTO "tweets" ("created_at", "updated_at", "userid", "twitter_id", "status") VALUES('2009-09-10 20:19:36', '2009-09-10 20:19:36', 'personA', 1, 'Tester')
UserProfile Create (0.1ms) INSERT INTO "user_profiles" ("twitter_userid", "created_at", "updated_at", "avatar") VALUES('personA', '2009-09-10 20:19:36', '2009-09-10 20:19:36', 'abc')
=> true
>> Tweet.set_primary_key :id
=> nil
Modfiying the model a split second before saving it might be an acceptable solution if you only have to redefine the primary key in one place (I didn't test if modifying the Tweet class like that affected only the current controller or all actions). Still, it's only what I consider to be a workaround.
Je pense que cela est probablement le moyen le plus pratique. Je ne pense pas que ce soit possible dans les rails autrement: http://compositekeys.rubyforge.org/ P>
Il y a deux choses en cours ici. Je pense que vous avez commuté le: has_one et: appartient à des déclarations.
Le Premier, Vous devrez spécifier (annuler) la clé primaire du modèle. Ici, je suppose qu'un utilisateur peut avoir de nombreux tweets au lieu d'une seule (sinon remplacer par alors vous devez ajuster votre puis, deuxièmement, une fois que vos relations sont correctement configurées correctement, il n'est pas nécessaire d'attribuer à la fois espère que cela aide cela aide . p> p> : appartient_to code> est livré dans le modèle qui a la clé étrangère.
Le : has_one code> est livré dans le modèle qui est renvoyé (s'il n'y en est qu'un, sinon si de nombreuses lignes: appartenir à la même chose, c'est un has_many bien sûr). Pour plus d'informations, lisez ici . P> : has_one code>). P> : has_one code> Déclaration: p> : user_profile < / code> ou : userid code> au moment de la création. Soit vous créez un nouveau userProfile code> et les touches étrangères seront automatiquement correctes, ou vous attribuez un utilisateur userid code> d'un profil existant. P>
Est-ce que "Persona" va dans votre DB?
Cela passe, donc oui c'est: il "devrait sauvegarder" do t = tweet.new (: twitter_id => 1,: statut => 'Tester',: userid => '"Persona' ,: user_profile => userprofile .new (: twitter_userid => 'persona' ,: avatar => 'abc')) T.Save! t.userid.should == 'persona' t.new_record? .should == false t.Valid? .should == vrai t.User_profile.new_record? fin pré>
Y a-t-il une raison pour laquelle vous devez utiliser UserID comme clé étrangère? Pourquoi ne pas simplement utiliser la clé principale du champ associé.