-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
encoding/xml: inconsistent omitempty compared to encoding/json #5452
Comments
A related issue: I believe this program should print {}, not {"X":null}. It may be strictly speaking within the letter of the documentation (the interface is not nil, but holds a nil value) but I think it would be more in the spirit of the existing marshalling (and consistent with encoding/xml) for the value inside the interface to be considered when deciding about omitempty. package main import ( "encoding/json" "fmt" ) type Foo struct { X interface{} `json:",omitempty"` } func main() { data, err := json.Marshal(Foo{[]int(nil)}) if err != nil { fmt.Println("err: %v", err) } else { fmt.Printf("%s\n", data) } } |
I like that json does not look inside the value of the pointer. Otherwise, I wouldn't be able to set the difference between a zero (zero availability) and null value (no update), which is important in the motel management solution I am writing. Maybe omitempty is too general. Maybe we need an omitnil as well. |
Otherwise, because of golang/go#5452, we can't encode zero values at all. So until that's fixed, you're stuck being unable to use default values in most requests.
What's the status on this ticket ? it's really hurting development , as it basically means for all google APIs (that use SOAP, and hence XML) we have to throw away the default xml marshaling and roll out our own :/ |
@allan-simon, the status is that nobody is working on it. |
@bradfitz ok ^^' , if I was to try my hand on it, would it have chances to get merge (admitting i follow the correct contributing procedure ofc) ? By that I mean, would there be backward compatibility concerns, even though it's not a documented "feature" ? |
I think it has a good chance of being accepted. If not it would've been closed a long time ago as "Unfortunate". The fact that it's still open implies that some sort of fix is possible. It's also not labeled as a "Documentation" fix. So, give it a shot. Complications often arise during development, but try and see. |
@bradfitz , thanks for the clarification , if things get complicated I will expose them here |
after investigation the problem seems to be with https://github.com/golang/go/blob/master/src/encoding/xml/marshal.go#L762-L768 So when we arrive in the function, we early return https://github.com/golang/go/blob/master/src/encoding/xml/marshal.go#L405-L407 as we got an empty string |
I've added in marshal_test for OmitFieldTest struct a field "PStr" which is a *string, and in the test, initialized it to a pointer to an empty string, with current code it fails, by removing lines 762-768 it works but now one test fail
I will dig more in some hours after some sleep ^^ |
got it, it was because the chardata / attributes part were relying on the fact that pointer were already dereferenced by the calling function, so it was simply ignoring pointers all test are passing now, I will complete the test suite that was lacking some cases and i will issue a patch |
I made a patch :) https://go-review.googlesource.com/#/c/15684/ |
CL https://golang.org/cl/15684 mentions this issue. |
Oh yes. The most important consequence of this for me is a problem with bool types. If I have |
by krolaw:
The text was updated successfully, but these errors were encountered: