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?
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
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 On Fri, Jul 8, 2011 at 1:37 PM, Luis Correa d''Almeida <luis.ca@gmail.com>wrote:> 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? > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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
On Jul 8, 6:45 pm, Geoff Harcourt <geoff.harco...@gmail.com>
wrote:> 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
>
> On Fri, Jul 8, 2011 at 1:37 PM, Luis Correa d''Almeida
<luis...@gmail.com>wrote:
>
>
>
>
>
>
>
> > 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?
>
> > --
> > You received this message because you are subscribed to the Google
Groups
> > "Ruby on Rails: Core" group.
> > To post to this group, send email to
rubyonrails-core@googlegroups.com.
> > To unsubscribe from this group, send email to
> > rubyonrails-core+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/rubyonrails-core?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
That did the trick. It''s far from intuitive though - agree should probably be considered a bug. On Fri, Jul 8, 2011 at 6:56 PM, Ken Collins <ken@metaskills.net> wrote:> > 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 > > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- Luis Corrêa d''Almeida tribe.fm/luis -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Fri, Jul 08, 2011 at 10:37:50AM -0700, Luis Correa d''Almeida wrote:> 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?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. -- Aaron Patterson http://tenderlovemaking.com/
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. On Fri, 2011-07-08 at 12:02 -0700, Aaron Patterson wrote:> On Fri, Jul 08, 2011 at 10:37:50AM -0700, Luis Correa d''Almeida wrote: > > 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? > > 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. >-- http://jonathanleighton.com/
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. On Fri, Jul 8, 2011 at 8:33 PM, Jon Leighton <j@jonathanleighton.com> wrote:> 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. > > On Fri, 2011-07-08 at 12:02 -0700, Aaron Patterson wrote: >> On Fri, Jul 08, 2011 at 10:37:50AM -0700, Luis Correa d''Almeida wrote: >> > 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? >> >> 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. >> > > -- > http://jonathanleighton.com/ >-- Luis Corrêa d''Almeida tribe.fm/luis -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.