# Migration adds a column, can't set a value for it **URL:** \ **Category:** Rails\ **Created:** [March 13, 2007, 9:22pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728 "2007-03-13T21:22:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\ **Post date:** [March 13, 2007, 9:22pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728/1 "2007-03-13T21:22:44Z")
I’ve got a migration that adds a column then sets the value for one of the records: def self.up add\_column :publish\_property\_lists, :preview\_page\_header, :string if p = PublishPropertyList.find(:first, :conditions =\> “default\_properties IS TRUE”) p.update\_attribute :preview\_page\_header, “Preview Your Video Entry” end end However after running the migration, preview\_page\_header is still null in the database. I thew a puts statement inside the if to make sure it’s getting there, and it is. So why isn’t the record being updated? Pat ---
**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\ **Post date:** [March 13, 2007, 9:45pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728/2 "2007-03-13T21:45:47Z")
On 3/13/07, Pat M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > However after running the migration, preview\_page\_header is still null > in the database. I thew a puts statement inside the if to make sure > it’s getting there, and it is. So why isn’t the record being updated? > > Pat It gets weirder (for me). I thought maybe it was a transaction issue, so I split the migration out into two separate steps. The first migration adds the column. The second migration finds the record and updates it. I took the conditional out of the second migration as well, so I know that it’s finding and updating a record. Still, the database doesn’t reflect that. If I create a record with attributes, it’s fine. I just can’t update it from a migration. What gives? Pat ---
**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\ **Post date:** [March 13, 2007, 10:03pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728/3 "2007-03-13T22:03:50Z")
On 3/13/07, Pat M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > end > > migration adds the column. The second migration finds the record and > > updates it. I took the conditional out of the second migration as > > well, so I know that it’s finding and updating a record. Still, the > > database doesn’t reflect that. > > If I create a record with attributes, it’s fine. I just can’t update > it from a migration. What gives? > > Pat Okay looking at the logs, the migration updates all the existing values and commits it. So say the record has the name “foo”, the logs show: PublishPropertyList Load (0.000552) SELECT \* FROM publish\_property\_lists WHERE (default\_properties IS TRUE) LIMIT 1 SQL (0.000152) BEGIN PublishPropertyList Update (0.000452) UPDATE publish\_property\_lists SET `name` = ‘foo’ WHERE id = 1 SQL (0.000098) COMMIT Obviously that’s not very helpful…I don’t need to update the record with the attributes it already has, but rather need to update its new attributes. I’m really confused here. Pat ---
**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\ **Post date:** [March 13, 2007, 9:27pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728/4 "2007-03-13T21:27:45Z")
On Mar 13, 2007, at 4:22 PM, Pat M. wrote: > I’ve got a migration that adds a column then sets the value for one of > the records: > > def self.up > add\_column :publish\_property\_lists, :preview\_page\_header, :string > PublishPropertyList.reset\_column\_information > > Pat ActiveRecord needs to be told to take a new look at the table since you changed it. -Rob Rob B. [http://agileconsultingllc.com](http://agileconsultingllc.com) removed\_email\_address@domain.invalid ---
**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\ **Post date:** [March 13, 2007, 10:28pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728/5 "2007-03-13T22:28:52Z")
On 3/13/07, Pat M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > end > > migration adds the column. The second migration finds the record and > > updates it. I took the conditional out of the second migration as > > well, so I know that it’s finding and updating a record. Still, the > > database doesn’t reflect that. > > If I create a record with attributes, it’s fine. I just can’t update > it from a migration. What gives? > > Pat It turns out I need to add PublishPropertyList.reset\_column\_information Now that behavior makes a little bit of sense when I do the full migration (0-final). When I create the record, Rails loads PublishPropertyList into the namespace. When I go to update it later on, it has it cached along with the columns. So I have to reset the column info. It’d make a lot more sense if Rails threw a method missing error, because that’s essentially what it thinks is going on. Oh well. Pat ---
**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\ **Post date:** [March 13, 2007, 10:08pm UTC](https://www.ruby-forum.com/t/migration-adds-a-column-cant-set-a-value-for-it/88728/6 "2007-03-13T22:08:50Z")
On Mar 13, 2007, at 4:45 PM, Pat M. wrote: > > Entry" > > Pat My previous email is still valid (reset\_column\_information), but you probably also have to make the condition valid from the point of view from SQL. Try this: p = PublishPropertyList.find(:first, :conditions =\> [“default\_properties = ?”, true]) This should work for any database regardless of whether booleans are modeled as 0/1 or true/false. In any case the SQL fragment “where default\_properties IS TRUE” is quite likely not equivalent to “where default\_properties = 1” or “where default\_properties = true” (note “=” rather than “IS”). -Rob Rob B. [http://agileconsultingllc.com](http://agileconsultingllc.com) removed\_email\_address@domain.invalid