Mongoose: 어떤 ES6이 라이브러리 몽구스가 사용하는지 지정하는 기능

모든 데이터베이스 작업이 완료된 후 무언가를 수행하기 위해 Promise.all()을 사용할 수 있기를 정말로 고대하고 있습니다.

:+1:

https://github.com/LearnBoost/mongoose/issues/1699 에서 명확하지 않은 한 가지는 구현이 기본값이 될 것입니다.

역방향 릴리스가 아니라는 점을 감안하면 mpromise가 기본값이 되어야 하지만 재정의할 수 있습니다.

+1

:+1:

해킹당하는 지점이 있나요? 나는 mpromise가 있는 오류 처리 흐름을 참을 수 없으며 이것이 어떻게 되는지 보기 위해 소스를 열려고 합니다.

약속하다:

  query.exec()
    .then(function(ou) {
      if(!ou) {
        return next(new errors.http.NotFound('The specified OU was either not found, or your credentials lack the required permissions to view it.'));
      }

      res.send(ou);
    }, next)
    .end(next);

거부를 처리하고 end 도 넣어야 합니다. end 가 없으면 예외(예: NotFound 클래스의 철자가 틀리는 경우)는 조용히 삼켜지고 표현은 중단됩니다.

파랑새:

  query.exec()
    .then(function(ou) {
      if(!ou) {
        return next(new errors.http.NotFound('The specified OU was either not found, or your credentials lack the required permissions to view it.'));
      }

      res.send(ou);
    })
    .catch(next);

promisifyAll(require('mongoose')) 하는 것은 실제로 지금까지 Mongoose 4와 함께 작동하는 것 같습니다. 이것을 다루는 회귀 테스트가 너무 표적이 됩니까?

지금은 아닙니다. 대부분의 작업은 #2754 및 vkarpov15 /kareem#2에 따라 kareem 모듈에서 이루어집니다. 왜냐하면 그렇게 하면 한 돌로 두 마리의 새를 죽이고 후크와 약속을 만들기 위해 작성된 정말 지저분한 포인트 컷 넌센스를 제거할 수 있기 때문입니다. 협력. 그래도 자유롭게 해보십시오. 저는 PR에 열려 있습니다.

하지만 다른 Promise 라이브러리를 계속 지원해야 하는 이유는 무엇입니까? ES6 Promises 사양은 이제 확고하고 여기에 머물 것입니다. 이전 버전의 노드에서 사용할 수 없을 때 로드된 폴리필과 함께 순수한 ES6 약속을 사용할 수 없습니까?

그렇다면 시도해 볼 수 있습니다.

요점은 원하는 ES6 호환 가능한 Promise 라이브러리를 사용할 수 있다는 것입니다. 많은 사람들이 when, q, rsvp 등에 여전히 많은 투자를 하고 있으며 각 라이브러리에는 일반 폴리필이 포착하지 못하는 고유한 특성이 있습니다.

나는 다른 제안에 열려 있습니다. 나는 특별히 약속을 좋아하지 않거나 사용하지 않습니다. 이 기능은 사람들이 "약속으로 블루버드 기능 X 지원" 또는 "네이티브 rsvp.js 지원"을 요청하는 것과 관련된 문제가 산적해 있다는 사실에 동기를 부여받았습니다. " 그리고 사람들이 자신의 약속 라이브러리를 파티에 가져오도록 하는 것이 이러한 문제를 종결하는 가장 쉬운 방법입니다.

