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

in function not working properly for JSON array #1468

Closed
jmarente opened this Issue Oct 1, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@jmarente

jmarente commented Oct 1, 2015

I'm having the following issue with "in" function when I use it with a JSON array.

This works:

{{ $array := (seq 1 10) }}
{{ in $array 7 }} => true
{{ in $array 12 }} => false

Having the following JSON:

{
    "array": [1,2,3,4,5,6,7,8,9,10]
}

This doesn't:

{{ $json_content := getJSON "path/to/json" }}
{{ in $json_content.array 7 }} => false
{{ in $json_content.array 12 }} => false

I have tried different things and I always get the same result.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 1, 2015

Member

Probably a type mismatch (int vs int64), not sure what to do about that in this case.

@tatsushid any idea?

Member

bep commented Oct 1, 2015

Probably a type mismatch (int vs int64), not sure what to do about that in this case.

@tatsushid any idea?

@tatsushid

This comment has been minimized.

Show comment
Hide comment
@tatsushid

tatsushid Oct 5, 2015

Contributor

@bep, yes, as you mentioned, it is caused by a type mismatch but not int64 vs int but float64 and int!

According to the go official document about encoding/json, any number values in JSON are unmarshaled into float64 when interface{} type value is passed as a container.

Which is the best introducing a something container struct at reading JSON to add special unmarshaler for int value or fix all template functions (includes in) to compare any numbers in float type? I prefer the former one.

Contributor

tatsushid commented Oct 5, 2015

@bep, yes, as you mentioned, it is caused by a type mismatch but not int64 vs int but float64 and int!

According to the go official document about encoding/json, any number values in JSON are unmarshaled into float64 when interface{} type value is passed as a container.

Which is the best introducing a something container struct at reading JSON to add special unmarshaler for int value or fix all template functions (includes in) to compare any numbers in float type? I prefer the former one.

@bep bep added the Bug label Oct 6, 2015

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 6, 2015

Member

Which is the best introducing a something container struct at reading JSON to add special unmarshaler for int value or fix all template functions (includes in) to compare any numbers in float type? I prefer the former one.

@tatsushid It would be totally preferred if this could be solved in one place.

Member

bep commented Oct 6, 2015

Which is the best introducing a something container struct at reading JSON to add special unmarshaler for int value or fix all template functions (includes in) to compare any numbers in float type? I prefer the former one.

@tatsushid It would be totally preferred if this could be solved in one place.

@tatsushid

This comment has been minimized.

Show comment
Hide comment
@tatsushid

tatsushid Oct 9, 2015

Contributor

I wrote a JSON unmarshal sample code https://play.golang.org/p/Ru3snl2_rR. json.Decorder has UseNumber() method not to convert a number value to float64 value but to just save it as json.Number. We can convert json.Number value to int64 or float64 as we like later.

The sample expands JSON element tree with json.Number to the one without json.Number not to break current behavior in other area in Hugo. It's not efficient but I can't find out the way to do it in parsing JSON.

What do you think? If it looks good, I will implement it around JSON parser in Hugo.

Contributor

tatsushid commented Oct 9, 2015

I wrote a JSON unmarshal sample code https://play.golang.org/p/Ru3snl2_rR. json.Decorder has UseNumber() method not to convert a number value to float64 value but to just save it as json.Number. We can convert json.Number value to int64 or float64 as we like later.

The sample expands JSON element tree with json.Number to the one without json.Number not to break current behavior in other area in Hugo. It's not efficient but I can't find out the way to do it in parsing JSON.

What do you think? If it looks good, I will implement it around JSON parser in Hugo.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Oct 12, 2015

Member

@tatsushid looks fine to me. I'll gladly trade a slight performance hit in this area in favor of consistent behavior.

Member

bep commented Oct 12, 2015

@tatsushid looks fine to me. I'll gladly trade a slight performance hit in this area in favor of consistent behavior.

@bep bep added the Stale label Feb 27, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Mar 1, 2017

Member

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

Member

bep commented Mar 1, 2017

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

@bep bep added Keep and removed Stale labels Mar 27, 2017

@bep bep modified the milestone: v0.23 Jun 8, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jun 8, 2017

Member

@moorereason is this fixed?

Member

bep commented Jun 8, 2017

@moorereason is this fixed?

@bep bep modified the milestones: v0.22, v0.23 Jun 8, 2017

@moorereason

This comment has been minimized.

Show comment
Hide comment
@moorereason

moorereason Jun 10, 2017

Contributor

No, here's a failing test:

{[]float64{1, 2, 3}, 1, true},

My recent updates have been in Union and Intersect, not In.

Contributor

moorereason commented Jun 10, 2017

No, here's a failing test:

{[]float64{1, 2, 3}, 1, true},

My recent updates have been in Union and Intersect, not In.

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Jun 10, 2017

Member

The slow path to perfection ... :-)

Member

bep commented Jun 10, 2017

The slow path to perfection ... :-)

@bep bep modified the milestones: v0.23, v0.22, v0.24 Jun 10, 2017

@bep bep modified the milestones: v0.24, v0.25 Jun 20, 2017

@bep bep self-assigned this Jul 3, 2017

bep added a commit to bep/hugo that referenced this issue Jul 3, 2017

@bep bep closed this in #3672 Jul 3, 2017

bep added a commit that referenced this issue Jul 3, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment