Why is my user_id nil?
Asked Answered
R

1

6
def destroy
  @dignity.destroy
end

Sorry, that's not code, that's just how I feel right now. I know there are a ton of beginner questions on Devise, I think I looked at almost every single one.

I have a very simple Devise setup in Rails 3. I did:

rails generate devise User

I'm also running the rails 3 GeoKit plugin,(not sure if that's relevant, just know that I have this other model) so I have another model called Location, and it acts_as_mappable.

Before I post the code, the basic problem is that I cannot seem to get user_id to auto-increment. It was my understanding that a bit of Rails magic should take care of this for me, if I add a column called user_id to Location class. (which I did through a migration.) and then simply set has_many and belongs_to accordingly. (see below)

I can't figure out why user_id is always nil. Does it have something to do with the way the Devise engine works? I am pretty sure I've made this type of association work in the past in the same way when I wasn't using Devise.

user.rb:

class User < ActiveRecord::Base

  has_many :locations

  # Include default devise modules. Others available are:
  # :token_authenticatable, :confirmable, :lockable and :timeoutable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable

  # Setup accessible (or protected) attributes for your model
  attr_accessible :email, :password, :password_confirmation, :remember_me
end

location.rb:

class Location < ActiveRecord::Base
  belongs_to :user


  attr_accessible :street_adress, :city, :state, :zip, :item, :user_id
  acts_as_mappable :auto_geocode => true

  def address
    return "#{self.street_adress}, #{self.city}, #{self.state}, #{self.zip}, #{self.item}"
  end

end

here is the migration that added the column:

class AddUseridToLocation < ActiveRecord::Migration
  def self.up
    add_column :locations, :user_id, :integer
  end

  def self.down
    remove_column :locations, :user_id
  end
end

And finally, here is the schema.rb:

ActiveRecord::Schema.define(:version => 20110213035432) do

  create_table "locations", :force => true do |t|
    t.string   "street_adress"
    t.string   "city"
    t.string   "state"
    t.string   "zip"
    t.float    "lat"
    t.float    "lng"
    t.datetime "created_at"
    t.datetime "updated_at"
    t.string   "item"
    t.integer  "user_id"
  end

  create_table "users", :force => true do |t|
    t.string   "email",                               :default => "", :null => false
    t.string   "encrypted_password",   :limit => 128, :default => "", :null => false
    t.string   "password_salt",                       :default => "", :null => false
    t.string   "reset_password_token"
    t.string   "remember_token"
    t.datetime "remember_created_at"
    t.integer  "sign_in_count",                       :default => 0
    t.datetime "current_sign_in_at"
    t.datetime "last_sign_in_at"
    t.string   "current_sign_in_ip"
    t.string   "last_sign_in_ip"
    t.datetime "created_at"
    t.datetime "updated_at"
  end

  add_index "users", ["email"], :name => "index_users_on_email", :unique => true
  add_index "users", ["reset_password_token"], :name => "index_users_on_reset_password_token", :unique => true

end

EDIT: I'm okay with a RTFM response, as long as I can get a little push in the right direction. I have a suspicion that I need to tell rails something in the create action of my locations_controller.rb ? Someone just give me a little hint here!

Rhyne answered 16/2, 2011 at 1:51 Comment(4)
i should just add that in my location.rb, I added the :user_id on to attr_accessible just trying to get it to work, that's why that's there, if you were wondering...Rhyne
Post the code where you create the locations.Jimmie
Why would user_id in locations table increment? It won't. The id in user table will increment.Lehman
@Lehman You're right, but shouldn't the user_id in locations hold an integer value that corresponds with the id of the user who created the location?Rhyne
S
10
def destroy
  @dignity.destroy
end

Clearly the first thing to be done is:

raise self.esteem

You say you can't get user_id to "autoincrement". I think what you meant is that user_id is not being assigned (i.e. it is always nil). Can you show the part of the code that assigns a location to a user? Either of these should work:

@user.locations.build
@user.locations << Location.new

EDIT

To expand on this a bit, say you have a request that looks like this:

POST /users/37/locations

And the submitted form contains input name=user[location][name] value="Paris". A typical Rails controller create action might look like this:

def create
  @user = User.find(params[:user_id])
  @user.locations.build(params[:user][:location])
  if @user.save
    flash[:notice] = "Location created successfully"
    redirect_to user_locations_path(@user)
  else
    render :new
  end
end

The 'magic' is basically Rails inferring from the has_many statement that it needs to set the value of the foreign key column ('user_id') in the related row in the locations table. When you call @user.save it adds a new row in locations and sets user_id to the value of @user.id.

Supernatant answered 16/2, 2011 at 2:54 Comment(4)
ha! well played, sir. I don't have anything that assigns a location to a user. :| Should what you have posted be in the create action for location? By the way, I'm very new to all of this, not just rails, but coding in general. I'm going to play around with this now, and see what happens. I'm becoming aware that I know a lot less than I thought I did.Rhyne
Knowing that there are things you don't know is an good start. I think Yoda said that. Or maybe Donald Rumsfeld.Supernatant
Thanks buddy! It's going to be a little bit different for my uses, but "build" is the method I was looking for! So that's how the foreign key is assigned. I guess rails is magic, but it can't perform a miracle for me...Rhyne
@location.user = current_user that works too, and makes perfect sense to me, now. because i see what it's actually doingRhyne

© 2022 - 2024 — McMap. All rights reserved.