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를 만들 수 있습니다.

작업용으로 지금 사용합니다.

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() 는 table.increments().primary() 수동으로 지정하는 경우에만 PK를 생성합니다.

떠나지 않는 이유
increments: 'serial'
대신에
increments: 'serial primary key'

그게 무슨 문제입니까?

여전히 같은 오류가 발생합니다.
IMHO .increments 은 (는) PK를 생성하지 않아야합니다.

이 문제에 대한 소식이 있습니까?

동의 함-다양한 방법으로이 문제를 해결할 수는 있지만 API가 기본 키로 만들지 않고 자동 증가 열을 생성하는 일급 지원이 없다는 것은 다소 이상합니다.

그렇다고해서이 문제가 아직 해결되지 않았다고 생각합니다. 가장 현명한 방식으로이 문제를 수정하는 것은 브레이킹 체인지이므로 메이저 버전 범프의 일부 여야하기 때문입니다.

뿡뿡
문제는 테이블을 생성 할 때 열에 .primary() 를 사용하면 테이블 생성을위한 별도의 쿼리와 기본 키를 정의하는 또 다른 alter table 쿼리가됩니다.
MySQL (또는 아마도 다른 DBMS)에서는 PK 없이는 auto_incremement 필드를 가질 수 없다고 생각합니다.
따라서 knex는 기본 키로 테이블을 생성 한 다음 테이블에 이미 하나가 있으므로 두 개의 기본 키를 정의하기 위해 alter 만 할 수 없습니다.
이 문제를 해결할 수 있다면 .increments 여전히 PK를 생성하지만 하나의 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"는 "여러 열에 하나의 PK"를 의미했습니다.

위의 모든 의견에 동의합니다. 이 동작은 키가 아닌 자동 증가 열뿐만 아니라 복합 기본 키를 만들려고 할 때 예기치 않은 동작입니다. 이것이 구현되는 것을 보는 것이 좋을 것입니다.

이 문제도 발생하고 있지만 Postgres 을 사용하고 직렬 필드를 외래 키로 사용하는 경우- Postgres 직렬 필드의 knex 구현은 increments() 그러면 기본적으로 기본 키가됩니다. 나는 postgres뿐만 아니라 sqlite3를 빌드 할 수 있기를 원하므로 원시 knex 쿼리를 사용하면 또는 둘 중 하나로 제한됩니다. 해결 방법 제안이 있습니까?

이 스레드는 한동안 많은 관심을받지 못했습니다. 이전 버전과 호환되는 이상적인 솔루션이라고 생각하는 것을 반복하고 싶습니다 (따라서 모든 마이너 릴리스의 일부가 될 수 있음) : .increments() 새 옵션을 추가하거나 primaryKey: false 에 추가합니다. (가능한 DBMS의 경우) 기능의 기본 키 부분을 비활성화합니다.

.increments() 는 기본 동작을 유지하므로 완전히 역 호환됩니다.

@zacronos 코드를 빠르게 살펴 보았습니다. 사소 해 보입니다. PR을 함께 던질거야
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에서 기본 키를 _not_ 강제로 조정하고 변경 로그에 추가하는 것이 매우 안전하다고 생각합니다. 패치가 아니라 다음 메이저 버전입니다.

이런 이유로 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). 이것에 대한 업데이트가 있습니까? 이미 제작 된

두 번째로 저는 이미 단일 프로젝트에서 3 번이 필요했습니다.

여기서도 동일한 문제로 PK 이음새를 비활성화하는 추가 매개 변수가 합리적입니다.

# 2896과 유사하게 MySQL에 사용할 수 있습니다.

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