> Of course, that's when you break out and write your own view.
Noted. And I shouldn't complain...it's not like they're exactly hard!
> You shouldn't have to import anything inside a template or generic view
> that either don't already have access to. Also, the "free" access
> didn't affect tem
Hi Luke,
On 2/19/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> I think I've found a bug in bulk delete.
This looks very similar to a bug I have been chasing where the query
system mistakes a m2m field for a m2o field (because of names reported
by get_accessor_name()).
What SVN revision are you
On 2/18/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> On Saturday 18 February 2006 23:27, Tom Tobin wrote:
> > Is there a scenario in which it would be
> > useful to only specify one of these options, and not the other, for
> > non-string fields?
>
> I have legacy data which requires allowing nulls
On Saturday 18 February 2006 23:27, Tom Tobin wrote:
> Is there a scenario in which it would be
> useful to only specify one of these options, and not the other, for
> non-string fields? I can't imagine one offhand; one would either be
> able to save null values but be unable to enter them in the
There currently seems to be a bit of redundancy with regards to the
"blank" and "null" field options; tickets #1043 and #1353 seem to be
the inverse of one another, each addressing that one must specify both
blank=True and null=True to get the expected behavior (i.e., being
able to specify and save
Hi Russell,
I think I've found a bug in bulk delete. It doesn't occur with mysql,
only with Postgres (perhaps because Django doesn't output the same
constraints as it does with Postgres).
A simplified but hopefully adequate version of my model is below:
class Person(models.Model):
name =
Russell Keith-Magee wrote:
>How about putting all the essential configuration items at the top of
>the generated settings.py, with an obvious 'border' that marks
>'optional, but possibly useful configuration options below this line';
>e.g.,
>
This looks reasonable to me... In fact I don't know if
Hi,I have been using django for developing application and it went on fine, worked as expected, but was not handling unicode properly. I have a Post model, and I am fetching the content of some blog posts and storing it in Post in _pre_save. I was using
original_content = urllib.ulropen(self.url).
On 2/18/06, Maniac <[EMAIL PROTECTED]> wrote:
> It's good that current settings.py looks small. This adds to the feeling
> of perceived simplicity of Django. It is important because settings.py
> is one of the first things that new user sees.
How about putting all the essential configuration ite
