Serialize Nested Hash Problem!

Rails
1

Hi,

I am serializing an attribute in my model with serialize :data

The data in question is a hash defined as

{:terminal_id => terminal_id, :order_data => table_order_data, :table_id
=> table_id}

I have deployed my app on a few machines and it works well, storing the
data above in serialized format as follows:

:terminal_id: DellXP
:order_data: !map:ActiveSupport::HashWithIndifferentAccess
tableID: “39”
orderData: !map:ActiveSupport::HashWithIndifferentAccess
items: !map:ActiveSupport::HashWithIndifferentAccess
“0”: !map:ActiveSupport::HashWithIndifferentAccess
amount: “1”
product: !map:ActiveSupport::HashWithIndifferentAccess
id: “68”
name: Club Orange
price: “2.4”
tax_rate: “21”
tax_rate: “21”
product_price: “2.4”
total_price: “2.4”
terminal_id: DellXP
time_added: “1310730896520”
serving_employee_id: “1”
synced: “true”
itemNumber: “1”
total: “2.4”
:table_id: “39”
:serving_employee_id: “1”

I recently did a fresh deploy and the data is now being stored without
the !map:ActiveSupport::HashWithIndifferentAccess part, which is
breaking my app. The serialized data is now stored as:

:terminal_id: DellXP
:order_data:
tableID: ‘1’
orderData:
items:
‘0’:
amount: ‘1’
product:
id: ‘7’
name: Guinness Pint
price: ‘3.8’
tax_rate: ‘21’
tax_rate: ‘21’
product_price: ‘3.8’
total_price: ‘3.8’
terminal_id: DellXP
time_added: ‘1310729775938’
serving_employee_id: ‘1’
synced: ‘true’
itemNumber: ‘1’
total: ‘3.8’
:table_id: ‘1’
:serving_employee_id: ‘1’

which is different to the above (which actually worked for me)

I am not sure what is going on, as I am using the exact same codebase.

Anyone have any ideas?

thanks

2

On Jul 15, 1:02pm, Lee F. [email protected] wrote:

Hi,

I am serializing an attribute in my model with serialize :data

The data in question is a hash defined as

which is different to the above (which actually worked for me)

I am not sure what is going on, as I am using the exact same codebase.

The difference is that you now cannot use strings and symbols
interchangeably as keys for this hash. The most common way to come
across such hashes (other than creating them explicitly) is via the
params hash (and its subhashes) which are always
HashWithIndifferentAccess instances
Are you saying that you did a deploy that did not change a single line
of code in the entire app (and there were not changes in version of
the various gems you might use) ?

What does the code that sets this hash look like?

Fred

3

Hi Fred, thanks for your feedback.

Yes, the data contained in the subhash (table_order_data) comes directly
from the params hash.

In which case I am not in control of how that hash is built.

This leads me to think that it has got something to do with how the
params
hash is constructed, rather than my application code?

“Are you saying that you did a deploy that did not change a single line
of code in the entire app (and there were not changes in version of
the various gems you might use) ?”

Yes, I have the same codebase deployed on a different machine that is
running apache and passenger.
The gems are not exactly the same, which could be the problem.

Here is a list of the gems that are on the working machine:

abstract (1.0.0)
actionmailer (3.0.5)
actionpack (3.0.5)
activemodel (3.0.9, 3.0.5)
activerecord (3.0.5)
activeresource (3.0.5)
activesupport (3.0.9, 3.0.5)
annotate-models (1.0.4)
archive-tar-minitar (0.5.2)
arel (2.0.9)
builder (2.1.2)
bundler (1.0.12)
columnize (0.3.2)
daemons (1.0.10)
erubis (2.6.6)
faker (0.9.5)
gem_plugin (0.2.3)
i18n (0.5.0)
linecache19 (0.5.12, 0.5.11)
mail (2.2.19, 2.2.15)
meta_search (1.0.5)
mime-types (1.16)
mongrel (1.2.0.pre2)
mysql2 (0.2.6)
polyglot (0.3.1)
populator (1.0.0)
rack (1.2.2)
rack-mount (0.6.14)
rack-test (0.5.7)
rails (3.0.5)
railties (3.0.5)
rake (0.8.7)
ruby-debug-base19 (0.11.25, 0.11.24)
ruby-debug-ide (0.4.16)
ruby-debug19 (0.11.6)
ruby_core_source (0.1.5, 0.1.4)
test-unit (2.3.0)
thor (0.14.6)
treetop (1.4.9)
tzinfo (0.3.27, 0.3.25)
will_paginate (3.0.pre2)

