향상된 ClickHouse: 개별 매개변수 지원 추가

묘사

는 최근의 재구성을 거쳐 독립된 매개 변수cmd,--secure,--multiline 등을 정확하게 처리하여 --multiquery의 생성을 간소화할 수 있다.
이 PR은 값이 없는 URL 매개변수 처리를 수행합니다.

토론 #1

이것?param은 문법이 표준적이지 않아서 좀 이상하다. 이것이 바로 내가 그것을 기록하지 않은 이유다.나는 지지?arbitrary-flag는 합리적인 행위라고 생각하지만 이미 알고 있는 표지?secure=true는 여전히 공식적이고 기록적인 행위일 것이다.
da00a957ac5d151896d0f9d0abcecf9e50c6037e를 보십시오. 이것은 당신에게 합리적인지 보십시오.나는 또한 --param=value 문법으로 전환할 것이다. 왜냐하면 --unknown-flag=true의 실패 방식은 --unknown-flag true보다 더 간단해야 하기 때문이다.

토론 #2

I'm also switching to --param=value syntax because --unknown-flag=true should fail in a less confusing way than --unknown-flag true.

네, = 매개 변수의 매개 변수에 대해 매우 합리적으로 보입니다!

This ?param syntax is nonstandard and kind of weird, which is why I left it undocumented. I think supporting ?arbitrary-flag is a reasonable behavior, but for known flags, ?secure=true should remain the official, documented behavior.

응, 나는 일치하지 않는다고 생각해.최근에 clickhouse-client 인터페이스는 어떤 방식으로든 변화가 발생할 수 있으며, 파라미터가 이미 알고 있거나 알 수 없기 때문에 그들의 행동은 다를 수 있다.나는 차라리 그것을 좋아하지 않겠다고 말하고 싶다.

Have a look at da00a95 and see if that looks reasonable to you.

불행히도https://github.com/tpope/vim-dadbod/commit/da00a957ac5d151896d0f9d0abcecf9e50c6037e#diff-206372fc5a380a2736d4903f9a3b4fc4c80c517d481946a0af6a9812c7acab57R22는 내가 보기에 매우 틀렸다.대부분의 clickhouse-client 매개 변수는 settings 문자열을 받아들이는 매개 변수입니다.빈 문자열 1, 2, 3 을 포함한 거의 모든 것이 될 수 있다.그리고 시작할 때 1 (심지어 전체 값) 인지 확인해도 예상대로 작동하지 않는다.예를 들어, true는 input-format-parallel-parsing의 유효한 매개변수입니다.
솔직히 말해서, 나는 클라이언트 2진법과 같은 의미를 사용하는 것보다 어떤 방식이 더 정확한지 모른다.
나는 방금 고http.Request가 있는 경우=와 없는 경우Empty의 행위를 검사했다.

vals: net/url.Values [
        "with-equal": [""],
        "without-equal": [""],
]
r.RequestURI: "/render/?with-equal=&without-equal"

네 말이 맞다. 표준으로 보면 그들은 같다.하지만 매개 변수와 아래의 매개 변수를 어떻게 구분하는지 모르겠습니다 =\
업데이트: 페이지에서 검색한 후에 문자열

토론 #셋

도 하나valid parameter인 것을 발견했습니다.1

Unfortunetely, da00a95#diff-206372fc5a380a2736d4903f9a3b4fc4c80c517d481946a0af6a9812c7acab57R22 looks very wrong to me. The most of clickhouse-client arguments are settings accepting strings. It can be almost anything including empty string 1, 2, 3. And checking it for 1 at the beginning (and even the whole value) won't work as expected. true is a valid parameter for input-format-parallel-parsing, for example.

조건문의 앞부분을 자세히 보아라.키가 5가지 특수 상황 중 하나가 아니라 ?param에 의해 생성되지 않은 경우=, 그렇지 않은 경우elseif는 이 clickhouse-client에 도달하지 못할 것이다.다음은 중복을 희생하는 대가로 더 명확한 버전이다.

    if k =~# '^\%(multiline\|multiquery\|time\|stacktrace\|secure\)$'
      if v =~# '^[1Tt]'
        call add(cmd, '--' . k)
      endif
    else
      if v is# 1
        call add(cmd, '--' . k)
      else
        call add(cmd, '--' . k . '=' . v)
      endif
    endif

This ?param syntax is nonstandard and kind of weird, which is why I left it undocumented. I think supporting ?arbitrary-flag is a reasonable behavior, but for known flags, ?secure=true should remain the official, documented behavior.

응, 나는 일치하지 않는다고 생각해.최근에 ?without-equal 인터페이스는 어떤 방식으로든 변화가 발생할 수 있으며, 파라미터가 이미 알고 있거나 알 수 없기 때문에 그들의 행동은 다를 수 있다.나는 차라리 그것을 좋아하지 않겠다고 말하고 싶다.
솔직히 말해서, 문제의 관건은 우리가 알 수 없는 검색 파라미터를 완전히 받아들이는 데 있다.유일하게 이 점을 해낼 수 있는 어댑터는 사용자의 공헌입니다. 저는 그렇게 까다롭지 않기로 결정했습니다.나는 이미 알고 있는 범위 내에서 제한하는 것을 지지한다.

I just checked how the go http.Request behaves with and without =:

vals: net/url.Values [ "with-equal": [""], "without-equal": [""], ] r.RequestURI: "/render/?with-equal=&without-equal"

You are right, by standard they are the same. But I don't know how then distinguish the parameter w/o the following argument. =\

그것보다 더 나쁘다.기준이 없다.다음은 루비의 작업입니다.

>> CGI.parse('with-equal=&without-equal')
=> {"with-equal"=>[""], "without-equal"=>[]}

그래서 나의 타협은 받아들이는 것이지만 격려하거나 의존하는 것은 아니다.좋은 아침, 팀.하룻밤의 토론을 거쳐 나는 너의 관점에 대해 더욱 분명하게 이해하게 되었다

Here's a version that might be a bit clearer, at the expense of repetition

이 판본은 확실히 작용할 것이다.patch의 조건은 설정되지 않습니다. 예를 들어

토론 #4

매개변수의 분기가 없기 때문입니다.미안하지만, 나의 견해는 분명하지 않다. 이것은 나의 관점이다.고쳐줘서 고마워요.

I'd support limiting to a known set.

나는 이 점을 안다.그럼에도 불구하고 CH는 매우 적극적으로 발전하는 프로젝트로 변화가 매우 격렬하다.이 해결 방안을 받아들여 주셔서 대단히 감사합니다!
나의 마지막 문제는 그것이 문서에 반영되지 않고 숨겨진 함수가 되어야 한다는 것이다.--ask-password

Good morning Tim. After taking the topic for a night, I have a clearer understanding of your point

Here's a version that might be a bit clearer, at the expense of repetition

이 판본은 확실히 작용할 것이다.patch의 조건은 설정되지 않습니다. 예를 들어

토론 #5

매개변수의 분기가 없기 때문입니다.미안하지만, 나의 견해는 분명하지 않다. 이것은 나의 관점이다.고쳐줘서 고마워요.
이 두 조건은 반드시 같은 결과를 만들어야 한다.동의하지 않을 경우 전체 URL로 반례를 제공합니다.

I'd support limiting to a known set.

나는 이 점을 안다.그럼에도 불구하고 CH는 매우 적극적으로 발전하는 프로젝트로 변화가 매우 격렬하다.이 해결 방안을 받아들여 주셔서 대단히 감사합니다!
나의 마지막 문제는 그것이 문서에 반영되지 않고 숨겨진 함수가 되어야 한다는 것이다.
URL의 목적은 데이터베이스에 연결하는 방법을 지정하는 것이지, 임의의 클라이언트 행동을 지정하는 것이 아니다.그래서 실제로 유일하게 기록된 매개 변수는 --ask-password일 것이다.고급 용례의 발표 가치로서, 나는 secure 막후에서 일하는 것에 동의하지만, 문서에서 그것을 삭제할 것이다.format

The two conditionals should produce identical results. If you disagree, please provide a counterexample in the form of a complete URL.

니가 맞았어.나는

토론 #6

regexp와 일치할 줄 몰랐다.이것은 내가 오늘 배운 새로운 것이다. 고마워.
만약 네가 너의 지점을 대사로 합병할 수 있다면 나는 감격을 금할 수 없을 것이다.int 1가 합병되었다.
2021년 5월 7일 금요일 오전 9:56 미하일 f. 히리아예프 @.**>
쓰기:

Closed #90 https://github.com/tpope/vim-dadbod/pull/90.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tpope/vim-dadbod/pull/90#event-4702129438, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAC6UWQQUPCFQYXZACTADTMPWSJANCNFSM44HMV4HQ .