-
Notifications
You must be signed in to change notification settings - Fork 106
Update always sets hstore column #102
Comments
I'll take a look at this during this week |
Rails core is dealing with the flip side of this issue: rails/rails#6127 The problem is that if Rails's change tracking doesn't work at the granularity of keys within a hash, so it's either:
In the latter case, a partial update won't be saved unless the developer is careful (actually reassigning the attribute or calling |
Even if you don't change anything in hstore column, #save issue UPDATE ..... |
I've ended up with moving hstore column to separate relation. So now if need to access hstore attributes, will call them directly, by Before: class Product
serialize :attrs, ActiveRecord::Coders::Hstore
end After: class Product
has_one :attrs, class_name: 'ProductAttrs'
end
class ProductAttrs
belongs_to :product
serialize :data, ActiveRecord::Coders::Hstore
end It's not so efficient on selects, but I do many more updates, than selects, so it works for me. |
Has there been any update on this? I've run into an issue where hstore is removing columns in my shared pg database when a different api does an update request. The columns aren't defined in one api but are defined in the other, shouldn't those columns remain concrete and not be removed from the table? |
When I update other fields, the hstore column, is always set as well.
The options column gets updated as well.
The text was updated successfully, but these errors were encountered: