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
> @post = Post.new
> @post.id = "abc123"
=> Fails because id is nil/null (obviously)
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.
To clarify, I was previously doing using a callback via before_create,
self.id = UUIDTools::UUID.timestamp_create.to_s
Just do this and it will work.
class Post < ActiveRecord::Base
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.
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.