Setting primary key value manually

In ActiveRecord 3.1.0.rc4, setting the id manually no longer works - the assignment seems to be ignored. Is this expected behavior? Seems to break BC

create_table :posts, :id => false do |t|     t.string :id, :limit => 36, :primary => true, :null => false     t.string :title end

> @post = Post.new > @post.id = "abc123" > @post.id    => nil

> @post.save!     => Fails because id is nil/null (obviously)

Thoughts?

I never knew what the proper practice was for this sort of thing. In scenarios where I had to ensure that a primary key was set to a number I specified, I always used a callback to modify the ID to match a facade attribute if it had been set.

I’m sure that’s wrong, but I could never figure out a more reliable way to do it.

-Geoff

To clarify, I was previously doing using a callback via before_create, like so

      before_create :set_uuid       def set_uuid         self.id = UUIDTools::UUID.timestamp_create.to_s       end

Just do this and it will work.

class Post < ActiveRecord::Base   set_primary_key :id end

This may seem odd, but what is likely happening is that since the id column is the same name as the expected default and the type is now a string, it is failing to set things correctly or cast them appropriately. Being explicit will fix it, tho this could be considered a regression or bug.

- Ken

That did the trick. It's far from intuitive though - agree should probably be considered a bug.

If it worked in 3.0.9, but doesn't work in 3.1.0, please file a ticket (along with a test case if you can). In this case, I think it's likely this behavior was undefined (had no test case). At the very least we should add a test case that specs the behavior for this.

I tried using non-integer keys a while back and eventually gave up. I half got it working, but there were numerous issues. This is something I'd really like to get working properly in 3.2.

I've been using UUIDs since 3.0 stable and it works fine. Prior to 3.0 stable, there was code in activerecord that assumed an integer when assigning to id but that was fixed throughout 3.0.x. This seems to be a different issue, will log it as soon as I have minute.