Hi,
I just delved into the comments framework (Django 1.1) and have a
question about the email address field. According to
djang.contrib.comments.model the user_email field is not required
since blank=True. I don't see anything in admin.py or forms.py that
alters this, yet my comment form produc
> i would be against unifying the options as i can imagine a more complex
> environment (i.e. a database trigger or complex type not known to
> django) where there may be a distinction and i believe the current
> distinction is a clear one. it may be worthwile to imply that setting
> 'null=True'
One more:
4. django.test.TestCase effectively reloads initial_data fixtures with
every test because it calls the flush command.
--David
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post
After several iterations of running tests on an application (manage.py
test myapp), I have these observations which are not really clear in
the documentation:
1. All initial_data fixtures (not just those for the tested app) are
always loaded into the test database.
2. Because there is no means to
OK, this is interesting: I didn't mention that I also has
limit_choices_to set on the self-referential foreign key. When I
remove limit_choices_to the problem goes away! My model is listed
below. I had set limit_choices_to=PARENT_CHOICES on OrgUnit.parent.
[start code]
LIBRARY_ID = 1
SAP_ORG_UNIT
To make this even stranger, the problem only occurs when the pk of the
selected (self-)related object is 1. There's something deep going on
in Django that I can't trace ...
--David
On Aug 25, 4:20 pm, dchandek <[EMAIL PROTECTED]> wrote:
> After upgrading from post-0.96 dev
After upgrading from post-0.96 development version to 1.0-beta1, I now
get a MultipleObjectsReturned when submitting a change via the Admin
UI to an object, where the model has a many-to-one relationship with
itself. From the Python interactive prompt I am not able to reproduce
the error.
Traceba
An interesting variation I have encountered. I have custom managers
for my model classes in models.py. If I add doctests to the custom
manager methods, they run. But if I then add doctests to any model
methods, none of the doctests in models.py run -- neither the doctests
for the custom manager me
> I *think* that so long as you don't have multiple URLs pointing at the
> same generic view you'll be OK, but otherwise there could be issues --
> we're working on it.
Thanks for the reply. This is exactly the problem. I want to use
object_detail and object_list for multiple URLs, so I'll be int
I posted previously about how it seemed to me that, while the
permalink decorator is useful in decoupling the get_absolute_url()
methods of an application's models from the site/project, it more or
less forces you to create dummy custom views where you would normally
simply use generic views. Here
> Any suggestion as to how we could differentiate amongst them?
>
> At thepermalinkdecoratorfinds the first match given the view and the
> parameters. If there are multiple matches, we have to make a choice
> somehow, right?
Sadly, I don't have a suggestion. My point was merely that, while
permal
I was happy to find the addition of the permalink decorator in the
development version as a help in removing hardcoded paths from
get_absolute_url() methods.
Unfortunately, using it requires that you define a custom view (even
if the custom view simply returns a generic view). Interestingly, you
Thanks, Brian and Ivan! The CAS example was helpful in figuring things
out. Turns out the solution was simple, but the Django documentation
was not as much help as I would have liked -- I guess because, again,
the general assumption is that Django is going to handle the
authentication credentials
I've spent a few hours digging around, but can't seem to find a
straightforward answer ...
I have an Apache module that does user authentication and sets the
REMOTE_USER variable with the user name. This is completely independent
of Django and Python.
I want Django to "trust" the REMOTE_USER val
http://www.djangoproject.com/documentation/model_api/#save-on-top
This may affect other admin options ... but Django throws a syntax
error when `save_on_top' is set before `fields'. The doc merely says
that fields is required -- doesn't seem like the order should matter.
--~--~-~--~
15 matches
Mail list logo