무슨 말인지 알겠다. 저는 Promises의 큰 사용자이자 지지자입니다. 기준을 적용하는 것이 바람직하다고 생각합니다.
A+ 약속은 ES6의 필수 요소로 선택되었습니다. ES6 호환되지 않는 노드 버전(예: https://github.com/jakearchibald/es6-promise)에 대한 지원을 보장하기 위해 폴리필을 제안했습니다.

ES6 Promise와 호환되고 혼합될 수 있도록 다른 Promise 라이브러리의 손에 있어야 합니다.

편집하다:
그리고 현재 API가 중단되지 않았습니까? 아니면 제가 놓치고 있는 것이 있습니까?

Promises/A+ 사양은 ES6 Promise 사양과 매우 다르며, 이는 이전 주석에서 나열한 Promise 라이브러리와도 다릅니다. 수많은 Promise 라이브러리가 모두 ES6으로 통합된다면 나에게는 좋을 것이지만, 나는 그것이 일어날 수 있을지 의문입니다. 왜냐하면 오픈 소스의 아름다움은 Promise를 사랑하는 일부 사람들이 추가 기능을 원하고 자신의 Promise를 작성할 것이기 때문입니다. 도서관.

현재 API에 대한 주요 변경 사항은 없습니다. 제가 생각하는 것은 mongoose.set('Promise', require('bluebird')); 또는 이와 유사한 것을 말하는 방법이므로 옵트인이 되고 mpromise가 기본값이 될 것입니다.

아 맞다, 실수해서 미안해.
현재 구현과 다른 약속 라이브러리를 살펴보았습니다.

나는 다음과 같은 것을 만들 수 있다고 생각합니다.

mongoose.set('Promise', Promise);

mongoose.set('Promise', require('bluebird'));

mongoose.set('Promise', require('q').defer());

mongoose.set('Promise', require('when').defer());

// and so on...

따라서 기본적으로 resolve 및 reject 메서드가 있는 선택 개체의 약속을 몽구스에 노출해야 합니다.

이것이 당신이 염두에 두었던 것입니까? 그렇다면 풀 리퀘스트로 작업하겠습니다.

편집하다:
mongoose.set('Promise', Promise); 를 작성하는 것은 매우 어리석은 일입니다. ES6이 기본이어야 하며 선택한 라이브러리를 사용할 수 있어야 한다고 생각합니다(ES6 Promises를 사용할 수 없을 때마다 mpromise).

물론입니다. 도와주시면 감사하겠습니다. 까다로운 부분은 1) 후크로 작동하게 하는 것입니다. vkarpov15/kareem#2를 참조하십시오. 2) mpromise와 역호환되도록 만드는 것입니다.

또한 re: Q, ES6 사양에 가장 가까운 Q 구문이므로 require('q').Promise 를 사용합니다.

입력해 주셔서 감사합니다. 경쟁 풀 리퀘스트 또는 지속적인 PR을 선호합니까?

완성된 것이 더 낫지만 항상 몇 가지 제안이 있을 것입니다. 막히면 알려주세요

이 기능에 대해 +1입니다. 나는 블루버드와 함께 사용하고 싶습니다

과감한 것에 대해 유감스럽게 생각합니다. 그러나 대안적인 접근 방식은 promise 지원을 완전히 사용하지 않는 것입니다. 그것은 다른 라이브러리의 지원을 요청하는 약속을 사용하는 모든 사람을 막을 것입니다.
bluebird와 같은 강력한 promise 라이브러리를 사용하는 사람들은 콜백 API를 노출하고 bluebird가 이를 0 비용으로 간단하게 래핑할 수 있기 때문에 어쨌든 계속 사용할 수 있습니다. 어쨌든 수동으로 지원하는 오류가 발생하기 쉽습니다.

@benjamingr 100% 동의하지 않습니다. 이제 iojs와 NodeJ가 Node 3.0으로 병합되면서 ES6 Promises 및 Generators가 지원됩니다.

지원을 중단하는 것은 엄청난 후퇴가 될 것입니다.

즉, Promise.promisifyAll(require("mongoose")) 는 표준에 부합하는 Mongoose용 빠른(수동 시도보다 빠른) 래퍼를 생성하고 이에 대해 아무 조치도 취하지 않고도 모든 API를 둘러싸고 있습니다. 사실, export 객체에 Promise.promisifyAll 를 직접 하고 bluebird Promise와 Dual Promise 메소드 (save - saveAsync) 를 무료로 노출시킨 다음 실제 작업을 하지 않고도 bluebird Promise 인터페이스를 노출한다고 말할 수 있습니다.

