Перезагрузить объект django из базы данных

Question

Перезагрузить объект django из базы данных

83

Возможно ли обновить состояние объекта django из базы данных? Я имею в виду поведение, примерно эквивалентное:

new_self = self.__class__.objects.get(pk=self.pk)
for each field of the record:
    setattr(self, field, getattr(new_self, field))

UPD: Найден войну reopen/wontfix в трекере: http://code.djangoproject.com/ticket/901. Все еще не понимаю, почему сопровождающим это не нравится.

grep 07 дек. 2010, в 13:25

Источник

0

В обычном контексте SQL это не имеет смысла. Объект базы данных может быть изменен только после того, как ваша транзакция commmit и сделает commmit . Как только вы это сделаете, вам придется подождать, пока следующая транзакция SQL будет зафиксирована. Зачем это делать? Как долго вы собираетесь ждать следующей транзакции?
S.Lott 07 дек. 2010, в 15:55
0

Это кажется ненужной функцией; уже возможно просто повторно найти объект из базы данных.
Stephan 07 дек. 2010, в 18:10
0

я хотел бы , как хорошо, но она была закрыта несколько раз здесь
eruciform 17 июнь 2011, в 23:34
2

Это не подходит, потому что объекты модели Django являются прокси. Если вы получаете одну и ту же строку таблицы на два объекта - x1 = X.objects.get (id = 1); x2 = X.objects.get (id = 1), они будут проверяться как равные, но это разные объекты, и состояние не будет общим. Вы можете изменить оба независимо и сохранить их - последний сохраненный определяет состояние строки в базе данных. Поэтому корректно перезагрузить с простым присваиванием - x1 = X.objects.get (id = 1). Наличие метода перезагрузки привело бы к тому, что многие люди ошибочно предположили, что x1.f = 'new value'; (x1.f == x2.f) верно.
Paul Whipp 06 фев. 2014, в 20:49

Показать ещё 2 комментария

Теги:

django

python

django-models

3 ответа

22

Я нашел относительно легким перезагрузить объект из базы данных так:

x = X.objects.get(id=x.id)

Rory 02 фев. 2011, в 12:40

14

Да, но ... после этого вы должны обновить все ссылки на этот объект. Не очень удобно и подвержено ошибкам.
grep 04 фев. 2011, в 14:12
0

да, это ничего не делает, если экземпляр все еще передается, например, подклассом ModelForm, так что тот, который в конечном итоге вызывает form.instance.save (), получит «перезагруженную» версию
eruciform 17 июнь 2011, в 23:38
2

Считая, что это необходимо, когда Celery обновил мой объект в базе данных за пределами django, django, очевидно, хранил кеш объекта, так как не знал, что он изменился.
Bob Spryn 21 авг. 2012, в 06:16
2

из django.db.models.loading import get_model; instance = get_model (instance) .objects.get (pk = instance.pk)
Erik 31 май 2013, в 22:22
0

Также проблематично, если поле id является одним из полей, которые не синхронизированы.
Peter Westmacott 19 авг. 2013, в 14:33
0

@PeterWestmacott хорошо, довольно часто очень полезно иметь неизменяемое поле первичного ключа, пусть это будет «id» или что-то еще. Конечно, существуют исключения из правил.
Olli 23 нояб. 2013, в 14:55
0

@grep только что потерял 2 часа на написание теста для этого варианта использования: 1: инициализировать модель; 2: обновить модель через форму; 3: Проверьте, что новое значение обновлено .... Так что да, подвержен ошибкам.
vlad-ardelean 06 окт. 2014, в 09:06
0

Я думаю, что refresh_from_db решает все эти проблемы.
Flimm 05 янв. 2017, в 13:47

Показать ещё 6 комментариев

13

В отношении комментария @grep не следует делать:

