Django - how to save form without validation? - python

I need to separate form saving feature from form confirming. I want to give user possibility to save form without validating its content firstly, but when form is finished, users should click confirm button which implies data validation and saves it to database.
When I try to save it with commit=False parameter it raises error:
The Table could not be created because the data didn't validate.
UPDATE:
What I did was delete validation in model and create different function with validation which is executed when user finished with form. So I dont validate this form in Django terms.
But if somebody got different solution please answer.

in forms.py, you need to specify that all field is not required, pass required=False to the Field constructor:
example:
first_name = forms.CharField(max_length = 150, required=False)

I had the same issue. The solution I ended up with was using two tables:
one for unconfirmed data (contains data in JSON format and boolean field is_confirmed)
one for confirmed data
If your database supports JSON data type(for example MySQL 5.7+), you can stick with only former table.
I think that's better because validation is not only about required fields. Just imagine a user typed invalid date in a date field. If you save it without validation, it will be saved to db as NULL (or 0000-00-00). So, the original invalid value will be lost.

Related

How to know which field is saved when only() has been used in Django?

I am using Django 1.11, in one of my models I have added actions when the model is saved.
However I don't want these actions to be done when only a part of the model is saved.
I know that update_fields=('some_field',) can be used to specify which field must be saved.
But, when the object has been fetched in the database using the methods only() or defer() I don't see any information about the fields updated in the save() method, update_fields is empty.
Thus my question: How can I get the fields saved by Django when only some fields have been fetched ?
When you use defer or only to load an instance, the get_deferred_fields() method returns a list of field names that have not been loaded; you should be able to use this to work out which ones will be saved.

Django how does Django know which formset is which

Assuming I have a model that directly correspond to a ModelFormset.
Assuming three instances of the model are saved in the database.
Assuming I loaded the ModelFormset with initial data = the three instances
Now I render the ModelFormset on a page for users to modify.
After modification, users click on submit. How do I know which one of the ModelFormset correspond to which instance of the Model saved in the database?
Update:
I was reading this example: https://docs.djangoproject.com/en/1.9/topics/forms/formsets/#formsets-initial-data
In this example, the initial data was provide manually. Assuming if the the initial data was passed in like this:
article = Article.objects.get(pk=...)
formset = ArticleFormSet(initial=[
model_to_dict(article)
])
When this formset is sent to the template, is article's id preserved in the rendered HTML? If not, then how does Django know which article it should update if modifications to the article has been made and submitted?
If you have an existing instance in ModelForm (or in a set of them inside ModelFormset), then there's a hidden field with the value of the primary key for the record.
Each ModelForm has also a unique suffix for each the field, which helps distinguish which fields belongs to the same model.

Database queries with ModelForm Model(Multiple) Choice fields in Django

I have a form with some Model(Multiple)Choice fields that have so many options that I would like to trim down the available options based on user responses on the front-end, and then populate the select options through AJAX.
I am a little confused as to when Django will query the database in this case, and what are considered the best practices for Django ModelChoice fields that are populated with AJAX data.
Originally, I had been doing things like this:
contact = forms.ModelChoiceField(queryset=aRelatedModel.objects.all())
or a restricted queryset:
contact = forms.ModelChoiceField(queryset=aRelatedModel.objects.filter(somefield = someValue))
So, my question is, when does the DB get queried for ModelChoice options?
The confusion stems from another form I did, where I had a ModelChoiceField with the ability to add new options dynamically. In that case, unless I instantiated the ModelChoiceField after saving the new option, I would get an error. This makes me feel like the database is queried on form instantiation. But, given the lazy nature of Django querysets, it seems like it would also make sense that the DB is not queried until you iterate over said list (ie, when printing the form options).
So, in this kind of case is there a way to avoid potentially needless DB queries? What is the best practice for ModelChoiceFields that will be populated with AJAX data?
I've seen mentions of:
contact = forms.ModelChoiceField(queryset=aRelatedModel.objects.none())
...but never any explicit explanation on why to use this.
Edit:
In that case, I had a form with
field = forms.ModelChoiceField(queryset = relatedModel.objects.all())
Subsequently in the view, I naively did:
myForm = modelForm(request.POST). This produced an error if I instantiated the form before first saving the dynamically added field. After adding the field, and then calling modelForm(request.POST) I no longer had an "invalid choice" error - presumably because the dynamically added field was now included in the modelForm queryset.
I am not sure how that is relevant to the question, however. The question is when a modelForm's queryset is populated with data from the DB.

Passing a model instance, not __unicode__ method in django

I've got a django form that contains a join via a foreign key. This is a foreign key to a very large table. On the form, to prevent loading up a massive select that tends to crash browsers, I've got a jQuery autocomplete, which on each keystroke sends off the entered text. This text is then searched in the table and suitable results are returned to be displayed. The id is then passed to a hidden CharField when one is selected. This hidden CharField is the widget for the ForeignKey relation. When I try to save the form, I get an error that I need to be passing a model instance for the related model, which is fair enough. I can't work out how to do this however. I can take that id and do a model.objects.get(pk=id_from_form), but if I replace the POST data with the result of this, I still get an error as I'm just passing the __unicode__ method of the model. I'm sure there's something I'm missing, but I can't see what it is.
Thanks.
Instead of using a CharField to store the id, try using a ModelChoiceField with the widget set as a HiddenInput. The field definition in your form would look something like:
mymodel = forms.ModelChoiceField(widget=forms.HiddenInput, queryset=MyModel.objects.all())

Django best practice for displaying mostly read-only form, one field writeable

I have a requirement where one user creates an 'instance' of an object via a ModelForm. Another user of a different group has access to read all of the fields of the form, but has to update only one field. Think of a student who creates an exam object. Then a teach pulls up the exam and just needs to put in a grade, the rest of the exam is read only.
What's the best way to do that? Should I just query for the object, and display each field individually, then create a form (not a ModelForm?) for just the one field?
Should I just query for the object, and display each field individually, then create a form (not a ModelForm?) for just the one field?
This is probably the best way to go about it. Note you can use a ModelForm for the teacher form, see the Django documentation on using a subset of fields on a model form. You will have to display all the other fields manually in your template, but you should probably have a separate template for this view (I would use separate views as well).
You could find some code for a read only field on Django Snippets, but generally it's better to be explicit about what fields you are updating from each view. This is likely to be more trouble than it's worth.

Categories

Resources