What is the correct way to delete the records in a Join Table (used to
link two files using habtm).
I have resorted to creating a model for the join table. The table is
called boats_members (as it links two tables called boats and members.
And the model is called boats_member (to allow for rails pluralizing).
This way I can do Boats_member.delete_all which works just fine. (I am
also deleting all the records from the boats and members file prior to
rebuilding the whole thing). Because you do not normally need a model
for a join table I suspect there is a “more correct” way to delete the
records.
I have tried using .clear but that did not delete the records in the
join table. I think what I tried was
b = Boat.find[1]
b.members.clear
but I have deleted the non-working code and I can’t be sure. I’m
pretty sure I tried the .clear after had deleted the records in the
boats and members tables, in case that matters.
I am concerned that if junk remains in the join table it may
accidentally represent an incorrect join between unrelated records -
as well as which the join table might grow to an enormous size if it
cannot be cleared out.
What is the correct way to delete the records in a Join Table (used to
link two files using habtm).
I have resorted to creating a model for the join table. The table is
called boats_members (as it links two tables called boats and members.
And the model is called boats_member (to allow for rails pluralizing).
This way I can do Boats_member.delete_all which works just fine. (I am
also deleting all the records from the boats and members file prior to
rebuilding the whole thing). Because you do not normally need a model
for a join table I suspect there is a “more correct” way to delete the
records.
I have tried using .clear but that did not delete the records in the
join table. I think what I tried was
b = Boat.find[1]
b.members.clear
but I have deleted the non-working code and I can’t be sure. I’m
pretty sure I tried the .clear after had deleted the records in the
boats and members tables, in case that matters.
I am concerned that if junk remains in the join table it may
accidentally represent an incorrect join between unrelated records -
as well as which the join table might grow to an enormous size if it
cannot be cleared out.
Thanks
Probably, you can try out by assinging empty array like
What you’re doing is similar to what one would achieve using has_many
:through. It is arguably superior to HABTM since you do indeed create a
join model for your join table, so you can delete records in a typical
way. There are also other advantages to it, such as being able to store
extra data in the join table. And example would be like so:
class Post < ActiveRecord::Base
has_many :taggings, :dependent => :destroy
has_many :tags, :through => :taggings
emd
class Tag < ActiveRecord::Base
has_many :taggings, :dependent => :destroy
has_many :posts, :though => :taggings
end
class Tagging < ActiveRecord::Base
belongs_to :post
belongs_to :tag
end
So with this setup I could conceivably “tag” Posts, say in a blog type
application. This makes available methods like post.tags and
post.taggings. If I wanted to remove all the tags from a Post I could
use post.taggings.destroy_all. (It’s important not to use
post.tags.destroy_all since that would remove those Tags from every Post
that has them.) But overall you could use Tagging as you would any
other model.
It looks like my problem was using delete_all when I should have used
destroy_all. The distinction is not clear from the Rails API -
surprise, surprise …
speed is irrelevant - I only want to use this a few times while I am
developing the app - I am transferring data from an Access database
and splitting it into relational tables. I need to be able to update
the the latest data when I get the transfer process working properly
(which it now seems to be) and when I am given the latest data
(tomorrow?)
As an aside, you wouldn’t believe the mess the Access database is in -
all in a single table with, for example separate columns for first
child (i.e. young person), second child etc. And I have cobbled
together a rails app to replace most of it in a couple of days. It
would have taken me longer to re-learn how to use Access as I have
only used it a little bit.
This is an app for my own use as I take over the operation of a club
membership system - so no pressure to make it look nice
…Robin
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.