그래서 제가 bluebird promise를 사용하는 동안 두 개의 인터페이스로 코딩하여 코드를 복잡하게 만드는 것보다 문서의 섹션에서 이 모든 것을 수정할 수 있다고 생각합니다.

@albertorestifo 는 실제로 삭제되지 않는다는 점을 제외하고는. 나는 약속이 무엇인지 잘 알고 있으며(스택 오버플로에서 1500포인트 이상 500 답변:P) io.js에서 작동하는 방식의 일부에 대해서도 책임이 있습니다(예: https://github.com/ nodejs/io.js/issues/256).

그렇다고 해서 @vkarpov15 가 약속을 사용하지 않기 때문에 자신의 라이브러리에서 약속을 지원할 필요가 없다고 생각한다는 사실은 변하지 않습니다. mongoose가 제공하지 않더라도 쉽게 mongoose와 함께 promise를 사용할 수 있습니다. 내부적으로 지원을 구현하는 mongoose는 유지 관리가 더 많고 느리고 오류가 발생하기 쉽습니다. @vkarpov15 는 콜백 API 작업을 계속할 수 있으며 사용자는 Mongoose를 쉽게 하나의 라이너로 프라미스로 묶을 수 있다고 약속합니다.

@benjamingr 는 외부 Promise 라이브러리를 사용한다고 가정합니다. 나는 사양에 있는 것을 고수하고 있습니다. 여러분도 잘 아시겠지만 래퍼가 없습니다.

나는 당신의 요점을 봅니다. 둘 다 지원하면 엄청난 혼란이 발생합니다. 저는 개인적으로 콜백을 싫어하므로 대신 콜백을 삭제합니다. 하나는 생성기와 약속을 사용하고 다른 하나는 콜백을 사용하는 두 개의 별도 리포지토리가 있어야 합니다. 둘 다 동일한 구조와 API를 최대한 가깝게 유지합니다.

@benjamingr 는 외부 Promise 라이브러리를 사용한다고 가정합니다. 나는 사양에 있는 것을 고수하고 있습니다. 여러분도 잘 아시겠지만 래퍼가 없습니다.

느리고 디버그하기 어렵고 기능이 덜 풍부한 구현을 사용하기로 선택한 경우 당연히 선택해야 합니다. 그러나 그것이 래퍼와 어떤 관련이 있습니까? 기본 약속*을 사용하여 bluebird의 promisifyAll 와 유사한 래퍼를 작성하는 것은 매우 쉽습니다.

별도의 패키지로 몽구스의 약속이 활성화된 버전을 원한다면 다음과 같이 할 수 있습니다.

• 1단계, 좋아하는 편집기를 열거나 괜찮은 편집기만 엽니다.
• 2단계, module.exports = require("bluebird").promisifyAll(require("mongoose")) 입력
• 3단계, 적절한 package.json 파일을 만들고 npm에 게시합니다.
• 4단계, 수만 다운로드.

이제 "네이티브 프라미스를 사용하지 않는다"고 생각하는 것을 압니다. 여전히 Promise 프로토타입에서 then 및 catch 를 제외한 모든 메소드를 삭제할 수 있고 all 및 race from Promise 그리고 동일한 API로 끝납니다. 또는 사람들에게 기본 약속을 내보내고 있다고 말할 수 있습니다. 그들은 단지 두 개의 Promises/A+ 구현이기 때문에 알지 못할 것입니다. 약속합니다 ;)

(* 빠르게 작성하는 것은 사용자 수준에서 더 어렵습니다. 왜냐하면 지금 당장 Promise를 생성하는 빠른 방법이 없기 때문에 io.js가 결국 promisify 함수 자체를 내보낼 가능성이 있기 때문입니다. 어쨌든 천천히).

