Предсказать следующий автоматически вставляемый идентификатор строки (SQLite)

Я думаю, что это невозможно сделать, потому что нет никакого способа быть уверенным, что ничего не будет вставлено между вашим запросом и тем, что вы вставляете. (вы могли бы заблокировать таблицу для вставок, но фу)

Кстати, я использовал только MySQL, но не думаю, что это будет иметь значение)

Скорее всего, вы сможете +1 к самому последнему идентификатору. Я бы посмотрел на все (возвращаясь на некоторое время назад) существующие идентификаторы в упорядоченной таблице. Согласованы ли они и является ли идентификатор каждой строки на один больше, чем последний? Если так, то, вероятно, все будет в порядке. Однако я бы оставил комментарии в коде, объясняющие это предположение. Выполнение блокировки поможет гарантировать, что вы не получите дополнительных строк, пока вы это делаете.

Выберите значение last_insert_rowid ().

Вероятно, вам удастся добавить 1 к значению, возвращаемому sqlite3_last_insert_rowid, при определенных условиях, например, при использовании того же соединения с базой данных и отсутствии других параллельных писателей. Конечно, вы можете обратиться к исходному коду sqlite, чтобы подтвердить эти предположения.

Однако вы также можете серьезно подумать об использовании другого подхода, который не требует прогнозирования следующего идентификатора. Даже если вы сделаете это правильно для используемой версии sqlite, в будущем все может измениться, и это, безусловно, затруднит переход на другую базу данных.

Вставьте строку с каким-либо флагом INVALID, получите идентификатор, отредактируйте его, если необходимо, удалите, если необходимо, или отметьте как действительный. Это и не беспокойтесь о пробелах в последовательности

Кстати, вам нужно будет выяснить, как сделать недопустимую часть самостоятельно. Пометка чего-либо как NULL может работать в зависимости от специфики.

Редактировать: Если можете, воспользуйтесь предложением Иви об использовании правильных транзакций. Это намного меньше работы.

Либо списание, либо одновременное выполнение серии операций с базой данных - это именно то, для чего нужны транзакции. Запросите BEGIN;, прежде чем пользователь начнет возиться, и COMMIT;, когда он / она закончит. Вам гарантируется, что либо все изменения будут применены (если вы зафиксируете), либо все будет отменено (если вы запросите ROLLBACK;, если программа выйдет из строя, отключится питание и т. д.). После чтения из базы данных вам также гарантируется, что данные в порядке до конца транзакции, поэтому вы можете получить MAX(id) или что угодно, не беспокоясь об условиях гонки.

http://www.sqlite.org/lang_transaction.html

Почти все, что нужно сказать в этой теме, при этом уже имеет ... Однако будьте очень осторожны с условиями гонки.. Если два человека открывают ваше приложение / веб-страницу / что-то еще, и один из них добавляет строку, другой пользователь попытается вставить строку с тем же идентификатором, и у вас будет много проблем.

Я понимаю, что ваше приложение, использующее SQLite, невелико, а SQLite имеет собственную семантику. Другие решения, размещенные здесь, могут иметь желаемый эффект в этой конкретной настройке, но, на мой взгляд, каждое из них, которое я прочитал до сих пор, в корне неверно, и его следует избегать.

В нормальной среде следует избегать любой ценой проведения транзакции для пользовательского ввода. Способ справиться с этим, если вам нужно хранить промежуточные данные, состоит в том, чтобы записать информацию для этой цели в рабочую таблицу, а затем попытаться записать всю информацию в атомарной транзакции. Проведение транзакций вызывает тупиковые ситуации и кошмары параллелизма в многопользовательской среде.

В большинстве сред нельзя предполагать, что данные, полученные с помощью SELECT в транзакции, являются повторяемыми. Например

SELECT Balance FROM Bank ...
UPDATE Bank SET Balance = valuefromselect + 1.00 WHERE ...

После ОБНОВЛЕНИЯ значение баланса вполне может измениться. Иногда вы можете обойти это, обновив сначала интересующие вас строки в рамках транзакции, поскольку это гарантированно заблокирует строку, не позволяя дальнейшим обновлениям изменять ее значение до тех пор, пока ваша транзакция не будет завершена.

Однако иногда лучший способ обеспечить согласованность в этом случае - это проверить ваши предположения о содержимом данных в предложении WHERE обновления и проверить количество строк в приложении. В приведенном выше примере, когда вы "UPDATE Bank", предложение WHERE должно предоставить ожидаемое текущее значение баланса:

WHERE Balance = valuefromselect

Если ожидаемый баланс больше не совпадает, условие WHERE - UPDATE ничего не делает, а rowcount возвращает 0. Это означает, что возникла проблема с параллелизмом, и вам нужно повторно запустить операцию, когда что-то еще не пытается изменить ваши данные в в то же время.

select max(id) from particular_table;

Следующим идентификатором будет +1 от максимального идентификатора.

Попробуйте SELECT * FROM SQLITE_SEQUENCE WHERE name='TABLE';. Он будет содержать поле с именем seq, которое является наибольшим числом для выбранной таблицы. Добавьте 1 к этому значению, чтобы получить следующий идентификатор.

Также см. Статья об автоинкременте SQLite, откуда взялась вышеуказанная информация.

Ваше здоровье!

select max(id) from particular_table is unreliable for the reason below..

http://www.sqlite.org/autoinc.html

"Обычный алгоритм выбора ROWID, описанный выше, будет генерировать монотонно увеличивающиеся уникальные ROWID, если вы никогда не используете максимальное значение ROWID и никогда не удаляете запись в таблице с самым большим ROWID. Если вы когда-либо удаляете строки или создаете строку с максимально возможным ROWID, тогда ROWID из ранее удаленных строк могут быть повторно использованы при создании новых строк, а вновь созданные ROWID могут быть не в строго возрастающем порядке ».