Cassius Rosenthal on 18 Oct 2006 21:24:22 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PhillyOnRails] ActiveRecord::new() and default table values

So in Chris' approach, I could do:
And this would work except that I have 'before_create' filters on Product, and for some reason clone() loses all of the methods that should be there. For example, self.kind='something' doesn't work in a filter for @product as generated above. I can't rewrite all of the before filters to muck around in the @attributes variable, because there are just too many models to rewrite for this exception.

So, I'm settling for Evan's approach, using the "write_attribute" function (which I see is also mentioned in the comments of "active_record/base.rb") and removing the default value in the table definition. It's not what I would like to do, but it is a step forward.

Thanks for your help; I hope this helps others on the list as well. If anyone knows of a cleaner approach . . .


Evan wrote:
You can force a specific primary key by adding an id writer method to
your model:

   def id= n; write_attribute :id, n; end

Then after instantiating the object with .new(hash), you can assign
.id= the new id. Then you can save the record and it will go in with
the id you want. (At least, that's how I worked around the problem in
my own code).

I don't know why your "kind" attribute isn't getting saved properly, though.


On 10/18/06, Cassius Rosenthal <> wrote:
Interesting approach.  This breaks filters because the YAML object uses
strings instead of symbols to hash the attributes.  Substituting strings
into filter functions [is ugly but] does solve the problem of :kind in
the example below overriding the table default; however, the id for the
object still is not preserved.  In this case, it defaults to the
postgres sequence.  So this approach still doesn't work.

This may be obvious, but building on my example below, the sql:
"INSERT INTO products VALUES (42,'apple','fruit');"
works perfectly, and is the sql that I expect/wish to be generated by Rails.

Any other ideas?


Chris wrote: > Try products[0].clone rather than creating a new object. > > Cassius Rosenthal wrote: >> This is one of those questions where I knew how to do what I want to, >> but I can't for the life of me remember how to do it. I should know >> this, but I just can't seem to find the answer from The Brain (ie., >> googling didn't help). >> Say I have a model Product. I create the table as follows: >> [code] >> create_table :products, :force => true do |t| >> t.column :name, :string >> t.column :kind, :string, :default=>"pizza" >> end >> [/code] >> >> I then load a product from a fixture: >> [code] >> products=YAML::load(foo.yml) >> [/code] >> #products[0].attributes=> >> {:id=>"42", :name=>"apple", :kind=>"fruit"} >> So far, so good. Note the id of 42, which is important because this >> object relates to another model, and I want to preserve the primary >> keys. >> >> Then I instantiate a new ActiveRecord from this data: >> [code] >>[0].attributes) >> [code] >> #@products=> >> {:id=>"1", :name=>"apple", :kind=>"pizza"} >> Ack! ActiveRecord used the table defaults instead of the attributes >> that I sent to the object. How do I override this behavior? >> >> Thanks! >> -Cassius >> _______________________________________________ >> talk mailing list >> >> >> > > _______________________________________________ > talk mailing list > > > > >

talk mailing list

_______________________________________________ talk mailing list