After obtaining data from a model form based on a Model, say
form_data = MyModelForm(request.POST)
Then I can either create an instance of Model by
instance = Model(**form_data.cleaned_data)
Or by
instance = form_data.save()
I wonder which one is the preferred way in the django world
There is a significant difference between the two.
instance = Model(**form_data.cleaned_data) doesn't save the object in the database. It only creates a local instance.
instance = form_data.save() adds the object to the database (it performs a commit, if so supported), and it also has the side effect of triggering validation.
If you want to do custom post-processing of the object before saving it, you pass commit=False to the save() method.
instance = form_data.save(commit=False)
# do some stuff with instance
instance.save()
Related
I have a Model with a FileField like that:
class Video(MediaFile):
""" Model to store Videos """
file = FileField(upload_to="videos/")
[...]
I'm populating the DB using a cron script.
Is it possible to somehow access the "upload_to" value of the model?
I could use a constant, but that seems messy. Is there any way to access it directly?
You can access this with:
Video.file.field.upload_to # 'videos/'
or through the _meta object:
Video._meta.get_field('file').upload_to # 'videos/'
The upload_to=… parameter [Django-doc] can however also be given a function that takes two parameters, and thus in that case it will not return a string, but a reference to that function.
i'm writing an app with django and i need to change a specific model when
ever it been saved. i.e lets say i have a model A and a client want to save
changes to that model - i need to also save a change (only if the client
changed a certain field) to the same model (not instance).
my code:
#receiver(pre_save, sender=A)
def my_callable(sender, instance, **kwargs):
a = A.objects.filter(b=True).all()
for my_a in a:
my_a.b= False
my_a.save()
i have 2 problems with that code:
it has an infinite recursion
i don't know how to check which field had changed
and ideas?
Use .update(b=False) on the queryset:
#receiver(pre_save, sender=A)
def my_callable(sender, instance, **kwargs):
A.objects.filter(b=True).update(b=False)
The update is done in SQL, doesn't call model's save() method or trigger any signals
.update() docs
Assuming you're able to use Django1.8, this exact use case is covered in the docs actually: https://docs.djangoproject.com/en/1.8/ref/models/instances/#customizing-model-loading
Cliff notes: use the from_db method to customize loading of the model and save a copy of the instance's attributes as it is loaded, and then compare them before it is saved.
If you want to compare form data to a model instance to see if a user is changing it, do that in the view, not with a signal.
I have refered this documentation page for save() method
https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#the-save-method
But in my view I have the following code
def saveEvent(request):
eventForm = EventForm(request.POST)
if eventForm.is_valid():
event=eventForm.save(commit=False)
requestor=None
if(event.is_hp_requestor):
#Save and get requestor
requestorHPPersonForm = PersonHiddenForm(request.POST, prefix = 'hp_requestor')
requestorHPEmployeeForm = HPEmployeeForm(request.POST, prefix = 'hp_requestor')
requestor=saveHPEmployeeHelper(requestorHPEmployeeForm, requestorHPPersonForm).person
else:
requestorHPPersonForm = PersonHiddenForm(request.POST, prefix = 'hp_requestor')
requestor=get_object_or_404(Person, pk=requestorHPPersonForm.data[requestorHPPersonForm.prefix+'-'+'email'])
if (requestor is not None) and eventForm.is_valid():
event.requestor_new=requestor
event.save()
if request.POST['opportunities']:
for str_sfid in request.POST['opportunities'].split(','):
sfid = int(str_sfid)
opportunity_object, dummy = Opportunity.objects.get_or_create(sfdc_id=sfid)
event.opportunities.add(opportunity_object)
event.save()
return HttpResponseRedirect(reverse('dashboard'))
else:
errors = eventForm.errors
return HttpResponse(json.dumps(errors), status=500, mimetype='application/json')
In my view I do not invoke the save_m2m() method, but still it save many2many field data.
How is it works, if this is working then why we need the save_m2m() method?
The docs you linked to explain this:
Calling save_m2m() is only required if you use save(commit=False). When you use a simple save() on a form, all data – including many-to-many data – is saved without the need for any additional method calls.
Also, it looks like event is itself a model instance rather than a form. save_m2m is required for forms, not model instances.
To paraphrase the explanation in the docs: a form's save method, if called with commit=True (the default) does two things - it creates a new model instance using the form's cleaned data, and it writes that model instance to the database. Then, if there are any many-to-many relationships, it writes those to the database as well. It does that after writing the instance because you can't write a many-to-many relationship until the instance has a primary key, which is auto-generated when you write it to the database.
If you call the form's save method with commit=False, it creates the new model instance but it does not write it to the database. Thus, it has no primary key yet and the many-to-many information can't be saved either. After you save the model instance and therefore generate a primary key for it, the many-to-many information is still stored only in the form object. So you need to notify the form object that it's now OK to save the many-to-many information, by calling save_m2m.
edit Since you've added more of your code I can see more clearly what you're asking. The above code will not save many-to-many relationships that are set in your EventForm instance. Is that what your loop to set opportunities is doing?
I have a function which currently calls Models.object.get(), which returns either 0 or 1 model objects:
if it returns 0, I create a new model instance in the except DoesNotExist clause of the function.
Otherwise, I would like to update the fields in the pre-existing
instance, without creating a new one.
I was originally attempting to
call .update() on the instance which was found, but .update()
seems to be only callable on a QuerySets. How do I get around
changing a dozen fields, without calling .filter() and comparing
the lengths to know if I have to create or update a pre-existing
instance?
With the advent of Django 1.7, there is now a new update_or_create QuerySet method, which should do exactly what you want. Just be careful of potential race conditions if uniqueness is not enforced at the database level.
Example from the documentation:
obj, created = Person.objects.update_or_create(
first_name='John', last_name='Lennon',
defaults={'first_name': 'Bob'},
)
The update_or_create method tries to fetch an object from database
based on the given kwargs. If a match is found, it updates the
fields passed in the defaults dictionary.
Pre-Django 1.7:
Change the model field values as appropriate, then call .save() to persist the changes:
try:
obj = Model.objects.get(field=value)
obj.field = new_value
obj.save()
except Model.DoesNotExist:
obj = Model.objects.create(field=new_value)
# do something else with obj if need be
if you want only to update model if exist (without create it):
Model.objects.filter(id = 223).update(field1 = 2)
mysql query:
UPDATE `model` SET `field1` = 2 WHERE `model`.`id` = 223
As of Django 1.5, there is an update_fields property on model save. eg:
obj.save(update_fields=['field1', 'field2', ...])
https://docs.djangoproject.com/en/dev/ref/models/instances/
I prefer this approach because it doesn't create an atomicity problem if you have multiple web app instances changing different parts of a model instance.
I don't know how good or bad this is, but you can try something like this:
try:
obj = Model.objects.get(id=some_id)
except Model.DoesNotExist:
obj = Model.objects.create()
obj.__dict__.update(your_fields_dict)
obj.save()
Here's a mixin that you can mix into any model class which gives each instance an update method:
class UpdateMixin(object):
def update(self, **kwargs):
if self._state.adding:
raise self.DoesNotExist
for field, value in kwargs.items():
setattr(self, field, value)
self.save(update_fields=kwargs.keys())
The self._state.adding check checks to see if the model is saved to the database, and if not, raises an error.
(Note: This update method is for when you want to update a model and you know the instance is already saved to the database, directly answering the original question. The built-in update_or_create method featured in Platinum Azure's answer already covers the other use-case.)
You would use it like this (after mixing this into your user model):
user = request.user
user.update(favorite_food="ramen")
Besides having a nicer API, another advantage to this approach is that it calls the pre_save and post_save hooks, while still avoiding atomicity issues if another process is updating the same model.
As #Nils mentionned, you can use the update_fields keyword argument of the save() method to manually specify the fields to update.
obj_instance = Model.objects.get(field=value)
obj_instance.field = new_value
obj_instance.field2 = new_value2
obj_instance.save(update_fields=['field', 'field2'])
The update_fields value should be a list of the fields to update as strings.
See https://docs.djangoproject.com/en/2.1/ref/models/instances/#specifying-which-fields-to-save
I am using the following code in such cases:
obj, created = Model.objects.get_or_create(id=some_id)
if not created:
resp= "It was created"
else:
resp= "OK"
obj.save()
update:
1 - individual instance :
get instance and update manually get() retrieve individual object
post = Post.objects.get(id=1)
post.title = "update title"
post.save()
2 - Set of instances :
use update() method that works only with queryset that what would be returned by filter() method
Post.objects.filter(author='ahmed').update(title='updated title for ahmed')
Been trying to figure this out for a couple of hours now and have gotten nowhere.
class other(models.Model):
user = models.ForeignKey(User)
others = other.objects.all()
o = others[0]
At this point the ORM has not asked for the o.user object, but if I do ANYTHING that touches that object, it loads it from the database.
type(o.user)
will cause a load from the database.
What I want to understand is HOW they do this magic. What is the pythonic pixie dust that causes it to happen. Yes, I have looked at the source, I'm stumped.
Django uses a metaclass (django.db.models.base.ModelBase) to customize the creation of model classes. For each object defined as a class attribute on the model (user is the one we care about here), Django first looks to see if it defines a contribute_to_class method. If the method is defined, Django calls it, allowing the object to customize the model class as it's being created. If the object doesn't define contribute_to_class, it is simply assigned to the class using setattr.
Since ForeignKey is a Django model field, it defines contribute_to_class. When the ModelBase metaclass calls ForeignKey.contribute_to_class, the value assigned to ModelClass.user is an instance of django.db.models.fields.related.ReverseSingleRelatedObjectDescriptor.
ReverseSingleRelatedObjectDescriptor is an object that implements Python's descriptor protocol in order to customize what happens when an instance of the class is accessed as an attribute of another class. In this case, the descriptor is used to lazily load and return the related model instance from the database the first time it is accessed.
# make a user and an instance of our model
>>> user = User(username="example")
>>> my_instance = MyModel(user=user)
# user is a ReverseSingleRelatedObjectDescriptor
>>> MyModel.user
<django.db.models.fields.related.ReverseSingleRelatedObjectDescriptor object>
# user hasn't been loaded, yet
>>> my_instance._user_cache
AttributeError: 'MyModel' object has no attribute '_user_cache'
# ReverseSingleRelatedObjectDescriptor.__get__ loads the user
>>> my_instance.user
<User: example>
# now the user is cached and won't be looked up again
>>> my_instance._user_cache
<User: example>
The ReverseSingleRelatedObjectDescriptor.__get__ method is called every time the user attribute is accessed on the model instance, but it's smart enough to only look up the related object once and then return a cached version on subsequent calls.
This will not explain how exactly Django goes about it, but what you are seeing is Lazy Loading in action. Lazy Loading is a well known design pattern to defer the initialization of objects right up until the point they are needed. In your case until either of o = others[0] or type(o.user) is executed. This Wikipedia article may give you some insights into the process.
Properties can be used to implement this behaviour. Basically, your class definition will generate a class similar to the following:
class other(models.Model):
def _get_user(self):
## o.users being accessed
return User.objects.get(other_id=self.id)
def _set_user(self, v):
## ...
user = property(_get_user, _set_user)
The query on User will not be performed until you access the .user of an 'other' instance.