>
> The correct exception is risen when you try to save it:
>
> >>> t.save()
> Traceback (most recent call last):
> ...
> IntegrityError: 20100212_thing.owner_id may not be NULL
>
> How can you not understand that the DoesNotExist exception above is
> risen too early? It is a bug!
>
Are you sa
On Fri, Feb 12, 2010 at 3:47 PM, Luc Saffre wrote:
> Sorry, but the longer we discuss, the more it becomes clear: Django's
> behaviour is certainly wrong.
No, it really isn't *certainly* wrong. It's *arguably* wrong, and I
join my colleagues Luke and Karen in arguing that it isn't wrong at
all.
I think the easiest way of understanding the behaviour is that
specifying a field like this:
owner = models.ForeignKey(Owner)
specifies a contract. The contract says that when you access this
attribute on an instance, it will only return an instance of an Owner
object or raise an DoesNotExist
On 12.02.2010 12:08, Gary Reynolds wrote:
>
> Are you saying that the correct behaviour is to throw an IntegrityError
> as opposed to a DoesNotExist on accessing the field?
No. It should raise no exception at all. The expression should yield
None. It should not be forbidden for an instance to con
On 12.02.2010 13:39, Russell Keith-Magee wrote:
>
> Hopefully that clarifies why Django works the way it does.
Yes, it does. Thank you, Russel.
> However,
> even if, hypothetically, we were to accept that Django's current
> behavior is in error, (...) there is an enormous issue of practicality.
On 12.02.2010 14:01, Tom Evans wrote:
> I think the easiest way of understanding the behaviour is that
> specifying a field like this:
>
>owner = models.ForeignKey(Owner)
>
> specifies a contract. The contract says that when you access this
> attribute on an instance, it will only return an i
Hello, Jari.
I'd recommend using twod.wsgi instead: http://bitbucket.org/2degrees/twod.wsgi/
It's very stable, full-feature and truly WSGI compliant. We've been
using heavily over the last 2 months. It started from this:
http://groups.google.com/group/django-developers/browse_thread/thread/08c7ff
Nice explanation, but I can't see this documented it like this anywhere. If
it isn't documented people have to interpret it based on what they would
expect and apparently our expectations are different.
Does Django enforce any other contracts defined on the models? What would
happen if I accessed
I don't know if this is a bug.. Here is the minimal test case:
class CustomStorage(FileSystemStorage):
def get_valid_name(self, name):
import random
return '%s.abc' % (random.randint(100, 999),)
def test_uploadto(self,filename):
return 'aaa/%s' % filename
testA = models.F
Hello,
I am trying to log into the IRC channel at #django-dev but I kept on
getting this error:
#django-dev :Cannot join channel (+r) - you need to be identified
with services
I can join other channels, so I think the problem is with #django-dev
specifically, is there something special I need t
On Fri, Feb 12, 2010 at 11:14 PM, Johan wrote:
> Hello,
>
> I am trying to log into the IRC channel at #django-dev but I kept on
> getting this error:
>
> #django-dev :Cannot join channel (+r) - you need to be identified
> with services
>
> I can join other channels, so I think the problem is wit
On Fri, Feb 12, 2010 at 10:25 PM, Gleber wrote:
> I don't know if this is a bug.
If you are not sure it is a bug, the right place to ask is django-users, not
here. See:
http://docs.djangoproject.com/en/dev/internals/contributing/#id1
Karen
--
You received this message because you are subsc
Got it! Thank you so much!
Johan
On Feb 12, 11:17 pm, Alex Gaynor wrote:
> On Fri, Feb 12, 2010 at 11:14 PM, Johan wrote:
> > Hello,
>
> > I am trying to log into the IRC channel at #django-dev but I kept on
> > getting this error:
>
> > #django-dev :Cannot join channel (+r) - you need to be i
13 matches
Mail list logo
