Re: Question (potential feature request) on dropping database column in migration

> > Won’t generate migration file, which means database wise, nothing has > changed > You are the one generating migration files, Django is not forcing them. The problem is not in Django, the problem is that this cannot be solved with a single deploy, there is not way for the old code to know w

Re: ModelForm unique validation is not done right IMHO.

the fields are visible for the user? Then you will have to use Form.clean, where you will basically rewrite the unique check which Django decides to skip. On Monday, September 24, 2018 at 11:51:49 AM UTC+3, Todor Velichkov wrote: > > Then the form will raise a Validation error saying there

Re: ModelForm unique validation is not done right IMHO.

1.11. Further, adding a new book with user field > disabled results in the following error: > > [image: Selection_046.png] > > > I have attached the code to reproduce the error. > > > On Monday, September 24, 2018 at 1:59:31 AM UTC+5:30, Todor Velichkov > wrote: >>

Re: ModelForm unique validation is not done right IMHO.

on't help when validating unique_together relationship when one of >> the fields is not exposed to the user. But I could be wrong. >> >> On Sep 24, 2018 07:34, "Protik" wrote: >> >> I am using Django 1.11. Further, adding a new book with user field >>

Re: ModelForm unique validation is not done right IMHO.

x27;post_update', post.pk) > else: > f = BookForm(instance=book, user=user) > > return render(request, 'blog/book_update.html', {'f': f}) > > > The code for models and modelform is exactly same as yours. > > > Am I doing somethi

Re: ModelForm unique validation is not done right IMHO.

st the > possible solution? > > On Tuesday, October 10, 2017 at 8:26:32 AM UTC+5:30, Todor Velichkov wrote: >> >> It does? Can you give me a link to that please? >>> >> >> Pard me, it does not explicitly say to set values programmatically, but >> that thi

Re: QueryDict and ordering

Is this what you are looking for? from django.http import QueryDict from collections import OrderedDict class OrderedQueryDict(QueryDict, OrderedDict): pass my_dict = OrderedQueryDict(request.META['QUERY_STRING']) print my_dict.items() On Friday, January 5, 2018 at 5:07:41 PM UTC+2, Ole

Re: ModelForm unique validation is not done right IMHO.

s to strip the missing fields, i.e. instead of "Book with this User and Name already exists." to become: "Book with this Name already exists." but it really depends on the context. The one thing that I know for sure is that personally I would definitely prefer a

Re: ModelForm unique validation is not done right IMHO.

an Apolloner wrote: > > > > On Saturday, October 7, 2017 at 5:07:31 PM UTC+2, Todor Velichkov wrote: >> >> I believe this could save a lot of headache to people. If there is no >> guarantee that an instance cannot be saved after the form has been >> validated, then d

Re: ModelForm unique validation is not done right IMHO.

Thank you for the replay Florian, I will think about what you said that Django shouldn't make any assumptions about fields outside the form, but my intuition tells me that there are more staff which we could be retrieved from the ModelForm's. Some of my initial thoughts: If the ModelForm does

ModelForm unique validation is not done right IMHO.

I will best explain what I mean with an example. Lets say we have a simple model called Book. class Book(models.Model): user = models.ForeignKey(User) name = models.CharField(max_length=255) class Meta: unique_together = ('user', 'name') so `Books` are linked to users, and

Re: Using EXISTS instead of IN for subqueries

How does this query look like? Not sure if this is gonna help, but you can take a look at Exists() subqueries On Wednesday, September 6, 2017 at 4:29:21 PM UTC+3, Stephan Seyboth wrote: > > Sorry for resurrecting

Re: Automatic prefetching in querysets

+1 to just add the queryset method it gives a fine granular level of control. Moreover when not used we could display warnings which can help people detect these O(n) query cases as Tom Forbes initially suggested. On Friday, August 18, 2017 at 9:08:11 AM UTC+3, Anssi Kääriäinen wrote: > > On Thu

Re: Adding signals to bulk update/create operations

gt; >> There's an accepted ticket about adding pre_update and post_update >> signals: https://code.djangoproject.com/ticket/21461. From a quick >> glance, I think this is what you're proposing. >> >> On Thursday, March 30, 2017 at 4:28:00 PM UTC-4, Todor

Adding signals to bulk update/create operations

Consider the following piece of code: @receiver(pre_save, sender=MyModel) def my_handler(sender, **kwargs): instance = kwargs['instance'] if instance.verified: do_something(instance) else: do_else(instance) Its good, because it keeps `MyModel` decoupled from `do_some