사용자 정의 JSON을 사용하여 라이브러리 봉인/해제 가능

묘사

주소 #82
새로운 API 방법jsonpatch.SetAPI(otherJsonLibrary)이 추가되었습니다. 이 방법은 사용자 정의 JSON 라이브러리를 사용할 수 있습니다. 필요한 3가지 방법만 있으면 됩니다. Marshal(),MarshalIndent(),Unmarshal(),jsonpatch.ResetAPI()입니다.그런 다음 표준 라이브러리 방법 대신 이 JSON 라이브러리를 사용합니다.표준 라이브러리로 복원하려면

토론 #1

토론 #2

를 사용하십시오. 봉인/해제를 교환할 충분한 이유가 있다고 생각하지 않습니다.당신은 하나를 제공할 수 있습니까?설령 우리가 이 길을 간다 하더라도, 나는 이런 전역 API 전환을 정말 좋아하지 않는다.json:@evanphx 우선, 이렇게 빨리 답장해 주셔서 감사합니다!
나는 문제 묘사에서 유한하게 용례를 묘사했다. #82. 그러나 여기에는 더 큰 해석이 있다.
기본적으로 표준 JSON 라이브러리에는 많은 Go 사용자가 필요로 하는 많은 기능이 부족하다. 이 점은 대량의 사용과 매우 설정 가능한 대체 JSON 라이브러리가 있다는 사실에서 증명할 수 있다.https://github.com/json-iterator/go
이 대체 라이브러리도 significantly faster than the standard library로 표시됩니다.
그러나 이 라이브러리의 가장 중요한 장점은 다음과 같은 기능을 필요에 따라 맞춤형으로 구성할 수 있다는 것입니다.
https://godoc.org/github.com/json-iterator/go#Config

맵키의 안정적인 정렬 - 표준 라이브러리에 알파벳/숫자 등 순서로 정렬할 수 있는 방법이 없습니다. 맵키를 통해 맵을 JSON

으로 정렬할 수 있습니다.

Go 태그의 선택적 포함 키/사용자 정의 태그 사용 - 일부 항목은 json-patch 이외의 다른 태그를 사용하여 서로 다른 장면에서 선택적 (취소) 그룹을 허용합니다. 예를 들어 '메타데이터' API 호출에서 (반대) 서열화할 때 구조 필드를 포함해야 하지만 '데이터' API 호출에서 (반대) 서열화할 때 이 필드를 포함해서는 안 됩니다.

그룹 해제 시 유효한 구조 필드

와 대응하지 않는 키를 건너뛰기
다음은 몇 가지 예이다.
따라서 json-patch json 교체기 라이브러리로 전환하기만 하면 될 수 있습니다. 그러나 변환jsonpatch은 json 교체기와 같은 설정 가능한 API를 제공하는 것이 여전히 중요합니다. 봉송/봉인 작업을 하기 전에 특정한 설정으로 API 실례를 만들고 이 API에 확장자를 등록해야 합니다.
저는 더 많은 질문에 대답하고 더 많은 배경을 제공하며 다른 방법으로 이 홍보를 처리하고 싶습니다. 하지만 제가 보고 싶은 관건은 다음과 같습니다.

JSON 라이브러리 대체 사용 능력: 만약에 우리가 JSON 교체기로만 전환하고 싶다면 된다. 그러나:

API 방법을 사용하기 전에 기초 json 라이브러리에 설정을 설정하는 능력 - 나는 jsonpatch 기초 json 라이브러리에 추가 설정을 추가할 때마다 더 많은 설정을 지원하기 위해 자주 업데이트하는 것을 원하지 않는다. 그래서 나는 jsonpatch 설정 가능한 json 라이브러리만 허용하는 것이 가장 간단하다고 생각한다.내가 걷는 길은 가장 간단하고 뚜렷한 분리인 것 같다.jsonpatch 호출할 수 있는 부분Marshal()과 Unmarshal()만 있으면 됩니다. 이 작업의 세부 사항은 jsonpatch의 문제가 아니라 다른 라이브러리의 문제이기 때문에 추가 설정 설정으로 과장하고 싶지 않습니다jsonpatch.IMOjsonpatch는 json 봉인/봉인 해제 행위가 아니라 병합/수리 기능에 대한 설정 설정만 있어야 한다.관심사 분리.

토론 #셋