and here are a list of the gems that are on the new machine where the
app is
not working:

abstract (1.0.0)
actionmailer (3.0.5)
actionpack (3.0.5)
activemodel (3.0.5)
activerecord (3.0.5)
activeresource (3.0.5)
activesupport (3.0.5)
archive-tar-minitar (0.5.2)
arel (2.0.9)
builder (2.1.2)
bundler (1.0.15)
columnize (0.3.4)
daemon_controller (0.2.6)
daemons (1.0.10)
erubis (2.6.6)
faker (0.9.5)
fastthread (1.0.7)
gem_plugin (0.2.3)
i18n (0.6.0)
linecache19 (0.5.12)
mail (2.2.19)
meta_search (1.0.5)
mime-types (1.16)
mongrel (1.2.0.pre2)
mysql2 (0.2.6)
passenger (3.0.7)
polyglot (0.3.1)
populator (1.0.0)
rack (1.2.3)
rack-mount (0.6.14)
rack-test (0.5.7)
rails (3.0.5)
railties (3.0.5)
rake (0.9.2, 0.8.7)
rmagick (2.13.1)
ruby-debug-base19 (0.11.25)
ruby-debug19 (0.11.6)
ruby_core_source (0.1.5)
thor (0.14.6)
treetop (1.4.9)
tzinfo (0.3.29)
will_paginate (3.0.pre2)

I am not sure what gems are actually used in building the params hash or
when using the “serialize” call, could you shed some light on that and
maybe
I can pin point what gem exactly is at the wrong version?

thanks,

Lee

4

Yes, I am using bundler, just that in my gemfile it states to use
versions
either BIGGER THAN or equal (~>) to the speicified versions, which is
the
reason why different versions are appearing on new systems.

I am not fully up on using bundler, is there a way to lock to specific
versions of gems?

Here is my Gemfile.lock

remote: http://rubygems.org/
specs:
abstract (1.0.0)
actionmailer (3.0.5)
actionpack (= 3.0.5)
mail (~> 2.2.15)
actionpack (3.0.5)
activemodel (= 3.0.5)
activesupport (= 3.0.5)
builder (~> 2.1.2)
erubis (~> 2.6.6)
i18n (~> 0.4)
rack (~> 1.2.1)
rack-mount (~> 0.6.13)
rack-test (~> 0.5.7)
tzinfo (~> 0.3.23)
activemodel (3.0.5)
activesupport (= 3.0.5)
builder (~> 2.1.2)
i18n (~> 0.4)
activerecord (3.0.5)
activemodel (= 3.0.5)
activesupport (= 3.0.5)
arel (~> 2.0.2)
tzinfo (~> 0.3.23)
activeresource (3.0.5)
activemodel (= 3.0.5)
activesupport (= 3.0.5)
activesupport (3.0.5)
archive-tar-minitar (0.5.2)
arel (2.0.9)
builder (2.1.2)
columnize (0.3.2)
daemons (1.0.10)
erubis (2.6.6)
abstract (>= 1.0.0)
faker (0.9.5)
i18n (~> 0.4)
gem_plugin (0.2.3)
i18n (0.5.0)
linecache19 (0.5.12)
ruby_core_source (>= 0.1.4)
mail (2.2.19)
activesupport (>= 2.3.6)
i18n (>= 0.4.0)
mime-types (~> 1.16)
treetop (~> 1.4.8)
meta_search (1.0.5)