확실히 괜찮은 대안입니다. 좋든 싫든 사용자가 몽구스를 사용하는 방식이기 때문에 사내에서 약속을 지키고 싶습니다. 몽구스와 함께 약속 라이브러리 X를 사용합니다." 개별 모듈로 연결을 끊을 때의 단점은 "이 버전의 mongoose-promise는 mongoose 3.8에서만 작동하고 이것은 mongoose >= 4.1에서 작동합니다"라고 말하는 것이 까다롭고 mongoose가 중요한 약속 래퍼를 깨는 것을 피하기가 어렵다는 것입니다. .

확실히 괜찮은 대안입니다. 좋든 싫든 사용자가 몽구스를 사용하게 될 것이기 때문에 사내에서 약속을 지키고 싶습니다.

테스트 커버리지를 원하거나 필요로 하는 이유는 무엇입니까? 코드에서 약속 자체를 테스트하는 것은 의미가 없습니다. 라이브러리에는 이미 테스트가 있습니다. 이것은 사용할 때 http 모듈을 테스트하는 것과 같습니다.

그리고 몽구스가 가장 중요한 약속 래퍼를 깨는 것을 피하기가 어렵습니다.

Bluebird는 정말 간단한 작업을 수행합니다. 프로토타입을 찾은 다음 Async 접미사가 있는 메서드를 추가합니다. 이것은 정말 간단하고 실제로 잘 작동합니다. Mongoose를 포함한 대부분의 라이브러리가 있는 하나의 라이너이며 중단되지 않았습니다. 지난 1년 동안 나를 위해 한 번이라도.

잠재적으로 오류가 발생하기 쉬운 많은 스티칭 코드를 유지하려는지 잘 모르겠습니다. 두 개의 API를 수동으로 지원해야 하는 경우가 많은 작업처럼 들리고 작업을 중단할 수 있습니다. bluebird의 promisifyAll 코드를 "빌려" 하고 다른 Promise 라이브러리(결국 오픈 소스임)와 함께 작동하도록 조정하지만 수동으로 하지는 않을 것입니다.

"이 버전의 mongoose-promise는 mongoose 3.8에서만 작동하고, 이것은 mongoose >= 4.1에서 작동합니다." 그리고 몽구스가 가장 중요한 약속 래퍼를 깨는 것을 피하는 것은 어렵습니다.

글쎄요, 약속이 자동이라면 일어나야 하는 획기적인 변화의 예를 들어주시겠습니까?

1) 사용자가 사용하는 방식을 테스트하고 싶습니다.

2) 게으르고 피하고 싶지만 대부분의 다른 약속 라이브러리에는 promisifyAll에 해당하는 것이 없다는 것을 이해합니다. 이것이 "Xpromise 기능 Y 지원"이 가장 인기 있는 몽구스 기능 요청인 이유라고 생각합니다. 게다가, 우리는 Bluebird의 약속을 다시 작성할 생각이 없습니다. 단지 mongoose 함수가 기본적으로 약속을 반환하도록 하기만 하면 됩니다.

3) 약속의 구현 및 사용 방법에 따라 다릅니다. :)

1) 사용자가 사용하는 방식을 테스트하고 싶습니다.

사용자가 사용하는 방식을 테스트한다는 것은 무엇을 의미합니까? 콜백에 대한 비유를 보여줄 수 있습니까?

2) 게으르고 피하고 싶지만 대부분의 다른 약속 라이브러리에는 promisifyAll에 해당하는 것이 없다는 것을 이해합니다. 이것이 "Xpromise 기능 Y 지원"이 가장 인기 있는 몽구스 기능 요청인 이유라고 생각합니다. 게다가, 우리는 Bluebird의 약속을 다시 작성할 생각이 없습니다. 단지 mongoose 함수가 기본적으로 약속을 반환하도록 하기만 하면 됩니다.

