8
votes

Rails - remplacer la clé primaire sur has_one

J'ai les associations suivantes, je veux fondamentalement, je veux lier via UserID et non l'ID de l'objet.

xxx pré> p>

xxx pré> code> p>

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


3 commentaires

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


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é.


4 Réponses :


0
votes

Si la clé primaire de votre dB n'est pas appelée ID, vous voulez faire quelque chose comme ceci: XXX

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?


1 commentaires

merci, mais mon identifiant est id. Pourtant, pour cette association, je veux utiliser une colonne différente



1
votes
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.

0 commentaires

0
votes

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/


0 commentaires

2
votes

Il y a deux choses en cours ici. Je pense que vous avez commuté le: has_one et: appartient à des déclarations.

Le : appartient_to est livré dans le modèle qui a la clé étrangère. Le : has_one 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 .

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 : has_one ). xxx

alors vous devez ajuster votre : has_one Déclaration: xxx

puis, deuxièmement, une fois que vos relations sont correctement configurées correctement, il n'est pas nécessaire d'attribuer à la fois : user_profile < / code> ou : userid au moment de la création. Soit vous créez un nouveau userProfile et les touches étrangères seront automatiquement correctes, ou vous attribuez un utilisateur userid d'un profil existant.

espère que cela aide cela aide .


0 commentaires