location.human_address is String -- not Hashie::Mash

[marks]

Is this on purpose or would a PR to convert location fields' human_address in to hashes be accepted?

Right now, we are looping through all returned records to convert the location into a hash like so:

 @results = @results.map do |result|
   result.location_1.human_address = JSON.parse(result.location_1.human_address)
   result
 end

[chrismetcalf]

@marks I love this idea. I've already been thinking about adding some "demarshalling" functionality to the Ruby gem, to do things like convert timestamps into Time objects, decode numerics, etc.

One thing to be concerned about will be backwards compatibility. Thoughts?

[marks]

@chrismetcalf - didnt even realize dates were Strings - yes, we need demarshalling. How do you feel about tackling backwards compatibility by having it as an opt-in feature only by defining a config variable?

[chrismetcalf]

I’m all for making it controlled by a config variable. If you’ve got the time to take this on, I’ll gladly give feedback and accept your PR! 

It might be worth checking out the datatype reference too: http://dev.socrata.com/docs/datatypes/

On Tue, Sep 9, 2014 at 5:19 PM, Mark Silverberg notifications@github.com
wrote:

@chrismetcalf - didnt even realize dates were Strings - yes, we need demarshalling. How do you feel about tackling backwards compatibility by having it as an opt-in feature only by defining a config variable?

Reply to this email directly or view it on GitHub:
#14 (comment)

[marks]

Just to keep everyone updated, I am trying to see if this makes more sense to build into Hashie which soda-ruby uses: hashie/hashie#227