Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"

I think (from squinting at the code) that in Django 1.2 m2m field updates now use the object save code to add relationships even where there aren't specifically defined intermediate classes, whereas previously the code did its own insert in such cases. So as a consequence last_insert_id gets called

Re: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"

get the ticket moved along (and whether my tests are sufficient and in a good enough place in the test suite). Regards, Matt On May 25, 12:00 pm, Matt Hoskins wrote: > I think (from squinting at the code) that in Django 1.2 m2m field > updates now use the object save code to add relati

Re: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"

Hi Russ, > I've just given your patch on #8901 a quick inspection, and it looks > good enough to me to progress to RFC (which I've done). I'm hoping to > have some time tonight to commit some patches; I'll try to put this on > the list. Thanks for taking a look at it - I was just wanting to make

Re: Decision required: PostgreSQL minimum versions

I have already given some of my thoughts on django-users and on the ticket for 8901... Andrew Godwin's reasoning above feels sound to me, so considering that and that 1.1 would still work for postgres 7.4 users (plus my desire to see the bug in 8901 fixed sooner rather than later as it does affect

Re: Decision required: PostgreSQL minimum versions

> If we'd thought of it, dropping 7.4 support in 1.2 would have been the > right thing to do. However, retroactively doing so now would be abuse > of the time machine privileges and I'd like to avoid being grounded. > #1's not worth the effort, so that just leaves #2, which sounds about > right to

Make "required=True" on forms.fields.NullBooleanField do something useful?

My use case is that I want to have a BooleanField on the model and on the form want to have the choices of "Unknown", "Yes" and "No" in a select list and give a "this field is required" error if the user leaves it set to "Unknown" (i.e. require them to actively choose "Yes" or "No", rather than def

Re: Make "required=True" on forms.fields.NullBooleanField do something useful?

For the reasons I gave in my explanation above - which bit isn't clear? > If you require a "Yes" or "No" choice, why do you use a > NullBooleanField in the first place and not a BooleanField ? > > George -- You received this message because you are subscribed to the Google Groups "Django develo

Re: Make "required=True" on forms.fields.NullBooleanField do something useful?

the default and thus the default value would be valid so the user could just hit submit without interacting with the field, whereas if the selection list includes "Unknown" and defaults to that, the user has to interact with the field and change it to "Yes" or "No" to pa

Re: Make "required=True" on forms.fields.NullBooleanField do something useful?

> > Looking at the code for forms.fields.BooleanField and > forms.fields.NullBooleanField I guess the change would be in to_python > in the latter to check in the case where it would return None if > self.required is true and raise the validation error if that's the > case (i.e. similar to what Boo

ModelMultipleChoiceField, clean and to_python

The validation documentation for forms says that to_python on the form field is the first step in validation. I've written some code (the details of which don't really matter) which makes use of to_python on fields in doing so I discovered that "to_python" on ModelMultipleChoiceField doesn't wo

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name"

Working on some code I've hit that the reverse name for a OneToOneField cannot be used, it seems, in values_list or values. I couldn't see why there would need to be such an exclusion, given it is a one-to-one relationship, so am wondering if it's just an oversight in the code or a deliberate exclu

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

My apologies for reposting this - I originally posted this at the end of January and as soon as I posted it I realised that with the push for bug squashing for the 1.3 release going on I probably wouldn't get any attention (and thus comment or replies :), so I'm trying a repost now that 1.3 is out.

Re: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

On Apr 7, 8:59 am, Russell Keith-Magee wrote: > > I'd need to go spelunking through the code to be sure, but if this is > happening, I'd be guessing it's oversight. From a quick scan of the > test suite, I can't find an obvious test for values() on one-to-one > fields. > > As for the reason for

Re: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

On Apr 7, 10:47 am, Julien Phalip wrote: > Hi Matt, > > Do you think this could be related > tohttp://code.djangoproject.com/ticket/11448 > ? > > If so, do the patches attached to that ticket help resolve your issue? > > Thanks, > > Julien Hi Julien, Thanks for your reply - from a quick squi

I don't think #15289 has been fully fixed

I'm just going through some code in an application and adjusting it to work with Django 1.3 and I thought I'd have to fix a portion of code to account for the change in transactions meaning that a cursor.execute call would leave a transaction in a dirty state (even tho' it didn't change anything).