Re: Denormalisation Magic, Round Two
I'm not sure on AggreateField either. What if you just do like
("Photo", "user__exact=self.user") or something. Currently there's no
rerepsentation for "self" in Django QuerySet's, so this is a hard
thing to call. Also, we need a way to support callables.
e.g. models.MirrorField("my_callable_or_attribute") as well as the
models.MirrorFIeld("my_attribute", "its_subattribute")
On Oct 27, 6:26 am, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> Russell Keith-Magee wrote:
> > I do have a slight reservation regarding the API you are proposing.
> > The fields you have proposed (MirrorField and AggregateField) capture
> > the obvious use cases, but the syntax don't feel consistent with the
> > rest of the Django API. In particular, AggregateField seems to be
> > introducing a whole new query syntax that is completely independent of
> > the aggregation syntax that is due for inclusion in v1.1.
>
> > I would prefer to see a syntax that demonstrated slightly better
> > integration with the Django query syntax. If it isn't possible to use
> > QuerySet itself as a way to develop the underlying query, then I would
> > expect to see a syntax that at the very least retained the flavour of
> > the Django query syntax rather than inventing "fk:" style operators
> > that have no real analog.
>
> Indeed; I was far happier with the queryset syntax for AggregateField I
> originally proposed, but I couldn't get it to work - it just won't go
> inside class bodies without far, far too much hackery. The MirrorField
> API I like more; I have an alternate version where you simply pass it
> the model name and column name, but that then has issues if you have
> more than one FK to the same model.
>
> The AggregateField proposal is just that, and I really squirmed at the
> idea of "all:" and "fk:", but it got it working pretty quickly. One
> possibility for more clean integration is an approach more like
> querysets, so you could have something like
>
> photos_count = models.AggregateField(Photo.view.filter(user_self=True))
>
> The main problem with anything like this (and indeed with my attempt to
> implement this with plain old querysets) is that, as a field, you exist
> only on a class, and so when you get a signal saying a model has been
> updated, it's somewhat difficult to determine which instances of
> yourself to update - you can't loop through them all testing, since
> that's hilariously inefficient. That's why I limited the querying to
> only fk: and all: types, since detecting these is far more efficient.
>
> I'd love to see any proposal for how Aggregates should look, as my
> current incarnation really isn't too django-ish. I personally like
> MirrorFields (now on their third name, more welcomed) as I have them
> now, but then I would, since I invented them for my own use...
>
> Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
order_by_fields for django.contrib.admin
One of the last of my feature-needs (for optimization reasons) is the
ability to specify what fields can, or can't be ordered in the admin
apps.
I'd like to propose something along the lines of:
order_by_fields = ('field', 'field', 'field')
This would allow you to only order by fields which you've created
indexes on.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
select_related optimization and enhancement for the django.contrib.admin
While I've been working on composite primary keys, I also made a few tweaks to the admin app. Most of these are related to the primary key support, but one is an optimization. I would post this as a patch, or a ticket, but I want to open this up for discussion, and my django repo is so far from trunk it's a PITA at the moment to create the patch. Anyways, what it does: * list_select_related can be a boolean, or a list. If it's a list it says "select_related on these fields" * select_related is smart by default, no more implicit select all If someone wants to create a patch, you'll be able to get to it a lot faster than I will. Otherwise I'll eventually throw one up on trac for each change. line 198ish of django.contrib.admin.views.main if isinstance(self.list_select_related, (tuple, list)): qs = qs.select_related(*self.list_select_related) elif self.list_select_related: qs = qs.select_related() else: fields = [] for field_name in self.list_display: try: f = self.lookup_opts.get_field(field_name) except models.FieldDoesNotExist: pass else: if isinstance(f.rel, models.ManyToOneRel): fields.append(name) if fields: qs = qs.select_related(*fields) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
ModelAdmin manager
There are currently inconsistencies with how ModelAdmin decides on what query set (i.e. manager) it's using. Issue 1: The change list it uses ModelAdmin.queryset() while the change view uses ModelAdmin.model._default_manager Issue 2: Also, when searching, ChangeList uses the base QuerySet model - I haven't looked too hard to see exactly why, but it was mentioned in the wontfixed ticket #7795 [1]. The reason Malcolm gave seems incorrect since now you can override the admin's manager using .queryset() The only problem is that if you do override .queryset(), you currently have to override the whole change_view and delete_view methods to match - see #7510 [2]. Regarding issue 2, Brian Rosner noticed that the fix malcolm applied in #7113 [2] differed from the actual reason he accepted the issue (not hardcoding QuerySet). The solution seems to be just to fix everything to use ModelAdmin.queryset() (maybe with an abstraction of the manager like in the most recent ticket of #7510 [4]. Would this be breaking any meaningful backwards compatibility? [1] http://code.djangoproject.com/ticket/7795 [2] http://code.djangoproject.com/ticket/7510 [3] http://code.djangoproject.com/ticket/7113 [4] http://code.djangoproject.com/attachment/ticket/7510/options.diff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: login_required
On Mon, Nov 10, 2008 at 3:38 PM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > but we can do this "little" modification in v1.1 > > i think this change will allow site administrator to ban users throughchange > is_active flag > > Waylan Limberg pisze: > > On Mon, Nov 10, 2008 at 2:49 PM, Sebastian Bauer <[EMAIL PROTECTED]> <[EMAIL > PROTECTED]> wrote: > > > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? > > > > I see two problems with this: > > 1. This current behavior is fully documented [1]. In relevant part, > the documentation says: > > > > This doesn't control whether or not the user can log > in. Nothing in the authentication path checks the > is_active flag, so if you want to reject a login based > on is_active being False, it is up to you to check that > in your own login view. However, permission checking > using the methods like has_perm() does check this > flag and will always return False for inactive users. > > > "Fully documented" as of one month ago [1]. This field was previously 'fully documented' as [2]: "Boolean. Designates whether this account can be used to log in. Set this flag to ``False`` instead of deleting accounts." Before these changes, the original help_text for the User.is_active field was: "Designates whether this user can login to the Django admin. Unselect this instead of deleting accounts." I had brought this disconnect between the new documentation and behavior up in a previous thread [3] but failed to follow up on the discussion at that time. My point then was that: 1) django.contrib.auth.forms. AuthenticationForm raises a ValidationError if user.is_active = False (thus preventing login via the django.contrib.auth.views.login view) 2) staff_member_required decorator only allows login if user.is_active = True I now see that the test client also can only login when the credentials are for user.is_active = True and the django.contrib.auth.handlers.modpython.authenhandler also enforces this check. In the previous thread, Malcolm said he wasn't trying to document the 'edge-cases' I brought up but now it's not so clear that these are really edge cases. This field appears to only be ignored by the `login_required` decorator and the django.contrib.auth.authenticate function for manually authenticating in views but seems to be respected everywhere else. Malcolm said to report a documentation bug if the documentation is incorrect. Whenever I come to a different conclusion than a core dev, my first assumption is that I'm missing something since I really doubt I have anything close to the grasp a core dev has of the nitty gritty details of the code base. In this case, as best as I can tell, this new 'fully documented' behavior doesn't seem to jive with the code and previous documentation. I understand the worries about backwards compatibility, but the behavior and documentation seems to be inconsistent in its current state. It's not my call whether to make the documentation consistent with the code or vice versa, but I did want to bring up these complicating factors. Cheers, John-Scott [1] http://code.djangoproject.com/changeset/9176 [2] http://code.djangoproject.com/browser/django/trunk/docs/topics/auth.txt?rev=8843#L90 [3] http://groups.google.com/group/django-developers/browse_thread/thread/3f46f4834b2bf9bf/cd26e079fa265497 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: login_required
but we can do this "little" modification in v1.1 i think this change will allow site administrator to ban users through change is_active flag Waylan Limberg pisze: > On Mon, Nov 10, 2008 at 2:49 PM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > >> Hello, i think login_required should check that user is not only >> authenticated, but also if is active. What do you think about this change? >> >> > > I see two problems with this: > > 1. This current behavior is fully documented [1]. In relevant part, > the documentation says: > > >> This doesn't control whether or not the user can log >> in. Nothing in the authentication path checks the >> is_active flag, so if you want to reject a login based >> on is_active being False, it is up to you to check that >> in your own login view. However, permission checking >> using the methods like has_perm() does check this >> flag and will always return False for inactive users. >> > > 2. Many people have expected the current behavior for some time and > such a change would be backward incompatible. > > Although, I do see that the documentation specific to the > login_required view does not specifically mention the behavior. > Perhaps a note there would be beneficial. > > [1]: http://docs.djangoproject.com/en/dev/topics/auth/#api-reference > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: login_required
On Mon, Nov 10, 2008 at 11:49 AM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? I think you can write your own decorator to do that, and it would be a backwards-incompatible change, so it isn't likely to happen :) -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: login_required
On Mon, Nov 10, 2008 at 2:49 PM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? > I see two problems with this: 1. This current behavior is fully documented [1]. In relevant part, the documentation says: > This doesn't control whether or not the user can log > in. Nothing in the authentication path checks the > is_active flag, so if you want to reject a login based > on is_active being False, it is up to you to check that > in your own login view. However, permission checking > using the methods like has_perm() does check this > flag and will always return False for inactive users. 2. Many people have expected the current behavior for some time and such a change would be backward incompatible. Although, I do see that the documentation specific to the login_required view does not specifically mention the behavior. Perhaps a note there would be beneficial. [1]: http://docs.djangoproject.com/en/dev/topics/auth/#api-reference -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #7611 contrib.auth PasswordResetTest requires specific templates for tests to pass
Not intending to derail the test-skip angle (which sounds generally useful), but in this case, wouldn't a better fix be to eliminate the dependency on admin, by providing the needed templates in the auth test suite itself? PasswordResetTest could also duplicate the setup/ teardown methods used by ChangePasswordTest, to ensure that the correct templates are used during the test. - Matt Brown --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
login_required
Hello, i think login_required should check that user is not only authenticated, but also if is active. What do you think about this change? Sebastian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: problem with inlineformset_factory
Hello Colling ok, but then did a test and saw that this problem is a bug in Django, with the database sqlite works, but is giving problems with postgresql On 7 nov, 01:38, "Collin Grady" <[EMAIL PROTECTED]> wrote: > Usage questions belong on the django-users list - this list is for the > development of django itself :) > > -- > Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Denormalisation Magic, Round Two
A Mele wrote:
> I have followed the discussions about denormalization and I really
> would like to see this in trunk. I agree with Rusell, the syntax
> should be more like Django's query syntax, but I think this kind of
> field is very useful for a lot of projects.
>
I obviously agree, but Russ' point about it being ugly still stands, and
the only improvement I've been able to think of so far is changing
"fk:foo" into fk="foo", so you get something like:
models.AggregateField("Person", fk="nation", function="count")
i.e. the same call, but different syntax.
I might just go open a ticket for this soon anyway to get it recorded
properly, and at the very least release the code as a standalone module
- it's written so it can work like that anyway.
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: unable to use django when not connect the network，what’s wrong？？
Please post your question to djang-users. This list is for discussion of developing Django itself, not usage questions. Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Django templates - Can I change the form field name in template dynamically?
I have a form with fields "num1" and "num2".
Both are FloatField.
In templates, i have too use something like the following:
First Number:
{{ form.num1}}
{% if form.num1.errors %}
{{ form.num1.errors|join:", " }}
{% endif %}
Second Number:
{{ form.num2}}
{% if form.num2.errors %}
{{ form.num2.errors|join:", " }}
{% endif %}
Question:
Is there a way in Django by which I can place a variable inside a
variablename.
Something like the following:
{% for var in var_list %}
{{ form.num}}
{% if form.num.errors %}
{{ form.num.errors|
join:", " }}
{% endif %}
{% endfor %}
So that the same stuff can be acheived.
This might make dynamic repeatable forms much simpler as well.
Regards,
SP
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
unable to use django when not connect the network，what’s wrong？？
when my ubuntu8.10 not connect the Internet ，i use command “python manage.py runserver” and use firefox to view http://127.0.0.1：8080but it‘s strange that nothing show，no “it worked” page. but when connect the Internet it show the "it worked" page. i don't know why? it take too much money to connect the internet in China, i can't connect Internet all the time. it's there anybody can help me to solve this problem? thank you very much!! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
