141
3
true
2009-02-26T16:24:56+00:00
47440
2009-08-31T00:00:00+01:00
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
11
8994
committed
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-09-27T18:15:48+01:00
71184
tsenart
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
Join tables for has_and_belongs_to_many relationships are not supposed to have primary keys. This is mentioned in a few places in the documentation, but remains an easy "gotcha". Unless you know this rule, you can create several habtm relationships before the process eventually fails in a cryptic manner. It's very likely that your tests will not catch this, since it does not fail right away.
The database eventually chokes on duplicate primary keys. The root cause of the problem is that, excluding foreign keys, ActiveRecord attempts to copy values from the associated table into the join table for any columns that the two tables have in common. If you leave the primary key in your join table, 'id' is usually one of those columns.
I've attached a patch with my solution, which includes full testing for all of my changes. When you attempt to create a habtm association, an exception is raised if the join table contains a primary key. This means it will fail right away, loudly, and with a clear explanation of the problem. The exception class raised is ActiveRecord::ConfigurationError, and the message is:
"Primary key is not allowed in a has_and_belongs_to_many join table (table_name)."
In order to create this solution, I had to create a unified way for the various connection adapters to return a primary key, even for tables that are not connected directly to an ActiveRecord model. This is usually the case with basic join tables. sqlite's adapter has a primary_key(table_name) method, which I mimicked in the mysql and postgresql adapters.
In order to handle new adapters gracefully, I created a supports_primary_key? method in AbstractAdapter (similar to supports_migrations?) that returns false. It is then overridden in the specific connection adapters (mysql, sqlite, and postgresql at this time) to return true, since those adapters now have a primary_key method that accepts a table name and returns the primary key. The primary_key method returns nil if there is no primary key for that table.
This patch replaces my earlier attempt to solve the problem in lighthouse ticket #2068. That patch made it possible to *keep* primary keys in your join tables and eliminated the db failure. But I have since learned this is not the solution the community wants.
Join tables for has_and_belongs_to_many relationships are not supposed to have primary keys. This is mentioned in a few places in the documentation, but remains an easy "gotcha". Unless you know this rule, you can create several habtm relationships before the process eventually fails in a cryptic manner. It's very likely that your tests will not catch this, since it does not fail right away.
The database eventually chokes on duplicate primary keys. The root cause of the problem is that, excluding foreign keys, ActiveRecord attempts to copy values from the associated table into the join table for any columns that the two tables have in common. If you leave the primary key in your join table, 'id' is usually one of those columns.
I've attached a patch with my solution, which includes full testing for all of my changes. When you attempt to create a habtm association, an exception is raised if the join table contains a primary key. This means it will fail right away, loudly, and with a clear explanation of the problem. The exception class raised is ActiveRecord::ConfigurationError, and the message is:
"Primary key is not allowed in a has_and_belongs_to_many join table (table_name)."
In order to create this solution, I had to create a unified way for the various connection adapters to return a primary key, even for tables that are not connected directly to an ActiveRecord model. This is usually the case with basic join tables. sqlite's adapter has a primary_key(table_name) method, which I mimicked in the mysql and postgresql adapters.
In order to handle new adapters gracefully, I created a supports_primary_key? method in AbstractAdapter (similar to supports_migrations?) that returns false. It is then overridden in the specific connection adapters (mysql, sqlite, and postgresql at this time) to return true, since those adapters now have a primary_key method that accepts a table name and returns the primary key. The primary_key method returns nil if there is no primary key for that table.
This patch replaces my earlier attempt to solve the problem in lighthouse ticket #2068. That patch made it possible to *keep* primary keys in your join tables and eliminated the db failure. But I have since learned this is not the solution the community wants.
<div><p>Join tables for has_and_belongs_to_many relationships are not
supposed to have primary keys. This is mentioned in a few places in
the documentation, but remains an easy "gotcha". Unless you know
this rule, you can create several habtm relationships before the
process eventually fails in a cryptic manner. It's very likely that
your tests will not catch this, since it does not fail right
away.</p>
<p>The database eventually chokes on duplicate primary keys. The
root cause of the problem is that, excluding foreign keys,
ActiveRecord attempts to copy values from the associated table into
the join table for any columns that the two tables have in common.
If you leave the primary key in your join table, 'id' is usually
one of those columns.</p>
<p>I've attached a patch with my solution, which includes full
testing for all of my changes. When you attempt to create a habtm
association, an exception is raised if the join table contains a
primary key. This means it will fail right away, loudly, and with a
clear explanation of the problem. The exception class raised is
ActiveRecord::ConfigurationError, and the message is:</p>
<p>"Primary key is not allowed in a has_and_belongs_to_many join
table (table_name)."</p>
<p>In order to create this solution, I had to create a unified way
for the various connection adapters to return a primary key, even
for tables that are not connected directly to an ActiveRecord
model. This is usually the case with basic join tables. sqlite's
adapter has a primary_key(table_name) method, which I mimicked in
the mysql and postgresql adapters.</p>
<p>In order to handle new adapters gracefully, I created a
supports_primary_key? method in AbstractAdapter (similar to
supports_migrations?) that returns false. It is then overridden in
the specific connection adapters (mysql, sqlite, and postgresql at
this time) to return true, since those adapters now have a
primary_key method that accepts a table name and returns the
primary key. The primary_key method returns nil if there is no
primary key for that table.</p>
<p>This patch replaces my earlier attempt to solve the problem in
lighthouse ticket <a href="/projects/8994/tickets/2068" title="Ticket #2068">#2068</a>. That patch made it possible to
<em>keep</em> primary keys in your join tables and eliminated the
db failure. But I have since learned this is not the solution the
community wants.</p></div>
0
Join tables for has_and_belongs_to_many relationships are not supposed to have primary keys. This is mentioned in a few places in the documentation, but remains an easy "gotcha". Unless you know this rule, you can create several habtm relationships before the process eventually fails in a cryptic manner. It's very likely that your tests will not catch this, since it does not fail right away.
The database eventually chokes on duplicate primary keys. The root cause of the problem is that, excluding foreign keys, ActiveRecord attempts to copy values from the associated table into the join table for any columns that the two tables have in common. If you leave the primary key in your join table, 'id' is usually one of those columns.
I've attached a patch with my solution, which includes full testing for all of my changes. When you attempt to create a habtm association, an exception is raised if the join table contains a primary key. This means it will fail right away, loudly, and with a clear explanation of the problem. The exception class raised is ActiveRecord::ConfigurationError, and the message is:
"Primary key is not allowed in a has_and_belongs_to_many join table (table_name)."
In order to create this solution, I had to create a unified way for the various connection adapters to return a primary key, even for tables that are not connected directly to an ActiveRecord model. This is usually the case with basic join tables. sqlite's adapter has a primary_key(table_name) method, which I mimicked in the mysql and postgresql adapters.
In order to handle new adapters gracefully, I created a supports_primary_key? method in AbstractAdapter (similar to supports_migrations?) that returns false. It is then overridden in the specific connection adapters (mysql, sqlite, and postgresql at this time) to return true, since those adapters now have a primary_key method that accepts a table name and returns the primary key. The primary_key method returns nil if there is no primary key for that table.
This patch replaces my earlier attempt to solve the problem in lighthouse ticket #2068. That patch made it possible to *keep* primary keys in your join tables and eliminated the db failure. But I have since learned this is not the solution the community wants.
<div><p>Join tables for has_and_belongs_to_many relationships are not
supposed to have primary keys. This is mentioned in a few places in
the documentation, but remains an easy "gotcha". Unless you know
this rule, you can create several habtm relationships before the
process eventually fails in a cryptic manner. It's very likely that
your tests will not catch this, since it does not fail right
away.</p>
<p>The database eventually chokes on duplicate primary keys. The
root cause of the problem is that, excluding foreign keys,
ActiveRecord attempts to copy values from the associated table into
the join table for any columns that the two tables have in common.
If you leave the primary key in your join table, 'id' is usually
one of those columns.</p>
<p>I've attached a patch with my solution, which includes full
testing for all of my changes. When you attempt to create a habtm
association, an exception is raised if the join table contains a
primary key. This means it will fail right away, loudly, and with a
clear explanation of the problem. The exception class raised is
ActiveRecord::ConfigurationError, and the message is:</p>
<p>"Primary key is not allowed in a has_and_belongs_to_many join
table (table_name)."</p>
<p>In order to create this solution, I had to create a unified way
for the various connection adapters to return a primary key, even
for tables that are not connected directly to an ActiveRecord
model. This is usually the case with basic join tables. sqlite's
adapter has a primary_key(table_name) method, which I mimicked in
the mysql and postgresql adapters.</p>
<p>In order to handle new adapters gracefully, I created a
supports_primary_key? method in AbstractAdapter (similar to
supports_migrations?) that returns false. It is then overridden in
the specific connection adapters (mysql, sqlite, and postgresql at
this time) to return true, since those adapters now have a
primary_key method that accepts a table name and returns the
primary key. The primary_key method returns nil if there is no
primary key for that table.</p>
<p>This patch replaces my earlier attempt to solve the problem in
lighthouse ticket <a href="/projects/8994/tickets/2068" title="Ticket #2068">#2068</a>. That patch made it possible to
<em>keep</em> primary keys in your join tables and eliminated the
db failure. But I have since learned this is not the solution the
community wants.</p></div>
false
2009-02-26T16:24:57+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
[PATCH] Primary key on HABTM join table now raises an exception
2009-02-26T16:24:59+00:00
47440
Jaime Bellmyer
Jaime Bellmyer
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
1
Looks like a good well thought-out patch to me. Passes tests, seems like an elegant solution. +1 from me.
<div><p>Looks like a good well thought-out patch to me. Passes tests,
seems like an elegant solution. +1 from me.</p></div>
false
2009-02-26T23:37:35+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
[PATCH] Primary key on HABTM join table now raises an exception
2009-02-26T23:37:38+00:00
9830
RSL
Jaime Bellmyer
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
1
This is a nice enhancement that should let us avoid some horribly confusing errors, nice change.
However I'm wondering why you only did the check on insert_record. Reading from the association would cause surprises too
<div><p>This is a nice enhancement that should let us avoid some
horribly confusing errors, nice change.</p>
<p>However I'm wondering why you only did the check on
insert_record. Reading from the association would cause surprises
too</p></div>
false
2009-03-02T05:30:21+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
[PATCH] Primary key on HABTM join table now raises an exception
2009-03-02T05:30:23+00:00
141
Michael Koziarski
Jaime Bellmyer
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
1
Thanks for the feedback! @Michael: I picked the best single point of failure, in my opinion. Creating is where the error occurs, and raising an exception on create means the database will never be corrupted in the first place.
Of course, I'm open to suggestions if you or anyone else really thinks this aspect should be changed.
<div><p>Thanks for the feedback! @Michael: I picked the best single
point of failure, in my opinion. Creating is where the error
occurs, and raising an exception on create means the database will
never be corrupted in the first place.</p>
<p>Of course, I'm open to suggestions if you or anyone else really
thinks this aspect should be changed.</p></div>
false
2009-03-02T06:48:09+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
[PATCH] Primary key on HABTM join table now raises an exception
2009-03-02T06:48:12+00:00
47440
Jaime Bellmyer
Jaime Bellmyer
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
1
On insert seems good enough to me. How could you allready have data in it? If you do, then you have got more serious problems then this patch will solve for you.
Also if you did it differently, it would probably mean you will be validating all has_and_belongs_to_many relationships on every access, which would not be acceptable. +1 for this one.
<div><p>On insert seems good enough to me. How could you allready have
data in it? If you do, then you have got more serious problems then
this patch will solve for you.</p>
<p>Also if you did it differently, it would probably mean you will
be validating all has_and_belongs_to_many relationships on every
access, which would not be acceptable. +1 for this one.</p></div>
false
2009-03-03T23:29:07+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
[PATCH] Primary key on HABTM join table now raises an exception
2009-03-03T23:29:12+00:00
5639
Bart ten Brinke
Jaime Bellmyer
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
1
On insert seems good enough to me. How could you allready have data in it? If you do, then you have got more serious problems then this patch will solve for you.
Also if you did it differently, it would probably mean you will be validating all has_and_belongs_to_many relationships on every access, which would not be acceptable. +1 for this one.
<div><p>On insert seems good enough to me. How could you allready have
data in it? If you do, then you have got more serious problems then
this patch will solve for you.</p>
<p>Also if you did it differently, it would probably mean you will
be validating all has_and_belongs_to_many relationships on every
access, which would not be acceptable. +1 for this one.</p></div>
false
2009-03-03T23:29:28+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
[PATCH] Primary key on HABTM join table now raises an exception
2009-03-03T23:29:34+00:00
5639
Bart ten Brinke
Jaime Bellmyer
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
141
1
false
2009-03-08T15:48:01+00:00
47440
---
:assigned_user:
:title: "[PATCH] Primary key on HABTM join table now raises an exception"
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-03-08T15:48:07+00:00
1366
Pratik
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
141
1
This patch doesn't seem to apply cleanly any more, but also it occurs to me that it could be worthwhile to cache the results of this test so we don't degrade performance for everyone's inserts?
Or perhaps have this test only fire in development mode? Or do all the adapters cache the results of the primary_key calls?
<div><p>This patch doesn't seem to apply cleanly any more, but also it
occurs to me that it could be worthwhile to cache the results of
this test so we don't degrade performance for everyone's
inserts?<br></p>
<p>Or perhaps have this test only fire in development mode? Or do
all the adapters cache the results of the primary_key calls?</p></div>
false
2009-03-09T07:49:00+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-03-09T07:49:04+00:00
141
Michael Koziarski
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
141
1
I've rebased, and attached the updated patch file, patch-2086b.diff. I'll look into caching today, but I wanted to correct the conflict right away.
<div><p>I've rebased, and attached the updated patch file,
patch-2086b.diff. I'll look into caching today, but I wanted to
correct the conflict right away.</p></div>
false
2009-03-09T15:39:29+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-03-09T15:39:32+00:00
47440
Jaime Bellmyer
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
141
2
The results of the primary key check are now cached, to save processing time on subsequent inserts. I also added a test which verifies this behavior. I moved the check itself out of insert_record, and into its own has_primary_key? instance method, with result caching:
@@@ ruby
# activerecord/lib/active_record/associations/has_and_belongs_to_many_association.rb
def has_primary_key?
return @has_primary_key unless @has_primary_key.nil?
@has_primary_key = (ActiveRecord::Base.connection.supports_primary_key? &&
ActiveRecord::Base.connection.primary_key(@reflection.options[:join_table]))
end
@@@
The insert_record method now calls this new method:
@@@ ruby
# activerecord/lib/active_record/associations/has_and_belongs_to_many_association.rb
def insert_record(record, force = true, validate = true)
if has_primary_key?
raise ActiveRecord::ConfigurationError,
"Primary key is not allowed in a has_and_belongs_to_many join table (#{@reflection.options[:join_table]})."
end
# ...
end
@@@
Finally, the test (based on a join table that DOES contain a primary key):
@@@ ruby
# activerecord/test/cases/associations/habtm_join_table_test.rb
def test_should_cache_result_of_primary_key_check
if ActiveRecord::Base.connection.supports_primary_key?
ActiveRecord::Base.connection.stubs(:primary_key).with('my_books_my_readers').returns(false).once
weaz = MyReader.create(:name=>'Weaz')
weaz.my_books << MyBook.create(:name=>'Great Expectations')
weaz.my_books << MyBook.create(:name=>'Greater Expectations')
end
end
@@@
The updated patch, patch-2086c.diff, has been attached.
<div><p>The results of the primary key check are now cached, to save
processing time on subsequent inserts. I also added a test which
verifies this behavior. I moved the check itself out of
insert_record, and into its own has_primary_key? instance method,
with result caching:</p>
<pre><code class="ruby">
# activerecord/lib/active_record/associations/has_and_belongs_to_many_association.rb
def has_primary_key?
return @has_primary_key unless @has_primary_key.nil?
@has_primary_key = (ActiveRecord::Base.connection.supports_primary_key? &&
ActiveRecord::Base.connection.primary_key(@reflection.options[:join_table]))
end
</code></pre>
<p>The insert_record method now calls this new method:</p>
<pre><code class="ruby">
# activerecord/lib/active_record/associations/has_and_belongs_to_many_association.rb
def insert_record(record, force = true, validate = true)
if has_primary_key?
raise ActiveRecord::ConfigurationError,
"Primary key is not allowed in a has_and_belongs_to_many join table (#{@reflection.options[:join_table]})."
end
# ...
end
</code></pre>
<p>Finally, the test (based on a join table that DOES contain a
primary key):</p>
<pre><code class="ruby">
# activerecord/test/cases/associations/habtm_join_table_test.rb
def test_should_cache_result_of_primary_key_check
if ActiveRecord::Base.connection.supports_primary_key?
ActiveRecord::Base.connection.stubs(:primary_key).with('my_books_my_readers').returns(false).once
weaz = MyReader.create(:name=>'Weaz')
weaz.my_books << MyBook.create(:name=>'Great Expectations')
weaz.my_books << MyBook.create(:name=>'Greater Expectations')
end
end
</code></pre>
<p>The updated patch, patch-2086c.diff, has been attached.</p></div>
false
2009-03-09T18:35:28+00:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-03-09T18:35:31+00:00
47440
Jaime Bellmyer
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
141
3
Is there anything I can/should be doing to move this ticket forward? I really think it's a valuable contribution, and I'd like to see it in Rails.
<div><p>Is there anything I can/should be doing to move this ticket
forward? I really think it's a valuable contribution, and I'd like
to see it in Rails.</p></div>
false
2009-06-03T18:04:35+01:00
47440
--- {}
9903
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-06-03T18:04:40+01:00
47440
Jaime Bellmyer
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.x
141
3
false
2009-06-10T04:41:03+01:00
47440
---
:milestone: 9903
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-06-10T04:41:03+01:00
141
Michael Koziarski
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
false
2009-08-07T14:00:33+01:00
47440
---
:tag: activerecord duplicate has_and_belongs_to_many join_table patch primary_key
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord bugmash duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-07T14:00:38+01:00
7211
Mike Gunderloy
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
* verified
* still cleanly applies
* +1, i've seen this bite many people in the past...definitely prefer the more descriptive error message the patch gives us.
* tests look sufficient
<div><ul>
<li>verified</li>
<li>still cleanly applies</li>
<li>+1, i've seen this bite many people in the past...definitely
prefer the more descriptive error message the patch gives us.</li>
<li>tests look sufficient</li>
</ul></div>
false
2009-08-08T17:15:40+01:00
47440
--- {}
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord bugmash duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-08T17:15:44+01:00
24346
John Trupiano
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
+1 for the feature but the patch did not apply cleanly to 2-3-stable - I also attempted to apply it to master but no joy.
I was recently bitten by this last week, so it's great to see this patch! Please confirm that this should apply to 2-3-stable and I'll modify the patch to apply cleanly
<div><p>+1 for the feature but the patch did not apply cleanly to
2-3-stable - I also attempted to apply it to master but no joy.</p>
<p>I was recently bitten by this last week, so it's great to see
this patch! Please confirm that this should apply to 2-3-stable and
I'll modify the patch to apply cleanly</p></div>
false
2009-08-08T19:57:10+01:00
47440
--- {}
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord bugmash duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-08T19:57:12+01:00
22242
Dan Pickett
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
+1 verified applies against 2-3-stable and master, tests look ok
<div><p>+1 verified applies against 2-3-stable and master, tests look
ok</p></div>
false
2009-08-08T20:23:02+01:00
47440
--- {}
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord bugmash duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-08T20:23:04+01:00
65576
stevestmartin
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
false
2009-08-10T06:20:38+01:00
47440
---
:tag: activerecord bugmash duplicate has_and_belongs_to_many join_table patch primary_key
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
new
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-10T06:20:43+01:00
85
Jeremy Kemper
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
(from [9c1bac0b7fcb627640db6824dca3e6e829a3c3e6]) raises an exception on habtm join table inserts if join table contains a primary key. Caches this check to save time on subsequent inserts.
[#2086 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
http://github.com/rails/rails/commit/9c1bac0b7fcb627640db6824dca3e6e829a3c3e6
<div><p>(from <a href=
"/projects/8994/changesets/9c1bac0b7fcb627640db6824dca3e6e829a3c3e6"
title=
"Changeset [9c1bac0b7fcb627640db6824dca3e6e829a3c3e6]">[9c1bac0b7fcb627640db6824dca3e6e829a3c3e6]</a>)
raises an exception on habtm join table inserts if join table
contains a primary key. Caches this check to save time on
subsequent inserts.</p>
<p>[<a href="/projects/8994/tickets/2086" title=
"Ticket #2086">#2086</a> state:committed]</p>
<p>Signed-off-by: Jeremy Kemper <a href=
"mailto:jeremy@bitsweat.net">jeremy@bitsweat.net</a><br>
<a href=
"http://github.com/rails/rails/commit/9c1bac0b7fcb627640db6824dca3e6e829a3c3e6">
http://github.com/rails/rails/commit/9c1bac0b7fcb627640db6824dca3e6...</a></p></div>
true
2009-08-10T06:20:53+01:00
47440
---
:state: new
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
committed
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-10T06:20:54+01:00
17393
Repository
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
(from [9d51f6286680b832b0df5e3ce288575214c1de59]) raises an exception on habtm join table inserts if join table contains a primary key. Caches this check to save time on subsequent inserts.
[#2086 state:committed]
Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce288575214c1de59
<div><p>(from <a href=
"/projects/8994/changesets/9d51f6286680b832b0df5e3ce288575214c1de59"
title=
"Changeset [9d51f6286680b832b0df5e3ce288575214c1de59]">[9d51f6286680b832b0df5e3ce288575214c1de59]</a>)
raises an exception on habtm join table inserts if join table
contains a primary key. Caches this check to save time on
subsequent inserts.</p>
<p>[<a href="/projects/8994/tickets/2086" title=
"Ticket #2086">#2086</a> state:committed]</p>
<p>Signed-off-by: Jeremy Kemper <a href=
"mailto:jeremy@bitsweat.net">jeremy@bitsweat.net</a><br>
<a href=
"http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce288575214c1de59">
http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce28857...</a></p></div>
true
2009-08-10T06:20:54+01:00
47440
--- {}
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
committed
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-08-10T06:20:55+01:00
17393
Repository
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
#3128 and #3190 are follow-ups on this feature.
<div><p><a href="/projects/8994/tickets/3128" title=
"Ticket #3128">#3128</a> and <a href="/projects/8994/tickets/3190"
title="Ticket #3190">#3190</a> are follow-ups on this feature.</p></div>
true
2009-09-11T22:08:51+01:00
47440
--- {}
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
committed
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-09-11T22:08:54+01:00
85
Jeremy Kemper
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
141
3
This patch just plain broke my app. Since AR doesn't support natively many-to-many double polymorphic relationships, we have a relationships table. Its migration is as follows:
class CreateRelationships < ActiveRecord::Migration
def self.up
create_table :relationships, :id => false do |t|
t.column :origin_id, :integer, :null => false
t.column :origin_type, :string, :null => false
t.column :destination_id, :integer, :null => false
t.column :destination_type, :string, :null => false
t.column :position, :integer, :null => true
end
add_index :relationships, [:origin_id, :origin_type, :destination_id, :destination_type],
:unique => true,
:name => 'index_relationship_polymorphs'
end
def self.down
drop_table :relationships
end
end
Do you have a solution for me? I need the primary key in this table.
<div><p>This patch just plain broke my app. Since AR doesn't support
natively many-to-many double polymorphic relationships, we have a
relationships table. Its migration is as follows:</p>
<p>class CreateRelationships < ActiveRecord::Migration<br>
def self.up</p>
<pre>
<code>create_table :relationships, :id => false do |t|
t.column :origin_id, :integer, :null => false
t.column :origin_type, :string, :null => false
t.column :destination_id, :integer, :null => false
t.column :destination_type, :string, :null => false
t.column :position, :integer, :null => true
end
add_index :relationships, [:origin_id, :origin_type, :destination_id, :destination_type],
:unique => true,
:name => 'index_relationship_polymorphs'</code>
</pre>
<p>end</p>
<p>def self.down</p>
<pre>
<code>drop_table :relationships</code>
</pre>
<p>end end</p>
<p>Do you have a solution for me? I need the primary key in this
table.</p></div>
true
2009-09-27T18:15:43+01:00
47440
--- {}
41987
2086
patch-primary-key-on-habtm-join-table-now-raises-an-exception
0
8994
committed
activerecord duplicate has_and_belongs_to_many join_table patch primary_key
Primary key on HABTM join table now raises an exception
2009-09-27T18:15:48+01:00
71184
tsenart
Jaime Bellmyer
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/2086
2.3.4
83c17b74866365b198f9cee98320e4a7eddb1e1f
text/plain
2009-02-26T16:24:57+00:00
habtm_join_table_with_pk_raises_exception.diff
93396
8032
47440
http://rails.lighthouseapp.com/attachments/93396/habtm_join_table_with_pk_raises_exception.diff
0a6dd15df1b25e726cd81c66fa97106262ada8a7
text/plain
2009-03-09T15:39:29+00:00
patch-2086b.diff
97548
8051
47440
http://rails.lighthouseapp.com/attachments/97548/patch-2086b.diff
920605f120a5eddd1ced4218976973b9bff13038
text/plain
2009-03-09T18:35:28+00:00
patch-2086c.diff
97661
11694
47440
http://rails.lighthouseapp.com/attachments/97661/patch-2086c.diff