hmmm... next time, coffee first, post second. Appologies...
On Jun 23, 1:55 pm, Collin Grady <[EMAIL PROTECTED]> wrote:
> AmanKow said the following:
>
> > Actually, 'required' is an argument to the *Model* field constructor,
> > and models are *not* always initialized from html forms. The
Hey all,
First, I apologize for posting this on django-dev, since I know it's
not development *of* Django, but I didn't want to add to the noise on
django-users, and most of the people I'm hoping to reach are frequent
readers of this list. No need to flame, I got it.
As most of you are no doubt
AmanKow said the following:
> Actually, 'required' is an argument to the *Model* field constructor,
> and models are *not* always initialized from html forms. The field
> certainly doesn't have to be represented as a checkbox in a form,
> either.
This is incorrect. Model fields have null and
Probably not the place for this discussion, but...
On Jun 22, 3:08 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> ambiguous in this context. Two perceptions exist:
> - required=True means the field has to be set. Following HTML form
> logics, it always is.
> - required=True means the
On Monday 23 June 2008 14:03:48 Michael Glassford wrote:
> Enough excuses. I'm usually more careful about looking closely at
> something before replying, and I'll try to be next time. I'm also
> looking at modifying Model._collect_sub_objects (to handle other
> types of on_delete behavior
Brilliant, I feel slightly less of a fool now. :)
On 23 Jun 2008, at 15:05, George Vilches wrote:
>
> You'll be happy to know that there's a ticket in the system that
> already resolves this problem: http://code.djangoproject.com/ticket/
> 7512 . It will properly LEFT JOIN whenever ordering
You'll be happy to know that there's a ticket in the system that
already resolves this problem: http://code.djangoproject.com/ticket/
7512 . It will properly LEFT JOIN whenever ordering occurs on
null=True relationships on any of the major field types.
gav
On Jun 23, 2008, at 10:00 AM,
Gah... ignore! Even though the foreignkey was nullable, I had an
ordering entry in the Meta class which ordered by deployment__name
which forced the inner join.
I'll be quiet now... ;-)
Mike
On 23 Jun 2008, at 14:51, Mike H wrote:
>
> Hi all,
>
> Before I rush off and possibly file a bogus
Hi all,
Before I rush off and possibly file a bogus bug report, am I seeing
incorrect behavior here?
I have a simple 'Project' model, as so:
class Project(models.Model):
deployment = models.ForeignKey(Deployment, blank=True, null=True)
... some other fields here
Some of the
Luke Plant wrote:
> On Friday 20 June 2008 23:40:43 Michael Glassford wrote:
>> Django builds a list of all the objects that are foreign keyed to
>> the one you are deleting and deletes those first, so it bypasses
>> any ON DELETE clauses. I assume this is what you're seeing.
>
> Yes, this is
Hi,
You could generate your 500.html file by rendering a different
template file that does get a RequestContext. This way you can use the
MEDIA_URL and things like that without hardcoding them in your
500.html file. Ofcourse you need to regenerate your 500.html file when
you change your
11 matches
Mail list logo
