Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Problems with WITHOUT ROWID tables with PK of string type #1559
This fixes two related problems:
I've implemented an alternative solution that restores the inline row insertion and only assures that the auto-incremented PK value is inserted as a string if the column is of type string. In this way we don't hide the auto-incrementing primary key feature, but avoid to insert an integer that we wouldn't be able later to reference.
Why do you think that? In that case wouldn't the special case for "INTEGER PRIMARY KEY" fit better?
I've taken a look to the documentation:
Note that this alternative solution is only for not shooting ourselves in the feet (not inserting an integer where a string should be). But this does not solve the case of the user inserting an integer to this text primary column. In that case, he puts a bull's-eye in his foot and later we shoot there
Seriously, I think the only way to solve the underlying problem would be to add cell types to the model and take them into account for updates. That would be also necessary for solving #1416, but that isn't really so important as this.
Thanks for the pretty good analysis, @mgrojo
The updated code looks like the best from both worlds and shouldn't break anything else. So I'm going to merge this and then cherry-pick the changes to the 3.11.0 branch to have this in the upcoming release