We had something very odd happen today after installing the twitter
gem. We had a ton of our tests fail. When we removed the gem they
would pass.
What it ended up being was during the building of attributes using
nested attributes setters we were accessing the hash that was passed
in like this:
def shade_preference_attributes=(shade_preference_attributes)
shade_preference_attributes.each_pair do |key, value|
value.each do |shade|
self.shade_preferences.build(:shade_id => shade
[:shade_id], :preference => shade[:preference])
end
end
end
Before installing and configuring the twitter gem in our rails
application this worked fine. After doing it, it started failing.
The failure was because shade (a hash) did not have :shade_id
or :preference in it anymore. It actually always had the keys
"shade_id" and "preference" that never changed, but now the
access of
them by symbol started failing.
When I removed removed the config.gem line for the the twitter gem
everything worked fine.
I''m assuming this has something to do with indifferent access. In
both cases the shade is a normal Hash. But, in one case it appears to
be using indifferent access and in another case not. Or could it be
the hash was built using indifferent acces or not? I''m not exactly
sure how that works.
The twitter gem installs a bunch of gems. Has anyone seen anything
like this before.
Thanks.
Erik
It''s not the twitter gem, it''s the mash gem. The twitter gem requires the mash gem. Erik On Oct 6, 6:36 pm, erik <e...-9T/GIyPsA//QT0dZR+AlfA@public.gmane.org> wrote:> We had something very odd happen today after installing the twitter > gem. We had a ton of our tests fail. When we removed the gem they > would pass. > > What it ended up being was during the building of attributes using > nested attributes setters we were accessing the hash that was passed > in like this: > > def shade_preference_attributes=(shade_preference_attributes) > shade_preference_attributes.each_pair do |key, value| > value.each do |shade| > self.shade_preferences.build(:shade_id => shade > [:shade_id], :preference => shade[:preference]) > end > end > end > > Before installing and configuring the twitter gem in our rails > application this worked fine. After doing it, it started failing. > The failure was because shade (a hash) did not have :shade_id > or :preference in it anymore. It actually always had the keys > "shade_id" and "preference" that never changed, but now the access of > them by symbol started failing. > > When I removed removed the config.gem line for the the twitter gem > everything worked fine. > > I''m assuming this has something to do with indifferent access. In > both cases the shade is a normal Hash. But, in one case it appears to > be using indifferent access and in another case not. Or could it be > the hash was built using indifferent acces or not? I''m not exactly > sure how that works. > > The twitter gem installs a bunch of gems. Has anyone seen anything > like this before. > Thanks. > Erik
These lines at the bottom of the mash gem are causing the issue:
# Converts all of the keys to strings
def stringify_keys!
keys.each{|k|
v = delete(k)
self[k.to_s] = v
v.stringify_keys! if v.is_a?(Hash)
v.each{|p| p.stringify_keys! if p.is_a?(Hash)} if v.is_a?(Array)
}
self
end
This is defined inside class Hash...end inside of the mash
file.....hmmm.....
Erik
On Oct 6, 6:47 pm, erik <e...-9T/GIyPsA//QT0dZR+AlfA@public.gmane.org>
wrote:> It''s not the twitter gem, it''s the mash gem. The twitter
gem requires
> the mash gem.
> Erik
>
> On Oct 6, 6:36 pm, erik
<e...-9T/GIyPsA//QT0dZR+AlfA@public.gmane.org> wrote:
>
> > We had something very odd happen today after installing the twitter
> > gem. We had a ton of our tests fail. When we removed the gem they
> > would pass.
>
> > What it ended up being was during the building of attributes using
> > nested attributes setters we were accessing the hash that was passed
> > in like this:
>
> > def shade_preference_attributes=(shade_preference_attributes)
> > shade_preference_attributes.each_pair do |key, value|
> > value.each do |shade|
> > self.shade_preferences.build(:shade_id => shade
> > [:shade_id], :preference => shade[:preference])
> > end
> > end
> > end
>
> > Before installing and configuring the twitter gem in our rails
> > application this worked fine. After doing it, it started failing.
> > The failure was because shade (a hash) did not have :shade_id
> > or :preference in it anymore. It actually always had the keys
> > "shade_id" and "preference" that never changed,
but now the access of
> > them by symbol started failing.
>
> > When I removed removed the config.gem line for the the twitter gem
> > everything worked fine.
>
> > I''m assuming this has something to do with indifferent
access. In
> > both cases the shade is a normal Hash. But, in one case it appears to
> > be using indifferent access and in another case not. Or could it be
> > the hash was built using indifferent acces or not? I''m not
exactly
> > sure how that works.
>
> > The twitter gem installs a bunch of gems. Has anyone seen anything
> > like this before.
> > Thanks.
> > Erik