다시 작성할 필요가 없습니다. 가져갈 수 있습니다. 일반 구현이 더 느리기 때문에 일반이 아닙니다.

널리 사용되는 기능을 수동으로 구현하지 않는 것도 게으름이 아닙니다. NodeJS는 코어에 익스프레스를 넣지 않기 때문에 게으른가요? TC39는 핵심에 밑줄을 넣지 않아 게으른가요? 규칙(콜백)을 고수함으로써 사용자에게 원하는 동시성 프리미티브를 사용할 수 있는 기능을 제공합니다.

3) 약속의 구현 및 사용 방법에 따라 다릅니다. :)

글쎄, bluebird의 약속, 또는 Q's 또는 When's - 구현은 다르지만 모두 동일한 작업을 수행합니다. 따라서 원하는 것을 선택하십시오. 어떻게 깨질지 궁금합니다.

이 토론에서 제가 놓치고 있는 한 가지가 있습니다.

mongoose가 표준 약속(ES6 기본 구현을 의미함)을 반환하는 경우 ES6 호환 Promise 라이브러리와 호환되어야 하지 않습니까? Promise.all([model.query().exec(), ...]) 는 물론이고 동등할 때 블루버드 q도 할 수 있습니다.

그렇다면 콜백과 표준 프라미스를 반환하고(지금 하고 있지만 약속을 "제거"하는 것처럼) 사용자가 즐겨 사용하는 프라미스 라이브러리를 사용하도록 하는 것은 어떻습니까? 아니면 내가 여기서 뭔가를 놓치고 있습니까?

@albertorestifo 글쎄요, 네이티브 프라미스는 현재 느리고 사용자 영역 라이브러리와 동등한 수준에 도달하기까지 잠재적으로 몇 년이 걸릴 것입니다. 주로 그렇습니다.

@benjamingr 당신은 몇 가지 좋은 점을 지적합니다. mongoose 약속의 주요 요점은 다른 라이브러리 없이 mongoose 비동기 작업과 함께 yield 를 사용할 수 있도록 하는 것이므로 가까운 미래에 대한 약속을 유지하고 있습니다. IMO는 앞으로 몽구스 코어의 일부가 되어야 합니다.

Q 또는 언제 약속 기능이 있습니까?

Q 또는 언제 약속 기능이 있습니까?

네, 제가 아는 거의 모든 널리 퍼진 promise 라이브러리는 일종의 약속을 제공합니다.

다음은 언제입니다: https://github.com/cujojs/when/blob/master/docs/api.md#nodeliftall
여기 Q: https://github.com/kriskowal/q/wiki/API-Reference#qnfbindnodefunc -args

네이티브 프라미스에는 아직 없지만 작업 중입니다. 프라미스 생성을 위한 빠른 경로(즉, 프라미스 생성자가 아님)가 존재하면 NodeJS는 네이티브 프라미스에 대해 코어에서 이를 지원할 가능성이 높습니다. 사용자 영역에서 _빠른_ 수행).

mongoose 약속의 주요 요점은 다른 라이브러리 없이 mongoose 비동기 작업과 함께 yield를 사용할 수 있도록 하는 것입니다.

어쨌든 promise와 함께 의미 있는 방식으로 yield 를 사용하려면 라이브러리가 필요합니다. 발전기를 비동기 함수로 펌프하는 9 LoC를 직접 작성할 수 있다면 확실히 promisify를 작성할 수 있습니다. 그리고 대부분의 사용자와 같다면 어쨌든 라이브러리를 사용합니다.

나는 확실히 Mongoose에서 약속을 허용하고 싶은/필요한 것을 알고 있습니다. 그것들은 앞으로 나아갈 길이며 언어가 현재 동시성을 수행하는 방법이지만 솔직히 방법별로 수동으로 수행하는 것이 고통스러울 것이라고 생각합니다. 문서의 "promise와 함께 사용" 또는 "제너레이터와 함께 사용" 섹션에서 라이브러리를 사용하여 수행하는 방법을 보여주는 것이 도움이 될 수 있습니다.

