naopontan です。

> そもそもidが増えていくことは保証されていないと思います。実際auto incrementになっていて
> 途中に空き番があったときにそこを使われることはありますし。

やっぱりそうですよね。
ただ、本番DBにて order 指定を削除したら、期待通りの順番になりました。
RDBMS に依存するのかな。まぁとりあえずはこれで様子を見てみます。
（テストが order 指定あり／なしのどちらでも通ったのは依然不明ですが…）


> 追加順にしたいのならタイムスタンプなどのフィールドを使って並べる必要があります。

という事は habtm ではなくて、has_many :through を使う事になるという事ですね。

2010年10月1日15:06 Andy Matsubara <andymatsubara@g...>:
> そもそもidが増えていくことは保証されていないと思います。実際auto incrementになっていて
> 途中に空き番があったときにそこを使われることはありますし。
> 追加順にしたいのならタイムスタンプなどのフィールドを使って並べる必要があります。
>
> Andy
>
> 2010/10/1 naopontan <naopontan@g...>:
>> こんにちは。
>>
>> User と Entry が has_and_belongs_to_many(habtm)で多対多の関係です。
>> この場合、
>>    @entry.users << @taro
>>    @entry.users << @jiro
>> の順番は保障されるのでしょうか？
>>
>> class Entry < ActiveRecord::Base
>>  has_and_belongs_to_many :users, :order => "id ASC", :uniq => true
>> end
>>
>> class User < ActiveRecord::Base
>>  has_and_belongs_to_many :entries
>> end
>>
>> 勝手に保障されると思っていて、逆転現象の不具合が出たので
>> 「:order => "id ASC"」がバグだ！って思ったんですけど、
>> 以下のテストを書いてみたら、:order を指定してもしなくてもテストが通ってしまいます。
>> あれ？何で？って感じです。
>>
>>  def test_my_group_order
>>    entry = entries(:entry1)
>>
>>    entry.users.clear
>>    entry.users << users(:taro)
>>    entry.users << users(:jiro)
>>    assert_equal [users(:taro), users(:jiro)], entry.users
>>
>>    entry.users.clear
>>    entry.users << users(:jiro)
>>    entry.users << users(:taro)
>>    assert_equal [users(:jiro), users(:taro)], entry.users
>>  end
>>
>> この辺りのご助言頂ければ幸いです。
>>
>> --
>> ML: rails@r...
>> 使い方: http://QuickML.com/
>>
>
> --
> ML: rails@r...
> 使い方: http://QuickML.com/
>

--
ML: rails@r...
使い方: http://QuickML.com/