좋은 정보를 제공해 주셔서 감사합니다. 궁금한 것은 왜 json 패치가 다른 json 패키지가 제공하는 추가 기능을 필요로 합니까?json 패치가 당신이 좋아하는 대체 패키지와 함께 사용할 때 어떤 기능을 제공했습니까?패치 프로그램의 행동을 바꾸지 않기 때문에, 키 정렬, 구조 처리는 상관없는 것 같습니다.

토론 #4

에 기술된 옵션이 실제로 이 패치의 행동을 바꾸었다.예를 들어 정렬 키가 있는 JSON 문서를 가져와 다른 정렬 키가 있는 JSON 문서에 통합하면 jsonpatch.MergePatch() 의 결과는 키가 정렬되지 않은 JSON 문서입니다.따라서 정렬된 키를 유지하는 유일한 대체 방법은 실행 MergePatch() 후 MergePatch() tje json-iterator 로 생성된 최종 문서에 대해 완전한 봉인/봉인 왕복을 실행하고 안정적인 키 정렬을 사용하는 것입니다.추가 봉인/해제 호출에 걸리는 추가 CPU 시간은 사용자의 시간을 낭비합니다. 매우 크거나 대량의 JSON 문서를 처리할 때 추가 시간이 누적됩니다.

토론 #5

이것은 이 가방의 버그처럼 들리는데 가능하면 지도 순서를 존중하지 않는다.이 오류를 복구하기 위해서, 통합 패치를 관리할 때 json-iterator 로 전환할 수 있습니다.

토론 #6

통합 패치를 관리할 때 json-iterator로 전환하고 SortMapKeys: true 구성을 사용할 수 있습니다.그러나 이것은 json-iterator가 지원하는 많은 설정 옵션 중의 하나일 뿐이다. 이 라이브러리는 이러한 옵션을 지원한다. 모든 옵션은 json-patch의 사용자와 관련이 있을 수 있다. 이 사용자는 JSON 문서의 봉인과 봉인 방식에 대해 매우 구체적인 요구를 가진다.앞서 설명한 바와 같이 다른 구성 옵션json-iterator은 다음을 포함한 MergePatch의 최종 출력에 영향을 미칩니다.

EscapeHTML: 부울 값.true인 경우 JSON 값의 HTML이 봉인 프로세서에서 이스케이프됩니다.

MarshalFloatWith6Digits: 부울 값.true인 경우 부동 소수점 서열화에 사용되는 자릿수를 사용자 정의합니다.

CaseSensitive: 부울 값.맵키는 대소문자를 구분하지 않아야 합니까? 아니면 대소문자를 구분해야 합니까?

OnlyTaggedField: 부울 값.봉인을 해제할 때 구조에서 태그 키(기본값: json가 사용되지 않은 키는 무시됩니다.

TagKey: 문자열.사용자 정의 구조 표시, 즉 json를 제외한 다른 내용을 사용하여 OnlyTaggedField가 사실이라면 구조상의 어떤 필드가 표시를 취소해야 하는지 확인할 수 있습니다.

이러한 구성 옵션 및 기타 옵션은 MergePatch 및 기타 json-patch API 메소드의 출력 동작에 영향을 미칩니다.
나는 json-patch 어떤 설정 속성을 사용해야 한다고 가정하고 싶지 않다.json-patch를 깔끔하고 간소화하고 제공하는 가치를 유지하기 위해 이 라이브러리의 사용자들이 사용할 사용자 정의 JSON 라이브러리를 지정해서 봉송/봉인을 어떻게 설정하는지 완전히 제어할 수 있도록 하는 것은 더욱 바람직하고 간단할 것 같다. 내가 이Pull 요청에서 제기한 것처럼.

토론 #7

이 문제에 대해 오랫동안 침묵해서 죄송합니다.나는 합병이 아니라 그것을 닫을 것이라고 생각한다.그 이유는 사용자가 서로 다른 json 모듈을 사용하여 서로 다른 일을 할 수 있도록 하기 때문이다. 이는 패치 처리 대상에 대한 가설 (키 순서 등 가설) 을 깨뜨리기 쉽기 때문에 가방을 더욱 취약하게 할 수 있다. 왜냐하면 가방에 대한 잘못된 사용을 의외로 장려하기 때문이다.
키 순서 같은 것과 관련이 있기 때문에, 나는 JSON 매핑을 키/값 구조의 일부분으로 관리하여 순서를 유지하는 것을 고려할 것이다.