Knex: upsert 유형 기능 추가

동의합니다. 이 기능은 _좋을 것입니다_!

:+1:

:+1:

CSV에서 일부 데이터를 가져오고 있는데 마지막 가져오기에서 일부 레코드가 겹칠 가능성이 높습니다(예: 마지막으로 가져온 것은 1월 1일부터 5월 31일까지, 이번에는 5월 31일부터 6월 18일까지 가져옴).

다행히 타사 시스템은 안정적으로 고유한 ID를 할당합니다.

새 레코드를 삽입하고 이전 레코드를 업데이트하는 가장 좋은 방법은 무엇입니까?

나는 아직 그것을 시도하지 않았지만 다음과 같을 것이라고 생각했습니다.

var ids = records.map(function (json) { return json.id })
  ;

Records.forge(ids).fetchAll().then(function () {
  records.forEach(function (record) {
    // now the existing records are loaded in the collection ?
    Object.keys(record).forEach(function (key) {
      Records.forge(record.id).set(key, record[key]);
    });
  });
  Records.invokeThen('save').then(function () {
    console.log('Records have been either inserted or updated');
  });
});

또한 때로는 내가 저장하고 있는 것이 해시와 같은 확정 id 값으로 저장됩니다. 이 경우 데이터를 추가하거나 교체하기만 하면 됩니다.

나는 항상 SQL을 전통적인 SQL로 사용하지 않습니다. 종종 명확한 관계 매핑 및 인덱스의 이점과 함께 하이브리드 NoSQL로 사용합니다.

:+1:

안녕,
이 새로운 기능에 대한 소식이 있습니까?

아니면 누군가 mysql에 대해 이 기능을 시뮬레이션하는 방법을 보여주는 예제를 추천할 수 있습니까?

고마워

지금은 raw 를 사용하고 있지만 곧 여기에서 사용할 수 있도록 열심히 노력하고 있습니다.

Postgres는 방금 upsert 지원을 구현했습니다. +1:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=168d5805e4c08bed7b95d351bf097cff7c07dd65

https://news.ycombinator.com/item?id=9509870

구문은 INSERT ... ON CONFLICT DO UPDATE 입니다.

MySql에서 REPLACE INTO 를 수행하는 방법을 찾고 있었는데 이 기능 요청을 찾았습니다. REPLACE 및 INSERT 는 MySql에서 정확히 동일한 구문을 가지고 있기 때문에 ON DUPLICATE KEY UPDATE 보다 구현하기가 더 쉽다고 상상할 수 있습니다. REPLACE 를 구현할 계획이 있습니까? PR이 가치 있는 것입니까?

특히 PostreSQL 9.5에서 이에 대한 업데이트가 있습니까?

한 가지 중요한 질문은 PostgreSQL 및 MySQL과 같은 다른 방언에 대해 동일한 upsert 메서드 서명을 노출할지 여부입니다. Sequelize에서 upsert 의 반환 값과 관련하여 문제가 발생했습니다: https://github.com/sequelize/sequelize/issues/3354.

일부 KnexJS 라이브러리 메서드는 다른 방언의 컨텍스트에서 반환 값과 관련하여 구별이 있음을 알고 있습니다(예: insert , 여기서 첫 번째 삽입된 ID의 배열이 Sqlite 및 MySQL에 대해 반환되는 반면 모든 배열은 삽입된 ID는 PostgreSQL과 함께 반환됩니다).

설명서에 따르면 MySQL의 INSERT ... ON DUPLICATE KEY UPDATE 구문에는 다음과 같은 동작이 있습니다(http://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate.html).

ON DUPLICATE KEY UPDATE를 사용하면 행당 영향을 받는 행 값은 행이 새 행으로 삽입되면 1, 기존 행이 업데이트되면 2, 기존 행이 현재 값으로 설정된 경우 0입니다.

PostgreSQL에서 (http://www.postgresql.org/docs/9.5/static/sql-insert.html):

성공적으로 완료되면 INSERT 명령은 다음 형식의 명령 태그를 반환합니다.

INSERT oid count

count는 삽입되거나 업데이트된 행의 수입니다. count가 정확히 1이고 대상 테이블에 OID가 있는 경우 oid는 삽입된 행에 할당된 OID입니다. 단일 행이 업데이트되지 않고 삽입되어야 합니다. 그렇지 않으면 oid는 0입니다.

INSERT 명령에 RETURNING 절이 포함된 경우 결과는 명령에 의해 삽입되거나 업데이트된 행에 대해 계산된 RETURNING 목록에 정의된 열과 값을 포함하는 SELECT 문의 결과와 유사합니다.

이 경우 RETURNING 절로 반환값을 변경할 수 있습니다.

생각?

나는 삽입을 위한 "onConflict" 메소드를 추가하기 위해 Client_PG를 원숭이 패치했다. github oauth 자격 증명을 upsert하려는 경우 다음과 같이 쿼리를 작성할 수 있습니다.

const profile = {
    access_token: "blah blah",
    username: "foobar",
    // ... etc
  }

  const oauth = {
    uid: "13344398",
    provider: "github",
    created_at: new Date(),
    updated_at: new Date(),
    info: profile,
  };

  // todo: add a "timestamp" method

const insert = knex("oauths").insert(oauth).onConflict(["provider", "uid"],{
  info: profile,
  updated_at: new Date(),
});

console.log(insert.toString())

열 이름의 배열은 고유성 제약 조건을 지정합니다.

insert into "authentications" ("created_at", "info", "provider", "uid", "updated_at") values ('2016-02-14T14:42:18.342+08:00', '{\"access_token\":\"blah blah\",\"username\":\"foobar\"}', 'github', '13344398', '2016-02-14T14:42:18.342+08:00') on conflict ("provider", "uid")  do update set "info" = '{\"access_token\":\"blah blah\",\"username\":\"foobar\"}', "updated_at" = '2016-02-14T14:42:18.343+08:00'

원숭이 패치에 대한 요점: https://gist.github.com/hayeah/1c8d642df5cfeabc2a5b 를 참조하세요.

이것은 매우 해킹된 실험입니다... 따라서 원숭이 패치를 프로덕션 코드에 정확히 복사하여 붙여넣지 마십시오. p

알려진 문제:

• QueryBuilder에 있는 원숭이 패치는 Client_PG가 빌더를 전문화하지 않기 때문에 모든 방언에 영향을 줍니다.
• count = count + 1 와 같은 원시 업데이트를 지원하지 않습니다.
• 쿼리 메서드가 삽입되지 않으면 onConflict가 발생해야 합니다.

피드백?

@hayeah 나는 당신의 접근 방식을 좋아하고 Postgres에 적합합니다. 나는 당신이 지적한 것 이외의 다른 문제를 경험적으로 감지할 수 있는지 확인하기 위해 프로젝트에서 원숭이 패치를 시도할 것입니다.

구문 제안: knex('table').upsert(['col1','col2']).insert({...}).update({...}); 여기서 upsert 는 조건문을 사용합니다. 이 방법은 db에 국한되지 않습니다.

upsert의 다양한 구현에 대한 요약은 https://en.wikipedia.org/wiki/Merge_(SQL )에서 찾을 수 있습니다.

저도 이 능력에 관심이 있습니다. 사용 사례: 외부 서비스의 많은 외부 데이터에 의존하는 시스템 구축 로컬 MySQL db에 저장하는 데이터에 대해 주기적으로 폴링합니다. 아마도 지금은 knex.raw를 사용할 것입니다.

또한 관심이 있지만 내 사용 사례에서는 열에 항상 '고유' 제약 조건이 있는 것은 아니므로 충돌을 기반으로 하지 않는 방식으로 작동해야 합니다. 존재하는 경우 쿼리와 일치하는 항목을 업데이트하기만 하면 됩니다. 그렇지 않으면 삽입 새 행.

@haywirez 고유 제약 조건이 없는 이유가 궁금합니다. 당신은 경쟁 조건에 노출되지 않을까요?

@hayeah 나는 주어진 날짜에 연결된 값이 있는 항목을 저장하는 시간 창 데이터에 대한 특정 사용 사례가 있습니다. 따라서 일치하는 (일) 타임스탬프의 "결합된 키"와 다른 테이블의 PK에 해당하는 두 개의 다른 ID가 있는 항목을 삽입하고 업데이트합니다. 24시간 이내에 삽입하거나 최신 카운트로 업데이트해야 합니다.

이것은 좋은 기능이 될 것입니다!

여기에 댓글을 달아주신 모든 분들 안녕하세요. PRPlease 레이블을 추가하고 있습니다.

이 기능을 추가하는 PR을 하게 되어 기쁩니다. 하지만 먼저 여기에서 원하는 API에 대한 토론을 보고 싶습니다.

추신.

^^ 동의합니다.

나는 이와 같은 댓글을 삭제할 것입니다. +1을 추가하려면 작은 이모티콘 반응으로 그렇게 하세요.

@willfarrell 및 @hayeah 의 예에서와 같이 열 제한 배열에 약간의 문제가 있습니다. 이러한 예가 json 속성을 지원할 수 있는지 확실하지 않습니다. 이러한 제안 중 어느 것도 레코드와 일치하는 where 문/적절한 "쿼리"를 포함하지 않는 이유가 있습니까?

제안 1

knex('table')
  .where('id', '=', data.id)
  .upsert(data)

제안 2

knex('table')
  .upsertQuery(knex => {
    return knex('table')
      .where('id', '=', data.id)
  })
  .upsertUpdate(knex => {
    return knex('table')
      .insert(data)
  })

제안 3

knex('table')
  .where('id', '=', data.id)
  .insert(data)
  .upsert() // or .onConflictDoUpdate()

나는 3과 같은 것에 가장 많이 기울고 있다.

여기에 mongodb가 수행하는 방법을 추가하기만 하면 됩니다 .

db.collection.update(
   <query>,
   <update>,
   {
     upsert: <boolean>,
     multi: <boolean>,
     writeConcern: <document>
   }
)

@reggi 내 원숭이 패치가 where 와 호환된다고 생각합니다 ...

@reggi 나는 당신의 요점을 이해하지 못합니다.
@willfarrell 및 @hayeah 의 예에서 제안된 접근 방식에서 어떤 기능이 누락되었는지 자세히 설명할 수 있습니까?
왜 where 이 필요합니까?
insert 작업일 뿐입니다.

@reggi 제공한 MongoDB 예제는 "먼저 UPDATE WHERE 시도 ... 쿼리와 일치하는 문서가 없으면 INSERT 수행"을 읽는 반면 SQL UPSERT는 "INSERT INTO ... 이 기본 키가 있는 행이 이미 있는 경우 UPDATING"이라고 읽습니다. .
따라서 SQL 데이터베이스에서 구현되는 것과는 완전히 다른 "업서트"에 대해 이야기하고 있는 것 같습니다.

나는 이 API를 제안할 것이다:

knex.createTable('test')
   .bigserial('id')
   .varchar('unique').notNull().unique()
   .varchar('whatever')

knex.table('test').insert(object, { upsert: ['unique'] })

.insert() 함수는 두 번째 매개변수를 분석합니다.
문자열이면 이전 returning 매개변수입니다.
객체인 경우 options.returning 및 options.upsert 가 있는 options 매개변수입니다. 여기서 options.upsert 는 고유 키 목록입니다. 복합 고유 키 제약 조건의 경우).
그런 다음 object 에서 기본 키와 모든 options.upsert 키를 제외하고 ( clone(object) && delete cloned_object.id && delete cloned_object.unique 를 통해) 제거된 cloned_object 를 사용하는 SQL 쿼리가 생성됩니다. SQL 쿼리의 두 번째 부분에서 SET 절을 구성하기 위한 기본(및 고유) 키: ... ON CONFLICT DO UPDATE SET [iterate cloned_object] .

그것이 현재 API와 동질적인 가장 간단하고 모호하지 않은 솔루션이 될 것이라고 생각합니다.

@slavafomin @ScionOfBytes API도 아직 합의되지 않은 것 같습니다. 그것이 다음 단계가 될 것이고 그것을 구현하기를 좋아하는 사람은 그렇게 할 수 있습니다. 그래서 소식이 없습니다.

추신. 이 스레드가 뉴스 요청 스팸 및 기타 관련성이 덜한 메시지로 채워지는 것을 방지하기 위한 추가 뉴스 요청이 없는 경우 뉴스에 대한 추가 요청을 삭제하기 시작했습니다.

@amir-s 동의하지만 이 문제의 주제는 upsert 기능입니다.

IMO, 진짜 문제는 API가 아니라 각 데이터베이스에서 upsert를 수행하는 드문 방법입니다.

MySQL(ON DUPLICATE KEY UPDATE) 및 PostgreSQL 9.5+(ON CONFLICT DO UPDATE)는 기본적으로 upsert를 지원합니다.

MSSQL과 Oracle은 merge 절로 이를 지원할 수 있지만, knex가 쿼리를 구성할 수 있으려면 충돌하는 열의 이름을 알아야 합니다.

-- in this case the conflict column is 'a'
merge into target
using (values (?)) as t(a)
on (t.a = target.a)
when matched then
  update set b = ?
when not matched then
  insert (a, b) values (?, ?);

그러나 SQLite는 그렇지 않았습니다. upsert를 시뮬레이션하려면 두 개의 쿼리가 필요합니다.

-- 'a' is the conflict column
insert or ignore into target (a, b) values (?, ?);
update target set b = ?2 where changes() = 0 and a = ?1;

또는 INSERT OR REPLACE , REPLACE 사용

-- replace will delete the matched row then add a new one with the given data
replace into target (a, b) values (?, ?);

불행히도 대상 테이블에 및 b보다 더 많은 열이 있는 경우 해당 값은 기본적으로 대체됩니다.

insert or replace into target (a, b, c) values (?, ?, (select c from target where a = ?1))

CTE를 사용하는 또 다른 솔루션은 이 stackoverflow 답변 을 참조하세요.

나는 knex 기반 Postgres upsert를 찾아 이 문제에 여러 번 왔습니다. 다른 사람이 이것을 필요로 하는 경우 방법은 다음과 같습니다. 단일 및 복합 고유 키에 대해 이것을 테스트했습니다.

설정

아래를 사용하여 테이블에 고유 키 제약 조건을 만듭니다. 복합 키 제약 조건이 필요했습니다.

table.unique(['a', 'b'])

함수

(편집: 원시 매개변수 바인딩을 사용하도록 업데이트됨)

const upsert = (params)=> {
  const {table, object, constraint} = params;
  const insert = knex(table).insert(object);
  const update = knex.queryBuilder().update(object);
  return knex.raw(`? ON CONFLICT ${constraint} DO ? returning *`, [insert, update]).get('rows').get(0);
};

용법

const objToUpsert = {a:1, b:2, c:3}

upsert({
    table: 'test',
    object: objToUpsert,
    constraint: '(a, b)',
})

제약 조건이 합성이 아닌 경우 당연히 한 줄은 constraint: '(a)' 입니다.

업데이트된 개체 또는 삽입된 개체를 반환합니다.

복합 nullable 인덱스에 대한 참고 사항

복합 인덱스 (a,b) 가 있고 b 가 nullable이면 (1, NULL) 및 (1, NULL) 값은 Postgres에서 상호 고유한 것으로 간주됩니다(이해할 수 없습니다. 어느 하나). 이것이 사용 사례인 경우 부분 고유 인덱스를 만든 다음 upsert 전에 null을 테스트하여 사용할 제약 조건을 결정해야 합니다. 부분 고유 인덱스를 만드는 방법은 다음과 같습니다. CREATE UNIQUE INDEX unique_index_name ON table (a) WHERE b IS NULL . 테스트에서 b 가 null인 것으로 확인되면 upsert에서 constraint: '(a) WHERE b IS NULL' 제약 조건을 사용해야 합니다. a 도 nullable인 경우 3개의 고유 인덱스와 4개의 if/else 분기가 필요하다고 생각합니다(내 사용 사례가 아니므로 확실하지 않음).

다음은 컴파일된 자바스크립트 입니다.

누군가가 이것을 유용하게 사용하기를 바랍니다. @elhigu knex().update(object) 사용에 대한 의견이 있으십니까? (편집: Nevermind - 경고를 보았습니다 - 지금 knex.queryBuilder() 사용)

@timhuff 는 멋지게 보입니다. 변경해야 할 한 가지는 값 바인딩을 사용하여 각 쿼리를 원시에 전달하는 것입니다. 그렇지 않으면 query.toString() 가 쿼리의 각 부분을 렌더링하는 데 사용되며 가능한 종속성 주입 구멍이 열립니다(queryBuilder.toString()는 매개변수를 바인딩만큼 드라이버에 전달하는 것만큼 안전하지 않습니다).

@elhigu 잠깐... query.toString() 는 바인딩을 사용하지 않습니까? 권장하고 있는 수정 사항의 대략적인 예를 들어 주시겠습니까? 나는... 업데이트할 코드가 많을 수 있습니다.

Raw bindings 라는 레이블이 붙은 문서 부분을 찾았습니다. 지금 업데이트하기 예제를 업데이트했습니다. query.toString 는 안전하다고 생각했습니다. 문서 섹션에 "안전하지 않은 쿼리를 만드는 방법"과 같은 레이블이 있는 것이 좋습니다. 금지 사항은 소수에 불과하며 사람들이 "이런 일을 하지 않는 한 안전합니다"라는 것을 알면서 도서관을 사용할 수 있습니다.

다음 upsert를 만들었습니다. https://gist.github.com/adnanoner/b6c53482243b9d5d5da4e29e109af9bd
단일 및 일괄 upsert를 처리합니다. @plurch 에서 약간 수정했습니다. 개선은 항상 감사합니다 :)

가치 있는 일을 위해 다음 형식을 사용했습니다.

편집: 이것을 검색하는 모든 사람을 위해 업데이트되었습니다. @elhigu 감사합니다

const query = knex( 'account' ).insert( accounts );
const safeQuery = knex.raw( '? ON CONFLICT DO NOTHING', [ query ]);

@NicolajKN toString()을 사용하면 안 됩니다. 많은 종류의 문제를 일으킬 수 있고 DB 바인딩을 통해 값을 전달하지 않습니다(잠재적인 SQL 주입 보안 구멍).

같은 방법으로 올바르게 수행하면 다음과 같습니다.

const query = knex('account').insert(accounts);
const safeQuery = knex.raw('? ON CONFLICT DO NOTHING', [query]);

관련 없는 문제에 대한 토론을 삭제했습니다.

@elhigu 잠깐만 그 삽입 쿼리가 생성 된 직후에 실행되지 않습니까? 경쟁 조건을 생성하지 않습니까?

@cloutiertyler 당신은 나에게 말을 하지 않았지만 아마도 내가 @elhigu 에서 시간을 절약할 수 있을 것입니다. 이러한 쿼리는 실행되지 않습니다. knex('account').insert(accounts) 문은 쿼리를 실행하지 않습니다. 데이터가 실제로 호출될 때까지 실행되지 않습니다(예: .then 를 통해). 그는 이것을 query.toString() 호출할 knex.raw('? ON CONFLICT DO NOTHING', [query]) 로 보내고 쿼리 를 실행될 SQL 문으로 변환합니다.

@timhuff 감사합니다 Tim, 그런 식이어야 한다고 생각했지만 약속에 대한 정상적인 행동은 아닙니다. 약속은 일반적으로 생성 시 실행됩니다. 내가 묻는 이유는 이 upsert를 실행하려고 할 때 "연결 종료됨"이라는 오류가 자주 발생했기 때문입니다. 삽입물을 제거하고 완전히 원시 쿼리를 만드는 것으로 전환하면 사라졌습니다. 경쟁 조건과 일치하는 것처럼 보입니다.

knex QueryBuilder s는 Promise s가 아닙니다. knex 쿼리 작성을 시작하면 "knexland"에 머물게 됩니다. 빌드하려는 쿼리의 JSON 사양을 구성하기만 하면 됩니다. .toString 를 실행하면 빌드하고 출력합니다. 이것들 중 하나 를 실행할 때까지는 ( bluebird ) Promise가 되지 않습니다. 명령문을 즉시 실행하려면 .return 를 사용하는 것이 좋습니다.

아, 알겠습니다. 그러면 혼란이 해소됩니다. 설명과 포인터 주셔서 감사합니다! 내 문제는 다른 곳에 있어야 합니다.

제쳐두고, 즉시 실행 되지 않는다는 사실은 종종 유용합니다. 때때로 당신은 실행하기 전에 그것을 구성하고 전달하고 싶을 때가 있습니다. 다음과 같은 작업을 수행할 수 있는 상황도 있습니다.

const medicalBuildings = knex.select('building_id').from('buildings').where({type: 'medical'})
const medicalWorkers = knex.select().from('workers').whereIn('building', medicalBuildings)

(매우 인위적인 예이지만 실행해 보겠습니다.)

나는 실제로 첫 번째 문장을 실행하고 싶지 않습니다. 그것은 두 번째 문장의 일부일 뿐입니다.

모든 쿼리 빌더가 생성 시 실행되는 경우 빌더 패턴 쿼리는 빌드가 완료되기 전에 트리거됩니다. 쿼리를 실행하는 종료자 메서드가 없으면 전혀 작동하지 않습니다.

@elhigu 제 말은... 항상 다음 틱에서 실행할 수 있을 것 같은데요? 나는 그것이 좋은 생각이 될 것이라고 제안하는 것이 아니지만 실제로 얼마나 많은 쿼리가 생성되고 다른 틱에서 실행됩니까?

@timhuff 나는 그것에 대해 생각하지 않았습니다. 네 그것도 가능할 것 같아요. 쿼리 작성을 시작한 다음 비동기 데이터를 가져오고 계속 빌드하는 경우가 아주 흔합니다. 그렇게 자주 하지는 않지만.

@lukewlms 는 'execute()'와 같은 메서드를 '.then()'이라고 하며 쿼리를 실행하고 약속을 받고 싶을 때 항상 호출할 수 있습니다. 'thenable'이 작동하는 방식이며 promise spec에 설명되어 있습니다. 이것은 Promise와 async/await(Promise.resolve 및 .then에 대한 거의 영광스러운 바로 가기)를 처리할 때 자바스크립트에서 중요하고 널리 사용되는 개념 중 하나입니다. 또한 결과를 처리하지 않고 쿼리를 실행하는 경우 앱 충돌과 같은 문제를 찾고 있습니다.

실제로 upsert 기능 구현 https://github.com/tgriesser/knex/pull/2197 에 대한 이 PR을 따르는 것이 더 낫습니다. API는 이미 작동 방식을 설계했습니다. 이 스레드에는 해당 PR의 주석에서 이미 언급되지 않은 유용한 정보가 없습니다. 필요한 경우(PR이 종료되고 완료되지 않음) 추가 API 설명과 함께 이 문제에 대한 새 문제를 열 ​​수 있습니다.

@elhigu 알려 주셔서 감사합니다! 나는 그 스레드를 몰랐다. API에 대한 upsert가 진행 중이라는 소식을 듣게 되어 기쁩니다. 6개월 전에 802 테스트 중 1개에 실패하여 travis-ci를 통과하지 못한 것 같습니다. 이것이 knex API의 일부가 되지 않도록 하는 유일한 방법은 실패한 테스트 케이스 1개입니까?

@timhuff 초기 구현만 완료되었으므로 완전히 다시 작성해야 합니다. 그 PR의 가장 중요한 부분은 대부분의 방언에서 지원할 수 있는 공통 API 디자인입니다. 따라서 이 기능은 누군가가 해당 API를 구현하기로 결정할 때 제공됩니다. 아무도 그렇게 하지 않고 언젠가 나에게 여분의 시간이 생기거나 절실히 필요하다면 내가 직접 할 것입니다. 이것은 (업데이트에 참여하는 것 외에도) knex가 얻고자 하는 가장 중요한 기능 중 하나입니다.

