# How do you set the DOMESTIC key?

**URL:** <https://www.ruby-forum.com/t/how-do-you-set-the-domestic-key/132679>\
**Category:** Rails\
**Created:** [March 23, 2008, 5:28am UTC](https://www.ruby-forum.com/t/how-do-you-set-the-domestic-key/132679 "2008-03-23T05:28:53Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![David\_H\_Dennis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e68b1a/32.png) [@David\_H\_Dennis](https://www.ruby-forum.com/u/David_H_Dennis)\
**Post date:** [March 23, 2008, 5:28am UTC](https://www.ruby-forum.com/t/how-do-you-set-the-domestic-key/132679/1 "2008-03-23T05:28:53Z")

</div>

The foreign key is the key to use in the OTHER table, usually called  
ID.

The domestic key (my name; I don’t know the right formal term) is the  
key to use in the calling table, usually called nameofothertable\_id ,  
i.e. photo\_id or user\_id.

I have a situation that appears to be surprisingly rare, although I  
would think it would be quite common in businesses with legacy  
tables. Let’s see if I can explain it.

I have a table called users.

It has a field called main\_photo , which is the ID number of the photo  
that is displayed with the user’s profile.

Many moons ago, when I started my project, I had real photos in the  
photos table, and that made the photos table so huge that I would  
never actually want to find the photo within the database. But I  
changed things so that the photos are now stored in the file system,  
because it’s much faster. So now all my photo table has is the  
extension and various sizes, and I would like to pull it up like this:

user = User.find(1, :include =\> :photo)

but I cannot because it’s assuming a field called photo\_id in the  
users table, instead of the actual photo ID in main\_photo.

Now, obviously I could change main\_photo to photo\_id but that would  
require a horrendous testing and debugging cycle, affecting probably  
hundreds of references, particularly since I have a method called  
photo\_id this would conflict directly with.

As far as I know, there’s actually no way to do this, but I figured I  
would ask before giving up. It seems like it should be an easy thing  
to do that someone would have already thought of, but tons of google  
searches have yet to come up with any kind of clue.

Many thanks for any thoughts.

D

---

<div class="post-metadata">

**Author:** ![David\_H\_Dennis](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e68b1a/32.png) [@David\_H\_Dennis](https://www.ruby-forum.com/u/David_H_Dennis)\
**Post date:** [March 23, 2008, 5:59am UTC](https://www.ruby-forum.com/t/how-do-you-set-the-domestic-key/132679/2 "2008-03-23T05:59:21Z")

</div>

On Sat, 2008-03-22 at 21:28 -0700, David H Dennis wrote:

> extension and various sizes, and I would like to pull it up like this:
> 
> As far as I know, there’s actually no way to do this, but I figured I  
> would ask before giving up. It seems like it should be an easy thing  
> to do that someone would have already thought of, but tons of google  
> searches have yet to come up with any kind of clue.
> 
> Many thanks for any thoughts.

* * *

[http://rails.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M001105](http://rails.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M001105)

Normally, you would have in the model…  
Class User \< ActiveRecord::Base  
belongs\_to :main\_photo

and  
Class MainPhoto \< ActiveRecord::Base  
belongs\_to :user

and you would have a field called :main\_photo\_id in users table  
and you would have a field called :user\_id in main\_photos table

This doesn’t require any extra effort.

If you want the field in users table to be called photo\_id, then you  
would have to declare it in User Class…

belongs\_to :main\_photo, :foreign\_key =\> ‘photo\_id’

as described in the above link.

More importantly though, you probably want to use a plugin such as  
‘file\_column’ to manage the links to the picture files and then you can  
just store the file name in your users table and not have a second table  
for this purpose at all.

Craig