Calling destroy on a model that has no id column

rubyonrails-talk
1

I've got a model, Favorite, that I'm trying to remove from the database by calling the destroy method on it. What's noteworthy about this model is that it doesn't have an id column. The unique index on the Favorites table is a both the user_id and the article_id. A favorite belongs to a user and an article.

So in my destroy method of my Favorites Controller, I first retrieve the favorite to delete:

favorite = Favorite.find_by_article_id_and_user_id(params[:id], @current_user.id)

Then I call favorite.destroy and I notice this in the log:

"DELETE FROM favorites where id = NULL"

So the delete doesn't actually work. What gives? Do I HAVE to have an id column in the favorites table? Thanks for any help.

2

what's content of params[:id], why not use favorite_id;

3

params[:id] is the incoming article_id....the dynamic finder tells you that too.

And again, the favorites table does not have an id column...the unique key is user-article. That's why I didn't put an id column on the table.

Maybe this is one of scenarios where you just don't fight conventions...

4

i think rails must be use table's id colunm.

5

The finder works though.

It looks like destroy relies specifically on the id column...maybe there's a way to tell it otherwise?

6

# File rails-2.3.2/activerecord/lib/active_record/base.rb, line 2576 2576: def destroy 2577: unless new_record? 2578: connection.delete( 2579: "DELETE FROM #{self.class.quoted_table_name} " + 2580: "WHERE #{connection.quote_column_name(self.class.primary_key)} = #{quoted_id}", 2581: "#{self.class.name} Destroy" 2582: ) 2583: end 2584: 2585: freeze 2586: end

i think <agile rails 3rd> could help you about primary key and id.

otherwise: you can use DBI. ActiveRecord::Base.connection().execute( "delete from table_name where id = ?")

7

If you want Rails to support composite primary keys you need to install a gem. Here's the projects github page: http://github.com/drnic/composite_primary_keys

8

If this is not a legacy table I would recommend adding the ID column and make it your primary key. It will simplify things. You could still have a unique key on article and user that you can use to your hearts content. If that's the way you are going I would add an index on those 2 columns since I'm guessing you would be doing most of your DB access using those fields.

One benefit of adding the ID would show up if you create a child table that depends on FAVORITES. You would add a field called 'favority_id' on the child table and use 'has_*' and 'belongs_to' and everything would be handled for you by Rails.

pepe

9

Thanks for the help guys.

pepe, this is not a legacy table so I think I'm just going to add the id and not fight conventions. The table is really just a link table...linking a user to an article and calling it a favorite. Nothing more...and that's why I went with the composite key.

At least I know this could work with a gem though. Thanks again.

10

Thanks for the help guys.

pepe, this is not a legacy table so I think I'm just going to add the id and not fight conventions. The table is really just a link table...linking a user to an article and calling it a favorite. Nothing more...and that's why I went with the composite key.

At least I know this could work with a gem though. Thanks again.

or if it is just destroying that's a problem you could just add a method that runs

delete from favourites where user_id = x AND article_id = y

Fred

11

Lee:

Related, perhaps helpful:

  Why is ActiveRecord tying to select nonex ID column? - Rails - Ruby-Forum

You've arrived at the same conclusion: Rails expects an id field, and we all know that you can't fight Rails convention. But don't overlook all the goodies you get by declaring :has_many :through.

- ff

12

Lee Smith wrote:

Thanks for the help guys.

pepe, this is not a legacy table so I think I'm just going to add the id and not fight conventions. The table is really just a link table...linking a user to an article and calling it a favorite. Nothing more...and that's why I went with the composite key.

Seems reasonable. I've used composite_primary_keys and it works very well. I don't think you need to add the id in this case.

At least I know this could work with a gem though. Thanks again.

Best,