DRF - как «обновить» ПК после удаления объекта?

Question

новичок здесь!

вот как я использую URL-путь (из учебников по DRF):

path('articles/', views.ArticleList.as_view()), path('articles/<int:pk>/', views.ArticleDetail.as_view())

, и я заметил, что после удаления статьи '( это моя модель ), ПК остается прежним.

a Пример:

1st Article pk = 1, 2nd Article pk = 2, 3rd Acrticle pk = 3

после удаления 2n Arctile im ожидая -

1st Article pk = 1, 3rd Artcile pk = 2

но он остается

3rd Artile pk = 3.

Есть ли лучший способ реализовать URL, может быть, pk не та переменная, которую я ищу?

или я должен каким-то образом обновить список?

thnkx

Answer 1

и я заметил, что после удаления Article (это моя модель), pk остается прежним.

Это действительно ожидаемый поведение. Удаление объекта не «заполнит пробел», сдвинув все остальные первичные ключи. Это будет означать, что для огромных таблиц вы начинаете обновлять тысячи (если не миллионы) записей, что приводит к огромному количеству дискового ввода-вывода. Это сделало бы обновление (очень) медленным.

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

Эта проблема может быть еще более серьезной, если вы работаете с распределенным система, в которой у вас есть несколько баз данных на разных серверах. Атомное обновление этих баз данных является серьезной проблемой. Теорема CAP [wiki] демонстрирует, что в случае сбоя сетевого раздела вы не можете гарантировать доступность или согласованность . Обновляя первичные ключи, вы оказываете на это большее «давление».

Сдвиг первичного ключа также не является хорошей идеей. Это будет означать, что если ваш REST API, например, возвращает первичный ключ объекта, то клиент, который хочет получить доступ к этому объекту, может не иметь доступа к этому объекту, потому что первичный ключ изменился между ними. Таким образом, первичный ключ можно рассматривать как постоянный идентификатор. Обычно не хорошая идея изменить токены, которые клиент использует для доступа к объекту. Если вы используете первичный ключ или слизняк, вы знаете, что если позже вы обратитесь к тому же элементу, вы снова получите тот же элемент.

как «обновить» pk после удаления объект?

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