@elhigu 작성해 주셔서 감사합니다. 시간이 좀 더 있으면 여기에서 진행 상황을 읽어봐야겠습니다.

이것이 누군가에게 도움이 되는지 아니면 제가 멍청한 놈인지 확실하지 않지만 @timhuff 의 솔루션에 대해 쿼리 구문 오류가 발생했기 때문에 제약 조건을 따옴표로 묶어야 했습니다.

const contraint = '("a", "b")'

나는 knex 기반 Postgres upsert를 찾아 이 문제에 여러 번 왔습니다. 다른 사람이 이것을 필요로 하는 경우 방법은 다음과 같습니다. 단일 및 복합 고유 키에 대해 이것을 테스트했습니다.

설정

아래를 사용하여 테이블에 고유 키 제약 조건을 만듭니다. 복합 키 제약 조건이 필요했습니다.

table.unique(['a', 'b'])

함수

(편집: 원시 매개변수 바인딩을 사용하도록 업데이트됨)

const upsert = (params)=> {
  const {table, object, constraint} = params;
  const insert = knex(table).insert(object);
  const update = knex.queryBuilder().update(object);
  return knex.raw(`? ON CONFLICT ${constraint} DO ? returning *`, [insert, update]).get('rows').get(0);
};

용법

const objToUpsert = {a:1, b:2, c:3}

upsert({
  table: 'test',
  object: objToUpsert,
  constraint: '(a, b)',
})

제약 조건이 합성되지 않은 경우 당연히 한 줄은 constraint: '(a)' 입니다.

업데이트된 개체 또는 삽입된 개체를 반환합니다.

복합 nullable 인덱스에 대한 참고 사항

복합 인덱스 (a,b) 가 있고 b 이 nullable이면 (1, NULL) 및 (1, NULL) 값은 Postgres에서 상호 고유한 것으로 간주됩니다(이해할 수 없습니다. 어느 하나). 이것이 사용 사례인 경우 부분 고유 인덱스를 만든 다음 upsert 전에 null을 테스트하여 사용할 제약 조건을 결정해야 합니다. 부분 고유 인덱스를 만드는 방법은 다음과 같습니다. CREATE UNIQUE INDEX unique_index_name ON table (a) WHERE b IS NULL . 테스트에서 b 가 null인 것으로 확인되면 upsert에서 constraint: '(a) WHERE b IS NULL' 제약 조건을 사용해야 합니다. a 도 nullable이면 3개의 고유 인덱스와 4개의 if/else 분기가 필요하다고 생각합니다(내 사용 사례가 아니므로 확실하지 않음).

다음은 컴파일된 자바스크립트 입니다.

누군가가 이것을 유용하게 사용하기를 바랍니다. @elhigu ~ knex().update(object) 사용에 대한 의견 ?~ (편집: Nevermind - 경고를 보았음 - 지금 knex.queryBuilder() 사용)

일부 관련 없는 토론을 제거했습니다(promise/thenables 작동 방식에 대해).

이 추가 되었습니까?

아니요. https://github.com/knex/knex/issues/3186 에 기능 요청 및 사양이 있습니다.