Serialize Nested Hash Problem!

[Lee Farrell]

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

--
Posted via http://www.ruby-forum.com/.

[Frederick Cheung]

On Jul 15, 1:02 pm, Lee Farrell <li...@ruby-forum.com> 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

[cipher_neo]

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

[Frederick Cheung]

On Jul 18, 9:09 am, cipher_neo <l33...@gmail.com> 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
>
> thanks,
>
> Lee

[cipher_neo]

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)

[cipher_neo]

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)

[cipher_neo]

surely somebody has had this problem?

[Frederick Cheung]

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

[cipher_neo]

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

[cipher_neo]

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?

[Tom Meinlschmidt]

do you have the same version of ruby?

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/l87V_ZfOaIIJ.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-ta...@googlegroups.com.
> 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
===============================================================================

[cipher_neo]

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

[Tom Meinlschmidt]

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

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/x8hki5-pwqEJ.

[cipher_neo]

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

[Colin Law]

On 21 July 2011 18:43, cipher_neo <l33...@gmail.com> 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

[cipher_neo]

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

I'll get back with results, thanks