Always parse language tag. #3243
Conversation
Currently, the language tag is only being parsed if the value is a string, which lead to issues in a different PR. This change makes it so that the language tag is always parsed.
There was a problem hiding this comment.
LGTM. Get someone to review and approve this change.
Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @martinmr)
There was a problem hiding this comment.
when do we need to parse the lang tag when the predicate is not a string, i.e. what's the issue?
Reviewable status: 0 of 2 files reviewed, 2 unresolved discussions (waiting on @martinmr)
chunker/json/parse.go, line 257 at r2 (raw file):
} if op == DeleteNquads {
Is this blocking doing the same thing as the block below starting at line 292?
There was a problem hiding this comment.
Predicate can be null, indicating a S P * deletion. Language tags were not being properly parsed in that case, which came up because I made a change to support delete triples of the format <uid> <pred@lang> * .
Reviewable status: 0 of 2 files reviewed, 2 unresolved discussions (waiting on @gitlw and @golangcibot)
chunker/json/parse.go, line 264 at r1 (raw file):
Previously, golangcibot (Bot from GolangCI) wrote…
File is not
goimports-ed (fromgoimports)
Done.
chunker/json/parse.go, line 257 at r2 (raw file):
Previously, gitlw (Lucas Wang) wrote…
Is this blocking doing the same thing as the block below starting at line 292?
Looks like it. I have removed the second block.
There was a problem hiding this comment.
Reviewable status: 0 of 2 files reviewed, 2 unresolved discussions (waiting on @gitlw and @golangcibot)
Currently, the language tag is only being parsed if the value is a string, which lead to issues in a different PR. This change makes it so that the language tag is always parsed.
Currently, the language tag is only being parsed if the value is a
string, which lead to issues in a different PR.
This change makes it so that the language tag is always parsed.
This change is