This obviously won't work long-term though, and especially not after v1.0 hits production. If I blow away the database and all migrations, and then create a new migration up from nothing, it will work because this step won't be required. When running the resulting migration, we get the error "SQLite Error 1: 'AUTOINCREMENT is only allowed on an INTEGER PRIMARY KEY'" Since this code was auto-generated by EFCore migrations, there's not much I can do about it in general, although I might be able to fix individual migrations one at a time. For a column with a numeric type, SQLite thinks that '0' and '0.0' are the same value because they compare equal to one another numerically. Every row must have a unique primary key. This means that AUTOINCREMENT is not required for. In other words, the purpose of AUTOINCREMENT is to prevent the reuse of ROWIDs from previously deleted rows. Change the datatype of your primary key to TEXT and it should work. If the AUTOINCREMENT keyword appears after INTEGER PRIMARY KEY, that changes the automatic ROWID assignment algorithm to prevent the reuse of ROWIDs over the lifetime of the database. "Id" bigint NOT NULL CONSTRAINT "PK_Thing" PRIMARY KEY AUTOINCREMENT, This problem occurs when your primary key is a numeric type. which results in the following DDL (Anonymized): CREATE TABLE "ef_temp_Thing" ( Our initial table creation works just fine, but when we make alterations to a table, EF wants to do the whole "make a new table, move the data, drop the old table, rename the new table" dance. We are accessing this through EFCore, and using Sqlite as our in-memory database when running integration tests. I work on a database that has several bigint (Int64) columns as Ids.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |