Calling destroy on a model that has no id column

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.

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

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

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

The finder works though.

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

# 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 = ?")

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

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

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.

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

Lee:

Related, perhaps helpful:

  http://www.ruby-forum.com/topic/208279

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

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,