To unmarshal JSON, do your structs have to match the JSON exactly?
m
However in practice, I've never been successful. I think it's because
unmarshaling assumes a simple JSON structure where in reality few real
world JSON objects are simple. Here's an example:
http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20yahoo.finance.industry%20where%20id%3D%22112%22&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys&callback=
So, before I waste my time, to I have to build structs that are going
to match the JSON exactly? I have to build a top level struct, then
sub structs, even though what I want is at the bottom of the pile so
to speak?
Peter Bourgon
You do have to represent the structure to the depth of the information
you want to extract, but you don't have to enumerate all the fields,
only the ones that contain relevant info. For example, if you wanted
only a list of company symbols, you have to have data structures that
hold the query, results, industry, company (list) and symbol, but you
can ignore created, lang, industry id/name, etc. The JSON unmarshaler
will skip stuff it doesn't find a place for.
I don't see anything wrong with this; it seems totally appropriate for
"real world JSON objects". Really I have no idea how you could even
get around this kind of requirement and still call it JSON parsing. If
you only want very particular pieces of data at the very bottom of a
deep hierarchy, consider a regex.
Brian Ketelsen
roger peppe
could unmarshal from a map[string]interface{} (as returned
when unmarshalling to *interface{}) to a struct.
then you could dive down into the json structure
and still get the benefits of unmarshalling to structs.
Brian Slesinsky
On Nov 25, 7:44 am, Peter Bourgon <peterbour...@gmail.com> wrote:
> I don't see anything wrong with this; it seems totally appropriate for
> "real world JSON objects". Really I have no idea how you could even
> get around this kind of requirement and still call it JSON parsing. If
> you only want very particular pieces of data at the very bottom of a
> deep hierarchy, consider a regex.
equivalent of an XPath query to specify the root nodes of interest.
- Brian
Stephen J Day
an underlying map as well:
package main
import (
"fmt"
"json"
)
func main() {
var m map[string]interface{}
json.Unmarshal([]byte("{\"foo\": 1}"), &m)
fmt.Println(m) // prints: map[foo:1]
}
Steve
> > I find the idea of unmarshaling JSON to structs to be wonderful.
> > However in practice, I've never been successful. I think it's because
> > unmarshaling assumes a simple JSON structure where in reality few real
> > world JSON objects are simple. Here's an example:
>
m
complicated JSON unmarshaling. Using the example I showed in this
thread, I've spent much time and can't get it to work. Now I get the
error: json: cannot unmarshal object key "query" into unexported field
query of type industries.Top
My code:
type Industry struct {
Id string
Name string
Company Company
}
type Top struct {
query Query
}
type Query struct {
count string
created string
lang string
results Results
}
type Results struct {
industry Industry
}
type Company struct {
Symbol string
Name string
}
func main() {
url := "http://query.yahooapis.com/v1/public/yql" +
"?q=select%20*%20from%20yahoo.finance.in" +
"dustry%20where%20id%3D%22"+ ind.Id +
"%22&format=json&env=store%3A%2F%2Fdatat" +
"ables.org%2Falltableswithkeys&callback="
resp, _, _ := http.Get(url)
var buf []byte
buf, _ = ioutil.ReadAll(resp.Body)
var t Top
_ = json.Unmarshal(buf, &t)
println("Worked!")
}
m
real.
Steven
JSON can't unmarshal into private fields because they are private. It
doesn't have any special permissions. In order to get it to work, you
have to export the fields you need to unmarshal into.
m
On Nov 26, 6:07 pm, Steven <steven...@gmail.com> wrote:
Steven
Thanks, I didn't understand what "export fields" meant.
m
of type []main.iIndustry
I have no idea why! Anyone willing to give it a try?
package main
import (
"http"
"io/ioutil"
"json"
"os"
)
type iIndustry struct {
Id string
Name string
}
type Sector struct {
Name string
Industry []iIndustry
}
type sResults struct {
Sector []Sector
}
type sQuery struct {
Count string
Created string
Lang string
Results sResults
}
type sTop struct {
Query sQuery
}
func GetIndustries() ([]iIndustry, os.Error) {
"ctors&format=json&env=http%3A%2F%2Fdata" +
"tables.org%2Falltables.env&callback="
resp, _, err := http.Get(url)
if err != nil { return nil, os.NewError("Could not get industries
from Yahoo servers.") }
var buf []byte
buf, err = ioutil.ReadAll(resp.Body)
if err != nil { return nil, os.NewError("Could not parse http
response for Industries.") }
var t sTop
err = json.Unmarshal(buf, &t)
if err != nil { return nil, err }
println("Worked.")
println(len(t.Query.Results.Sector))
//println(t.Query.Results.Sector[0].Name)
os.Exit(0)
return t.Query.Results.Sector[0].Industry, nil
}
chris dollin
> This returns an error of: json: cannot unmarshal object into Go value
> of type []main.iIndustry
>
> I have no idea why! Anyone willing to give it a try?
Mere guesswork: []main.industry is a slice, so you should
be trying to unmarshall an array into it, not any old object.
(Should the message be more explicit about the entity it's
trying to unmarshall?)
Chris
--
Chris "allusive" Dollin
roger peppe
for most sectors, "industry" holds a JSON array
holding the various industries, but Conglomerates,
with only one industry has a singleton value instead of an
array holding a single value.
if it's changed to be an array, the unmarshalling works.
if this is common practice in JSON encodings, it would
be possible to change json.Unmarshal so that it is
liberal enough to unmarshal a singleton object into
an array.
as it is currently, your only option is to change the
type of Sector.Industry to interface{} and do the extraction
manually.
i still think that my earlier suggestion would be useful,
particularly when the top levels of the JSON data
are not very rigidly defined.
On 27 November 2010 15:23, m <phill...@gmail.com> wrote:
roger peppe
> (Should the message be more explicit about the entity it's
> trying to unmarshall?)
yes!
Andrew Gerrand
One idea I had: register a type with the json package, and then when
unmarhsalling into a value of type interface{}, json will look at its
set of registered types for one that matches the provided fields and
initialise a value of that type, instead of a map[string]interface{}.
For example:
type Foo struct {
Bar int
Baz string
}
const s = `{"Bar": 12, "Baz": "a string"}`
func main() {
json.Register(Foo{})
var v interface{}
json.Unmarshal([]byte(s), &v)
_ := v.(Foo) // this should work
}
This would make much of my code simpler. Does that seem useful to anyone else?
Andrew
jimmy frasche
different kinds of reponses. You could just have one type for each of
them and do a typeswitch on v and know what kind of data you recieved
and have it nicely packaged and loaded up with helper methods. I
haven't played around with the json package yet but I have had run ins
with json data before where something like that would have saved a lot
of time and code.
Andrew Gerrand
> That seems pretty useful. Especially if you were getting a few
> different kinds of reponses. You could just have one type for each of
> them and do a typeswitch on v and know what kind of data you recieved
> and have it nicely packaged and loaded up with helper methods. I
> haven't played around with the json package yet but I have had run ins
> with json data before where something like that would have saved a lot
> of time and code.
Yes, exactly.
My workaround thus far has been to create a shim object:
type Shim struct {
Foo *Foo
Bar *Bar
}
And then when generating the JSON, I put the actual data one level down:
{"Foo": { foo object contents }}
or
{"Bar": { bar object ... }}
Then it's just an if shim.Foo == nil test, but it would be much more
elegant to use a type switch.
Andrew