문제는 이미 방법별로 수행했기 때문에 내부 약속 래퍼를 수정하기만 하면 됩니다. 어느 쪽이든 5.0까지는 핵심에서 약속을 완전히 제거할 수 없습니다. 나는 그것을 더 이상 사용하지 않는다는 생각에 동의합니다. @benjamingr 는 내가 면밀히 고려해야 할 몇 가지 좋은 주장을 하지만 다음 단계는 어쨌든 #2688이 될 것이라고 생각합니다.

당신은 분명히 Mongoose에 대한 더 많은 경험이 있고 더 중요한 것은 사용자이기 때문에 그 선택을 이해합니다. 들어주셔서 감사합니다.

나는 "its"를 입력했지만 내 iPhone은 "it's"로 자동 수정되어야 한다고 느꼈고 GitHub는 주석 편집이 흥미로운 사용 사례가 아니라고 느꼈습니다. 이중댓글 스팸 죄송합니다:)

댓글 오른쪽 상단의 연필을 클릭하면 웹사이트의 댓글을 수정할 수 있습니다.

저는 항상 진심 어린 토론, 특히 저에게 새로운 것을 가르쳐주는 토론에 열려 있습니다.

미래는 기본 약속에 속하는 것 같습니다. Mongoose는 mongo ops의 산업 표준이며 표준 약속에 의존하는 것도 완전히 유효합니다.

표준 약속은 필연적으로 성숙하고 어떤 프레임워크보다 널리 보급될 것입니다. 그것들을 사용하는 겸손한 +1.

@iliakan 아마도 미래에. 2016년 중반까지는 기본 프라미스가 "표준"이 될 것으로 기대하지 않습니다. 다양한 단편화된 프라미스 라이브러리가 너무 깊이 자리 잡고 있고 미묘한 단점이 너무 많습니다. 어느 쪽이든, 몽구스는 대대적인 역전 변경 없이 '기본적으로 기본'으로 전환할 수 없습니다.

@vkarpov15 확실히 이해합니다.

그 동안 유익할 수 있는 것 - 약속과 기본 약속 사이의 주요 비호환성을 간략하게 설명하는 간단한 페이지입니다. 적어도 mpromise 로 시도해서는 안 되는 것들 ;)

지금 당장은 catch 가 없다는 것을 이해합니까? 그것이 모든 제한 사항입니까?

ES6 API에 대해 자세히 알아보지 못했습니다. mpromise는 Promises/A+ 를 구현하고 .catch (), 긴 스택 추적 등을 의미하지 않습니다. 기본적으로 .then() 가 아닌 모든 것은 mpromise의 구현 범위를 벗어납니다.

일반적으로 Promises/A+를 구현하는 것은 높은 수준의 관점에서 ES6 promise도 구현하지만 그 반대는 사실이 아닙니다. Promises/A+는 저수준 구현 세부 사항에 대해 매우 구체적입니다. 예를 들어, bluebird는 Promises/A+를 정확히 따르지 않으며 다른 일반적인 promise 라이브러리에 대해서는 확실하지 않지만 사양을 준수하지 않는다고 확신합니다. 그들만의 독특한 방식. 이것이 이것을 특히 까다롭게 만드는 것입니다.

이제 블루버드와 네이티브 프라미스를 사용할 수 있습니까?

네 require('mongoose').Promise = global.Promise 는 몽구스가 네이티브 프라미스를 사용하게 합니다. 모든 ES6 약속 생성자를 사용할 수 있어야 하지만 지금은 네이티브, 블루버드 및 Q 로만 테스트합니다.

@vkarpov15 멋지네요 ! 정말 고맙습니다!

@vkarpov15 감사합니다! 잘 했어!

네, 확실히. 정말 멋지네요! :)

@vkarpov15 정말 멋지네요