Knex: アップサートタイプの機能の追加

私は同意します、これは素晴らしい機能になるでしょう！

：+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はアップサートサポートを実装しました：+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は価値のあるものでしょうか？

特にPostreSQL9.5で、これに関する更新はありますか？

重要な質問の1つは、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が正確に1であり、ターゲットテーブルにOIDがある場合、oidは挿入された行に割り当てられたOIDです。 単一の行は、更新されるのではなく挿入されている必要があります。 それ以外の場合、oidはゼロです。

INSERTコマンドにRETURNING句が含まれている場合、結果は、コマンドによって挿入または更新された行に対して計算された、RETURNINGリストで定義された列と値を含むSELECTステートメントの結果と同様になります。

この場合、戻り値はRETURNING句で変更できます。

考え？

Client_PGにモンキーパッチを適用して、挿入用の「onConflict」メソッドを追加しました。 github oauthクレデンシャルをアップサートしたいとすると、次のようにクエリを記述できます。

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

既知の問題：

• Client_PGはビルダーを専門化していないため、モンキーパッチはQueryBuilderにあり、すべての方言に影響します。
• count = count + 1のような生の更新をサポートしていません
• クエリメソッドが挿入されていない場合、onConflictはおそらくスローするはずです。

フィードバック？

@hayeah私はあなたのアプローチが好きで、Postgresに適しています。 プロジェクトであなたのモンキーパッチを試して、あなたが指摘した問題以外の問題を経験的に検出できるかどうかを確認します。

構文の提案： knex('table').upsert(['col1','col2']).insert({...}).update({...});ここで、 upsertは条件ステートメントを取ります。 このように、db固有ではありません。

アップサートのさまざまな実装の概要は、 https：//en.wikipedia.org/wiki/Merge_ （SQL）にあります。

私もこの機能に興味があります。 ユースケース：外部サービスからの大量の外部データに依存するシステムを構築します。 ローカルのMySQLデータベースに保存するデータを定期的にポーリングします。 おそらく今のところknex.rawを使用しているでしょう。

また興味がありますが、私のユースケースでは、列に常に「一意の」制約があるとは限らないため、競合に基づかない方法で機能させる必要があります-存在する場合はクエリに一致するエントリを更新するだけです。そうでない場合は挿入します新しい行。

@haywirezなぜ独自の制約がないのか知りたいのですが？ 競合状態にさらされませんか？

@hayeah特定の日に関連付けられた値を持つエントリを格納する、時間枠付きのデータを使用する特定のユースケースがあります。 したがって、一致する（日）タイムスタンプの「結合キー」と、他のテーブルのPKに対応する他の2つのIDを持つエントリを挿入および更新しています。 24時間以内に、それらを挿入するか、最新のカウントで更新する必要があります。

これは素晴らしい機能です！

こんにちは、ここにコメントしたことのある皆さん。 PRお願いラベルを追加します。

この機能を追加するPRを喜んで受けますが、最初にここで目的のAPIの説明を見てみたいと思います。

PS。

^同意しました。

このようなコメントを削除します。+ 1を追加する場合は、小さな絵文字の反応を使用してください。

@willfarrellと@hayeahの例のように、列の制約の配列に少し問題があります。 これらの例がjsonプロパティをサポートできるかどうかはわかりません。 これらの提案のいずれにも、レコードと一致する場所のステートメント/適切な「クエリ」が含まれていない理由はありますか？

提案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を実行します」と表示されますが、SQLUPSERTでは「INSERTINTO ... UPDATING（この主キーの行が既に存在する場合）」と表示されます。 。
つまり、SQLデータベースに実装されているものとはまったく異なる「アップサート」について話していると思います。

私はこのAPIを提案します：

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

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

.insert()関数は、2番目のパラメーターを分析します。
文字列の場合は、古いreturningパラメータです。
オブジェクトの場合は、 options.returningとoptions.upsertを持つ$ optionsパラメータです。ここで、 options.upsertは一意キーのリストです（1を超える場合があります）。複合一意キー制約の場合）。
次に、SQLクエリが生成されます。このクエリは、主キーとすべてのoptions.upsertキーをobjectから（ clone(object) && delete cloned_object.id && delete cloned_object.unique経由で）除外し、そのcloned_objectを使用して削除します。 SQLクエリの2番目の部分であるSET句を構成するための主キー（および一意のキー）： ... ON CONFLICT DO UPDATE SET [iterate cloned_object] 。

これは、現在のAPIと同種の最も単純で明確なソリューションになると思います。

