Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

func Locate() depth level #82

Closed
Ganitzsh opened this issue May 19, 2015 · 4 comments
Closed

func Locate() depth level #82

Ganitzsh opened this issue May 19, 2015 · 4 comments

Comments

@Ganitzsh
Copy link

Hi!
I'm trying to recover a slice of a byte array (encoded msgpack) .
The msgpacked string looks good and I'm able to recover a slice from the root depth, but not more.
Here is the structure:

type MyStructA {
 Field1 interface{}
}

type MyStructB {
 Field2 interface{}
}

type MyStructC {
 Field3 string
}

data := MyStructA {
       Field1: &MyStructB {
         Field2: &MyStructC {
           Field3: "String",
           },
          },
      }

I want to isolate Field2 to decode it into a MyStructC variable to avoid dealing with a map[string]interface{} object since my fields are of type interface{}.
Using the raw content (the entire msgpack from data) I can access Field1 and decode it to a proper structure but not Field2 because msgp.Locate("Field2", raw) returns an empty byte array.

@philhofer
Copy link
Member

Keep in mind that each struct is its own map, so a struct containing other structs is turned into a map-of-maps. Consequently, the encoded msgpack looks like

{ "Field1" : { "Field2" : { "Field3" : "String" } } }

You need to locate Field1, and then within that locate Field2. So:

msgp.Locate("Field2", msgp.Locate("Field1", raw))

@philhofer
Copy link
Member

If you wanted to be fancy, you could wrap Locate in a function that took an input like "Field1.Field2" and split the input on each . and then applied each search recursively.

@Ganitzsh
Copy link
Author

Ok! It works... My bad, I made a mistake in my structure and I was looking for the wrong key.
Thanks for the tip about the wrap, I thought of it and was wondering why you did not implement it?

@philhofer
Copy link
Member

Mostly because the string-processing (allocation) is more expensive than the actual de-serialization, and so the performance benefit of incremental/partial processing goes out the window.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants