Forum: Ruby on Rails Using Migrations to convert join table to join model

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
David W. (Guest)
on 2006-04-20 22:02
Greetings,

I'm trying to convert a HABTM w/attributes join table in my database
into a join model table in order to utilize the new has_many :through
functionality introduced in Rails 1.1.  Here's the current table
definition:

licenses_user_groups: license_id, user_group_id, usage_notes

Perhaps it was a mistake, but I made (license_id, user_group_id) the
primary key.

Now, after playing with has_many :through, I have discovered that, among
other modifications, I really need to add an id column to the table and
make it the primary key.  However, I cannot figure out how to use the
SchemaStatements to add the new column, set it to auto-increment, and
then redefine the primary key to be the id column instead of the
(license_id, user_group_id) columns.

I could use the execute statement and use SQL directly, but I would
prefer not to (one of the reasons behind migrations, I thought, was to
provide a DB independent way of creating and modifying schemas; using
SQL directly makes it possible and likely that database specific changes
will be introducted).

Any help (or confirmation that execute is the only way to do what I'm
looking to do) would be appreciated.

Thanks.

David.
David W. (Guest)
on 2006-04-21 00:05
Anyone out there?
Jean-François (Guest)
on 2006-04-21 00:23
(Received via mailing list)
Hello David,

> provide a DB independent way of creating and modifying schemas;
> using
> SQL directly makes it possible and likely that database specific changes
> will be introducted).

Maybe I'm wrong but i don't think it's possible without a direct
SQL execute statement. For me, the primary key is created
during a #create_table call. And there are no methods to suppress
or create a primary key (or I haven't found them yet).

The only way I see : create another table with a primary key id,
transfer the date into it, suppress the old join model table.

Not nice.

The simplest way is the SQL statement...

    -- Jean-François.
Josh S. (Guest)
on 2006-04-21 00:40
Jean-François wrote:
> Maybe I'm wrong but i don't think it's possible without a direct
> SQL execute statement. For me, the primary key is created
> during a #create_table call. And there are no methods to suppress
> or create a primary key (or I haven't found them yet).
>
> The only way I see : create another table with a primary key id,
> transfer the date into it, suppress the old join model table.
>
> Not nice.

Yep, that sounds about right to me.

There's a bug in trac to support this funcitonality. Didn't make it into
1.1, and it's now slated for 1.2.
http://dev.rubyonrails.org/ticket/3735

--
Josh S.
http://blog.hasmanythrough.com
David W. (Guest)
on 2006-04-21 02:25
Josh S. wrote:
Jean-François wrote:

Thanks for your responses; it is what I feared, but at least I can do
what I need to.

Am I just weird?  I can't be the only person running into all of these
has_many :through issues and using migrations to convert a HABTM join
table into a has_many :through join model.  I've also had issues with
migrations not support foreign keys and such; my experiences are making
me feel like a lot of RoR features are rather incomplete.

Like I said, I appreciate the confirmation both of you provided.

David.
Josh S. (Guest)
on 2006-04-21 03:22
David W. wrote:
> Am I just weird?  I can't be the only person running into all of these
> has_many :through issues and using migrations to convert a HABTM join
> table into a has_many :through join model.  I've also had issues with
> migrations not support foreign keys and such; my experiences are making
> me feel like a lot of RoR features are rather incomplete.

:through associations are still a relatively new feature, and there are
some facets that are incomplete. When you run into missing piece, the
best thing you can do is to make sure there is a ticket in trac. Either
create a new ticket, or add any pertinent information that is missing
from an existing ticket. Test cases can help. And if want to submit a
patch (with test cases) to fix the problem, go for it!

I gotta say though, you may be borrowing trouble here. Rather than do
things the "right" way using database agnostic migrations, just do the
simplest thing that will work (without causing you grief later on).

--
Josh S.
http://blog.hasmanythrough.com
This topic is locked and can not be replied to.