@slavafomin @ScionOfBytesAPIでさえまだ合意されていないようです。 それが次のステップであり、それを実装するのが好きな人はそうするかもしれません。 だからニュースはありません。

ps。 このスレッドがニュースリクエストスパムやその他の関連性の低いメッセージでいっぱいになるのを防ぐためのリクエストがない場合は、追加のニュースリクエストを削除し始めました。

@ amir-s同意しますが、この問題の主題はアップサート機能です。

IMO、本当の問題はAPIではなく、各データベースでアップサートを行う珍しい方法です。

MySQL（ON DUPLICATE KEY UPDATE）およびPostgreSQL 9.5+（ON CONFLICT DO UPDATE）は、デフォルトでアップサートをサポートします。

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はそうではありませんでした。 アップサートをシミュレートするには、2つのクエリが必要です

-- '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 (?, ?);

残念ながら、ターゲットテーブルにaとbよりも多くの列がある場合、それらの値はデフォルトに置き換えられます

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

CTEを使用する別のソリューション、このスタックオーバーフローの回答を見てください

私は、knexベースのPostgresアップサートを探してこの問題に何度か遭遇しました。 他の誰かがこれを必要とする場合、これを行う方法は次のとおりです。 これを単一および複合の一意キーの両方に対してテストしました。

セットアップ

以下を使用して、テーブルに一意のキー制約を作成します。 複合キー制約が必要でした：

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)',
})

制約が合成でない場合、当然、その1行はconstraint: '(a)'になります。

これにより、更新されたオブジェクトまたは挿入されたオブジェクトのいずれかが返されます。

複合null許容インデックスに関する注意

複合インデックス(a,b)があり、 bがnull許容である場合、値(1, NULL)と(1, NULL)はPostgresによって相互に一意であると見なされます（わかりません）また）。 これがユースケースである場合は、部分的に一意のインデックスを作成し、アップサートする前にnullをテストして、使用する制約を決定する必要があります。 部分的に一意のインデックスを作成する方法は次のとおりです： CREATE UNIQUE INDEX unique_index_name ON table (a) WHERE b IS NULL 。 テストでbがnullであると判断された場合は、アップサートで次の制約を使用する必要があります： constraint: '(a) WHERE b IS NULL' 。 aもnull許容の場合、3つの一意のインデックスと4つのif/elseブランチが必要になると思います（これは私のユースケースではないため、わかりません）。

これがコンパイルされたjavascriptです。

誰かがこれが役に立つと思うことを願っています。 @elhigu knex().update(object)の使用法についてコメントはありますか？ （編集：ネバーマインド-警告を見た-今knex.queryBuilder()を使用）

@timhuffは見栄えがよく、変更する1つのことは、値のバインドを使用して、各クエリをrawに渡すことです。 それ以外の場合query.toString()はクエリの各部分をレンダリングするために使用され、依存性注入の可能性のある穴を開きます（queryBuilder.toString（）は、バインディングほどドライバーにパラメーターを渡すほど安全ではありません）。

@elhigu待って... query.toString()はバインディングを使用しませんか？ あなたが推奨している修正の大まかな例を教えてください。 私は...更新するコードがたくさんあるかもしれません。

Rawバインディングというラベルの付いたドキュメントの一部が見つかりました。 今すぐ更新例を更新しました。 query.toStringは安全だと思いました。 「安全でないクエリを作成する方法」のようなラベルが付いたドキュメントのセクションがあると便利です。 ノーノーはほんの一握りであり、そうすれば人々は「私がこれらのことをしない限り、私は安全だ」と知って図書館を利用することができます。

次のアップサートを作成しました：https：//gist.github.com/adnanoner/b6c53482243b9d5d5da4e29e109af9bd
シングルおよびバッチのアップサートを処理します。 @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を介して）実行されません。 彼はそれをknex.raw('? ON CONFLICT DO NOTHING', [query])に送信し、$ query.toString()を呼び出します。これは、クエリを実行されるSQLステートメントにのみ変換します。

@timhuffありがとうTim、私はそれがそのようなものでなければならないと思いました、しかしそれは約束のための通常の振る舞いではありません。 約束は通常、作成時に実行されます。 私が尋ねる理由は、このアップサートを実行しようとすると、「接続が終了しました」というエラーが頻繁に発生するためです。 挿入を削除して完全に生のクエリを作成するように切り替えると、それらはなくなりました。 それは競合状態と一致しているようです。

ただし、knex QueryBuilderはPromiseではありません。 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)

（非常に工夫された例ですが、それを使って実行しましょう）

私は実際にはその最初のステートメントを実行したくありません-それは私の2番目のステートメントの一部にすぎません。

