Knex: 複数のPKを作成することはできません（.primaryで.incrementsをミックスイン）

いいえ、しかしおそらくそうあるべきです。 私はこれについて何かを調べます。

https://github.com/tgriesser/knex/blob/master/lib/dialects/mysql/schema/column.js#L30によると

ColumnCompiler_MySQL.prototype.increments = 'int unsigned not null auto_increment primary key';

したがって、 .increments()はPKを作成します。 強すぎる行動ではないですか？ PKなしでAUTO_INCREMENT列を作成する方が良いと思いますので、次のようにします。

int unsigned not null auto_increment

そして、PKを作成するには、 .primary()を呼び出す必要があります。

table.increments('id').primary();

AUTO_INCREMENT列で多くのPKを作成できます。

私が今使っているworkaroudとして：

table.primary(['cmdId', 'deviceId']);
table.integer('cmdId').notNullable();
table.string('deviceId', 16).notNullable().references('second_table.deviceId');

そしてthenコールバックで：

knex.schema.raw('ALTER TABLE my_table MODIFY cmdId INT UNSIGNED AUTO_INCREMENT');

同様の問題があります。主キーではなく.increments()を使用したいと思います。 私の場合、それはパフォーマンス上の理由によるものです。 インデックスのない（つまり主キーのない）テーブルを作成し、そこに多くの行を挿入してから、自動インクリメント列にインデックスを追加したいと思います。 これはよりパフォーマンスが高く、実際にはPostgresのドキュメント（http://www.postgresql.org/docs/9.4/static/populate.html#POPULATE-RM-INDEXESを参照）で推奨されていますが、現在のところ、これを行うことは不可能のようです。 knex。

私も同様の問題に遭遇しているようです。 次のようなテーブルを作成できません。

knex.schema.createTable("numeric_table", function (table) {
    table.integer("integer_key").primary;

   // Both increments & bigIncrements tries to create primary key.
    table.increments("increment_key");
    table.bigIncrements("big_increment_key");
});

ここで同じ問題.increments（）は、手動で主キーを指定した場合でも、主キーを定義しようとします

生のクエリを使用して、主キーなしで増分列を追加できます。

exports.up = function (knex) {
  return Promise.all([
    knex.raw('alter table "my_table" add column "my_seq" bigserial'),
  ]);
};

exports.down = (knex) => {
  return Promise.all([
    knex.schema.table('my_table', (t) => {
      t.dropColumn('my_seq');
    }),
  ]);
};

または、で自動インクリメント列を作成できます

table.specificType('myid','serial');

（Postgresqlの場合のみ）

しかし、 table.increments().primary()で手動で指定した場合にのみ、 table.increments()がPKを作成する方がはるかに優れていると思います。

離れてみませんか
increments: 'serial'
の代わりに
increments: 'serial primary key'

それの問題は何ですか？

それでも同じエラーが発生します。
IMHO .incrementsはPKを作成するべきではありません。

この問題に関するニュースはありますか？

同意しました-この問題をさまざまな方法で回避することは確かに可能ですが、APIが主キーにせずに自動インクリメント列を作成するためのファーストクラスのサポートを持っていないのはかなり奇妙です。

そうは言っても、これはまだ修正されていないと思います。これを最も賢明な方法で修正することは重大な変更であり、メジャーバージョンのバンプの一部である必要があるためです。

@zacronos
テーブルを作成するときに列で.primary()を使用すると、結果はテーブルを作成するための個別のクエリと、主キーを定義するための別のalter tableクエリになります。
MySQL（またはおそらく他のDBMSも）では、PKでなければauto_incremementフィールドを持つことはできないと思います。
したがって、knexは主キーを使用してテーブルを作成しますが、テーブルにはすでに1つあるため、 alterで2つの主キーを定義することはできません。
これを修正できれば、おそらく.incrementsはPKを作成しますが、他の列もすべて1つのcreate tableクエリでPKできるので、メジャーバージョンのバンプはおそらく必要ありません。

または、このために別の列タイプを追加し、下位互換性を損なわないように.incrementsをそのままにしておくこともできます。

@ amir-s：knexがそのように動作する理由を説明しています-サポートされているさまざまなDBMS間で同等の動作をしようとしているようです。 私は特にそれが好きではありませんが、少なくとも今は奇妙に見えません。

あなたの提案の問題は、定義上、テーブルに複数の主キーを持つことができないということです。 （複数の列に1つの複合PKを設定できますが、これは2つの単一列PKを使用する場合とは大きく異なります。）

したがって、 .incrementsがPKを作成する場合、他の列もPKとしてマークすることを許可することはできません。 .incrementsに渡すことができるオプションを作成して、Postgresおよびそのような動作をサポートする他のDBMSで主キーの動作を無効にすることができます。 下位互換性を損なうことはなく、DBMS間の互換性も損なうことがないため、おそらくこれが最善の解決策です。 私はまだそれが好きではなく、Postgresのデフォルトの動作を変更して.incrementsもPKにならないようにしていますが、より簡単に受け入れられるPRになります。

誰かがそれらの線に沿ってPRを提出したいのなら、私はその賛成を主張したいと思います。 :-)

@zacronos申し訳ありませんが、「複数のPK」とは、「複数の列に1つのPK」を意味します。

上記のすべてのコメントに同意します。 この動作は、複合主キーと非キーの自動インクリメント列を作成しようとしたときに予期しないものでした。 これが実装されるのを見るのは素晴らしいことです。

私もこの問題に直面していますが、 Postgres Postgresを使用し、外部キーとしてシリアルフィールドを使用している場合、 Postgresシリアルフィールドのknex実装はincrements()これにより、デフォルトでそれらが主キーになります。 postgresだけでなくsqlite3もビルドできるようにしたいので、生のknexクエリを使用すると、またはのいずれかに制限されます。 回避策の提案はありますか？

このスレッドはしばらくの間あまり注目されていません。 理想的な下位互換性のあるソリューション（したがって、マイナーリリースの一部になる可能性があります）であると私が思うことを繰り返したいと思います。 .increments()に新しいオプションを追加します。おそらくprimaryKey: falseです。 （これが可能なDBMSの場合）その機能の主キー部分を無効にします。

.increments()はデフォルトの動作を保持しているため、これは完全に下位互換性があります。

@zacronosコードを
https://github.com/DeedMob/knex/tree/master/src

ここで同じ問題。 別の主キーを作成しようとするためにbigIncrements()を回避するには、生のクエリを使用する必要があります。

回避策：

table.bigincrements();
table.biginteger('other').notNullable();
table.dropPrimary();
table.primary(['id', 'other']);

このトピックに関する以前の調査を正しく理解している場合、一部のDB（つまり、MySQL）は主キーでないとシリアルを作成できないため、knexは主キーを厳密に強制しますか？ そのような場合、Postgresに関しては下位互換性についてあまり心配する必要はありません。

MySQLユーザーは、それがプライマリであると期待します。
Postgresユーザーはそうしません。 _（上記で明らかです）_

このため、Postgresで主キーを強制しないように調整して変更ログに追加するのはかなり安全だと思います。 パッチとしてではなく、次のメジャーバージョン用です。

このため、Postgresで主キーを強制しないように調整し、それを変更ログに追加するのはかなり安全だと思います。 パッチとしてではなく、次のメジャーバージョン用です。

postgresqlについても.primary()なしでtable.bigincrements('id')だけを書くだけで常に移行を書いてきた何十人もの人々を知っています。なぜなら、それは常にそのように機能しているからです。

主キーを作成しないように指示するために使用する必要がある追加のオプションがありましたが、そこにはないようです。 少なくとも、主キーの作成をスキップすることについて、postgres / mysqlの実装については何も見つかりませんでした。

これは、移行時の下位互換性を損なう大きな変更であり、これが発生するのを見るのは嫌です。 この古い移行APIにパッチを適用し続ける場合は、最初にバージョン管理サポートを追加して、すべての人がすべてのknexバージョンで古い移行を修正できないようにする必要があります（移行コードの変更は、まったく同じように機能することを確認するのが非常に困難です自動テストなので、knexのユーザーコードでは非常に脆弱な部分です）。

解決策はありますか？

これに関するニュースはありますか？

このスレッドはしばらくの間あまり注目されていません。 理想的な下位互換性のあるソリューション（したがって、マイナーリリースの一部になる可能性があります）であると私が思うことを繰り返したいと思います。 .increments()に新しいオプションを追加します。おそらくprimaryKey: falseです。 （これが可能なDBMSの場合）その機能の主キー部分を無効にします。

.increments()はデフォルトの動作を保持しているため、これは完全に下位互換性があります。

このような増分を使用できますか？ すべてのアップデート？

調子はどう？ これは本当に面倒です。特にMSSQLでは、PK制約はデフォルトでは名前が付けられていませんが、「PK__requests__DD771E3CC0CD0A5E」のようになっているため、ドロップしてPKを作成することすらできません。
制約の名前を指定するのは本当ですが、increments（）では機能しません

それでも何もありませんか？

.incrementsのオプションのパラメータも非常に気に入っています！ 生のクエリは明らかに機能する可能性がありますが、複数の異なるDB（たとえば、本番用のmariadb、テスト用のsqlite）を実行する人にとっては煩わしいものです。 これに関する更新はありますか？ すでにPRが行われているようですが、ちょっと黙っていましたか？

もう一度言いますが、1つのプロジェクトですでに3回必要でした。

ここでも同じ問題がありますが、PKシームを無効にするための追加のパラメータがあります。

MySQLに使用できる＃2896と同様です。

t.primary(["cmdId", "deviceId"]);
t.specificType("cmdId", "int(10) unsigned AUTO_INCREMENT").notNullable();
t.string("deviceId", 16).notNullable().references("second_table.deviceId");