5

On Jul 18, 9:09am, cipher_neo [email protected] wrote:

I am not sure what gems are actually used in building the params hash or
when using the “serialize” call, could you shed some light on that and maybe
I can pin point what gem exactly is at the wrong version?

some combination of the rack and rails gems, although if you are using
bundler bundler should be ensuring you always run the same versions.

Fred

6

surely somebody has had this problem?

7

If I had of ran

bundle install --deployment

on the new machine, would that mean that it would not have specified
dependencies as >= (which seems to be breaking the app as the newer gems
are being downloaded and are incompatible with my code)

8

could it be something to do with passenger?

I have just made 100% sure that both systems are using the exact same
gems,
the only difference now is that I am using passenger on one system and
not
on the one that is working ok

9

On Jul 19, 11:19am, cipher_neo [email protected] wrote:

If I had of ran

bundle install --deployment

on the new machine, would that mean that it would not have specified
dependencies as >= (which seems to be breaking the app as the newer gems are being
downloaded and are incompatible with my code)

When you run bundle install --deployment it is supposed to use exactly
the versions in Gemfile.lock (if you look further down in the
Gemfile.lock file it lists the set of versions it picked that matched
the requirements of your gemfile), so that you get exactly the same
version on any machine you run it on. You can run bundle show to see
what versions bundler is actually pulling in for your two versions.

This is an odd problem though - params have always been an
HashWithIndifferentAccess and continue to be so - it feels to me that
you must be doing something to them that causes them to revert to
being normal hashes.

Fred

10

do you have the same version of ruby?

On Jul 21, 2011, at 12:03 , cipher_neo wrote:

To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

–

Tomas Meinlschmidt, MS {MCT, MCP+I, MCSE, AER}, NetApp Filer/NetCache

www.meinlschmidt.com www.maxwellrender.cz www.lightgems.cz

11

the hash comes directly from the params.

I store in the serializable column the exact hash that is there, so it
seems
like the params hash is not an instance of HashWithIndifferentAccess in
the
new deployment…

why could this be?

12

Hi tom,

yes the versions of ruby are also identical.

I have no clue what was happening, but I am going to get around it by
converting the hash to json format first then allowing it to be
serialized
and then retrieving it and doing a JSON.parse on it. After which I will
use
symbolize_keys!

I can be 100% certain then of the format of the data and should not have
any
problems.

thank you both for your help

13

I have a call

serialize :data

in the associated model.

Where exactly would I see the code you posted, and what exactly has it
got
to do with my problem, I don’t think I follow.

Anyway, I have solved the problem by going from params hash to json to
serialized data and then parsing it back out when it is needed by doing
the
reverse.

thanks

14

On 21 July 2011 18:43, cipher_neo [email protected] wrote:

I have a call

serialize :data

I wonder if the problem could be that “data” is a reserved word in
Rails. Using reserved words sometimes appears ok but then gives
strange problems.

See
http://oldwiki.rubyonrails.org/rails/pages/ReservedWords

Colin

15

how do you serialize?

via serialize :params ?

don’t you have somewhere in the code this?

class HashWithIndifferentAccess < Hash
def to_yaml(opts = {})
self.to_hash.to_yaml(opts)
end
end

there could be difference between env - production/devel, try to load
your app as production on your localhost

On Jul 21, 2011, at 13:04 , cipher_neo wrote:

–
You received this message because you are subscribed to the Google G. “Ruby
on Rails: Talk” group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-talk/-/x8hki5-pwqEJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

–

Tomas Meinlschmidt, MS {MCT, MCP+I, MCSE, AER}, NetApp Filer/NetCache

www.meinlschmidt.com www.maxwellrender.cz www.lightgems.cz

16

that could well be the case. I will revert the code and try rename it.

I’ll get back with results, thanks