# Put this on your base model (or monkey patch it onto django Model if that your thing)
def reload(self):
    new_self = self.__class__.objects.get(pk=self.pk)
    # You may want to clear out the old dict first or perform a selective merge
    self.__dict__.update(new_self.__dict__)

# Use it like this
bar.foo = foo
assert bar.foo.pk is None
foo.save()
foo.reload()
assert bar.foo is foo and bar.foo.pk is not None

Eloff 11 сен. 2012, в 16:26

0

Спасибо за решение. Если бы только ТАК допускалось несколько голосов "за"!
user590028 12 май 2016, в 12:04
8

Django теперь предоставляет метод refresh_from_db .
Flimm 05 янв. 2017, в 13:48

Ещё вопросы

В обычном контексте SQL это не имеет смысла. Объект базы данных может быть изменен только после того, как ваша транзакция commmit и сделает commmit . Как только вы это сделаете, вам придется подождать, пока следующая транзакция SQL будет зафиксирована. Зачем это делать? Как долго вы собираетесь ждать следующей транзакции?
Это кажется ненужной функцией; уже возможно просто повторно найти объект из базы данных.
я хотел бы , как хорошо, но она была закрыта несколько раз здесь
Это не подходит, потому что объекты модели Django являются прокси. Если вы получаете одну и ту же строку таблицы на два объекта - x1 = X.objects.get (id = 1); x2 = X.objects.get (id = 1), они будут проверяться как равные, но это разные объекты, и состояние не будет общим. Вы можете изменить оба независимо и сохранить их - последний сохраненный определяет состояние строки в базе данных. Поэтому корректно перезагрузить с простым присваиванием - x1 = X.objects.get (id = 1). Наличие метода перезагрузки привело бы к тому, что многие люди ошибочно предположили, что x1.f = 'new value'; (x1.f == x2.f) верно.
Да, но ... после этого вы должны обновить все ссылки на этот объект. Не очень удобно и подвержено ошибкам.
да, это ничего не делает, если экземпляр все еще передается, например, подклассом ModelForm, так что тот, который в конечном итоге вызывает form.instance.save (), получит «перезагруженную» версию
Считая, что это необходимо, когда Celery обновил мой объект в базе данных за пределами django, django, очевидно, хранил кеш объекта, так как не знал, что он изменился.
из django.db.models.loading import get_model; instance = get_model (instance) .objects.get (pk = instance.pk)
Также проблематично, если поле id является одним из полей, которые не синхронизированы.
@PeterWestmacott хорошо, довольно часто очень полезно иметь неизменяемое поле первичного ключа, пусть это будет «id» или что-то еще. Конечно, существуют исключения из правил.
@grep только что потерял 2 часа на написание теста для этого варианта использования: 1: инициализировать модель; 2: обновить модель через форму; 3: Проверьте, что новое значение обновлено .... Так что да, подвержен ошибкам.
Я думаю, что refresh_from_db решает все эти проблемы.
Спасибо за решение. Если бы только ТАК допускалось несколько голосов "за"!
Django теперь предоставляет метод refresh_from_db .

Tim Fletcher · Accepted Answer · 2015-07-14T18-10-00.000Z

По состоянию на Django 1.8 встроены восстановительные объекты. Ссылка на документы.

def test_update_result(self):
    obj = MyModel.objects.create(val=1)
    MyModel.objects.filter(pk=obj.pk).update(val=F('val') + 1)
    # At this point obj.val is still 1, but the value in the database
    # was updated to 2. The object updated value needs to be reloaded
    # from the database.
    obj.refresh_from_db()
    self.assertEqual(obj.val, 2)

@ fcracker79 Да, это было реализовано только в версии 1.8. Для более ранних версий Django лучше всего использовать один из других ответов.
Не уверены, что означает "Все неотложенные поля обновлены", упомянутые в документе?
@Yunti Вы можете отложить поля или явно запросить только подмножество полей, и полученный объект будет заполнен только частично. refresh_from_db будет обновлять только такие уже заполненные поля.