言うまでもなく、すべてのクエリビルダーが作成時に実行される場合、ビルドが完了する前にビルダーパターンクエリがトリガーされます。 （クエリを実行する）ターミネータメソッドがないと、まったく機能しません。

@elhiguつまり...次のティックでいつでも実行できると思いますよね？ 私はそれが決して良い考えであることを示唆していませんが、実際にいくつのクエリが作成され、異なるティックで実行されますか？

@timhuff私はそれについて考えていませんでした。 ええ、それも可能だと思います。 クエリの作成を開始してから、非同期データを取得してさらに作成を続けるというケースは非常に一般的です。 でもそんなことはあまりしません。

@lukewlmsその 'execute（）'のようなメソッドは '.then（）'と呼ばれ、クエリを実行してpromiseを取得したいときにいつでも呼び出すことができます。 これは「thenable」がどのように機能するかであり、promise仕様で説明されています。 これは、promiseとasync / await（Promise.resolveと.thenの栄光のショートカット）を処理するときにjavascriptで広く使用されている重要な概念の1つです。 また、結果を処理せずにクエリを実行している場合は、アプリのクラッシュなどの問題を探しています。

実際には、アップサート機能の実装についてこのPRに従うほうがよいでしょう。https：//github.com/tgriesser/knex/pull/2197すでにAPIがどのように機能するかを設計しています。 このスレッドには、そのPRのコメントでまだ言及されていない有用な情報は実際にはありません。 必要に応じて（PRは閉じられ、完了しません）、追加のAPIの説明を使用してこの問題の新しい問題を開くことができます。

@elhigu頭を上げてくれてありがとう！ 私はそのスレッドに気づいていませんでした。 APIのアップサートが進んでいると聞いてうれしいです。 6か月前は、802テストの1つに失敗したため、travis-ciに合格しなかったようです。 その1つの失敗したテストケースは、これがknex APIの一部になるのを妨げる唯一のことですか？

@timhuffは最初の実装のみが行われたため、完全に書き直す必要があります。 そのPRの最も重要な部分は、ほとんどの方言でサポートできる共通のAPI設計です。 したがって、この機能は、誰かがそのAPIを実装することを決定したときに提供されます。 誰もそれをしていなくて、いつか私が余分な時間があるか、それをひどく必要としているなら、私はそれを自分でします。 これは、（更新への結合に加えて）knexに取得してもらいたい最も重要な機能の1つです。

@elhigu記入していただきありがとうございます。もう少し時間ができたら、ここで進捗状況を確認する必要があります。

これが誰かに役立つのか、それとも私が初心者なのかはわかりませんが、 @ timhuffの解決策では、クエリ構文エラーが発生したため、制約を引用符で囲む必要がありました。

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

私は、knexベースのPostgresアップサートを探してこの問題に何度か遭遇しました。 他の誰かがこれを必要とする場合、これを行う方法は次のとおりです。 これを単一および複合の一意キーの両方に対してテストしました。

セットアップ

以下を使用して、テーブルに一意のキー制約を作成します。 複合キー制約が必要でした：

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)',
})

制約が合成でない場合、当然、その1行はconstraint: '(a)'になります。

これにより、更新されたオブジェクトまたは挿入されたオブジェクトのいずれかが返されます。

複合null許容インデックスに関する注意

複合インデックス(a,b)があり、 bがnull許容である場合、値(1, NULL)と(1, NULL)はPostgresによって相互に一意であると見なされます（わかりません）また）。 これがユースケースである場合は、部分的に一意のインデックスを作成し、アップサートする前にnullをテストして、使用する制約を決定する必要があります。 部分的に一意のインデックスを作成する方法は次のとおりです： CREATE UNIQUE INDEX unique_index_name ON table (a) WHERE b IS NULL 。 テストでbがnullであると判断された場合は、アップサートで次の制約を使用する必要があります： constraint: '(a) WHERE b IS NULL' 。 aもnull許容の場合、3つの一意のインデックスと4つのif/elseブランチが必要になると思います（これは私のユースケースではないため、わかりません）。

これがコンパイルされたjavascriptです。

誰かがこれが役に立つと思うことを願っています。 @ elhigu〜 knex().update(object)の使用法に関するコメント？〜（編集：nevermind-警告を見た-今すぐknex.queryBuilder()を使用）

いくつかの無関係な議論を削除しました（promise / thenablesがどのように機能するかについて）。

これは追加されましたか？

いいえ。https：//github.com/knex/knex/issues/3186に機能のリクエストと仕様があります