Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
On 9.02.2010 1:09, Karen Tracey wrote: > On Mon, Feb 8, 2010 at 5:31 PM, Luc Saffre > I personally won't insist > further, especially since Luke knows Django better than me. May I > suggest again to mark this ticket to something different than "duplicate > of an invalid ticket"? > > What difference does it make? "Closed" as "Invalid", as I understand it, means that this ticket is not worth to get more consideration and that further comments are not welcome. "Open" with a triage stage of "Someday/Maybe" would help people who stumble on this behaviour to find our discussion. Especially if we add a link to this discussion thread. Luc -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
- Make email unique and username non-required on the model. That would make implementing something that authenticated by email a lot easier :) On Feb 9, 1:34 am, Russell Keith-Magee wrote: > On Tue, Feb 9, 2010 at 8:15 AM, Justin Lilly wrote: > > To add another point, this doesn't mean that the day 1.2 hits release that > > everyone is gung-ho on 1.3. If past releases are any indication, there is > > usually a refactory period of a few weeks when everyone is basking in > > post-release bliss. > > I believe the post-release period is typically referred to as "sobering up" > :-) > > To address Vitaly's original point - contrib.auth is on my list of > things I want to address in 1.3. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
On 9 February 2010 09:09, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) Pff, move emails out entirely. Email-addresses may change. Usernames shouldn't change. One may have more than one email-address. Maybe the time is right to make that branch now... HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12804 - decorating admin views marked as invalid
On Feb 8, 2:44 pm, Luke Plant wrote: > What do people think? +1 for everything which removes the magic from auto_adapt_to_methods. Can't say much about the backwards incompatiblity issue, cause I don't care ;) Of course it would be nice, but given the options I would just document it and live with it… -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
On 9 February 2010 08:09, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) > For reference there are some good points here[1] on this topic started by Hanne Moa. I think ideally the user model would be as simple as only having an ID as we shouldn't make assumptions about requirements for usernames, emails or even passwords with the vast array of login options we have these days. The backends can then extend this to create logins that are based on email, username, oauth, openid etc. Essentially giving us an ID to tie things together and relating different authentication methods for the same user. Just some food for thought until 1.2 is out of the way and everybody is feeling a bit more sover. http://groups.google.com/group/django-developers/browse_thread/thread/c522f1e2bf01c3f7 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
I recently tried to use the recommended approach for custom user profiles: http://docs.djangoproject.com/en/dev/topics/auth/#auth-profiles and all the brick walls I hit were admin related. Whether these are better fixed in contrib.auth or contrib.admin is hard to say: 1. I can show profile fields in the user changelist but I can't sort, filter or search on them or use list_editable on them. 2. I can re-register my own ModelAdmin for users to customize the User admin but I can't add custom filterspecs as that requires editing the auth models.py #1 could be mitigated if contrib.admin allowed more ways to following relationships for things like list_display and list_filter. #2 requires a more elegant way to write custom filterspecs without touching models.py - maybe this is already possible? Andy Baker -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
On Tue, Feb 9, 2010 at 2:09 AM, Harro wrote: > - Make email unique and username non-required on the model. That would > make implementing something that authenticated by email a lot > easier :) 1. It's *extremely* unlikely that changes will be considered which require every Django install on the planet to undergo a DB schema migration. 2. The appropriate time to discuss possible 1.3 features is when the feature-discussion window for 1.3 comes up. That will happen sometime in April, probably. Suggestions made now are likely to be forgotten by the time that happens. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12804 - decorating admin views marked as invalid
On Tuesday 09 February 2010 02:40:03 Russell Keith-Magee wrote: > >> What do people think? > > > > Ugh. Assuming no one can come up with a brilliant fix so that the > > auto_adapt stuff can work when combined with arbitrary other > > decorators (I can't), I favor switching to a system that requires > > different decorators for methods vs. functions and documenting > > the backwards-incompatibility for 1.2. What you propose there > > reads pretty well to me. > > I concur. Ugh. :-) > > It's not nice but given the alternatives, I think the backwards > incompatibility is the best option. +1 to introducing method_dec > (bikeshedding - I actually prefer method_decorator), removing > @auto_adapt_to_method, and documenting the problem with > user_passes_test. OK, good, that's what I was thinking (complete with 'ugh' reaction!). Now, should we backport to 1.1.X or not? We could justify *not* backporting on the grounds that this is a fix for #12804, which does not exist in 1.1.X. Given that no-one filed a bug about this for the lifetime of 1.0 and 1.1, it's probably an obscure enough corner case in the context of 1.1.X that backporting this fix will cause more harm than good. And if someone does have a problem on 1.1.X, we can provide a work-around (which is to use method_decorator). Unless anyone shouts, I'll just commit to trunk. Luke -- "You'll be glad to know, I'm going to donate all the snot I sneeze to hospitals for mucus transfusions." (Calvin and Hobbes) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12804 - decorating admin views marked as invalid
On Tue, Feb 9, 2010 at 10:51 PM, Luke Plant wrote: > On Tuesday 09 February 2010 02:40:03 Russell Keith-Magee wrote: > >> >> What do people think? >> > >> > Ugh. Assuming no one can come up with a brilliant fix so that the >> > auto_adapt stuff can work when combined with arbitrary other >> > decorators (I can't), I favor switching to a system that requires >> > different decorators for methods vs. functions and documenting >> > the backwards-incompatibility for 1.2. What you propose there >> > reads pretty well to me. >> >> I concur. Ugh. :-) >> >> It's not nice but given the alternatives, I think the backwards >> incompatibility is the best option. +1 to introducing method_dec >> (bikeshedding - I actually prefer method_decorator), removing >> @auto_adapt_to_method, and documenting the problem with >> user_passes_test. > > OK, good, that's what I was thinking (complete with 'ugh' reaction!). > > Now, should we backport to 1.1.X or not? We could justify *not* > backporting on the grounds that this is a fix for #12804, which does > not exist in 1.1.X. Given that no-one filed a bug about this for the > lifetime of 1.0 and 1.1, it's probably an obscure enough corner case > in the context of 1.1.X that backporting this fix will cause more harm > than good. And if someone does have a problem on 1.1.X, we can > provide a work-around (which is to use method_decorator). > > Unless anyone shouts, I'll just commit to trunk. I'm happy to call this a "fix for @auto_adapt_to_method in 1.2", rather than a fix for the problem in 1.1. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
On Tue, Feb 9, 2010 at 3:02 AM, Luc Saffre wrote: > "Closed" as "Invalid", as I understand it, means that this ticket is not > worth to get more consideration and that further comments are not welcome. > > "Open" with a triage stage of "Someday/Maybe" would help people who > stumble on this behaviour to find our discussion. Especially if we add a > link to this discussion thread. > Open with a triage state of Someday/Maybe would imply that the current behavior has been acknowledged as wrong and that a change in the behavior might be expected. It would also imply that if someone provided a patch to change the behavior, it would have a chance of getting checked in. With two core devs stating they see the current behavior as logical and consistent and none stepping up to say the opposite, a change in behavior here isn't going to happen. Thus an open state for this ticket would give people the wrong impression of the state of the issue. Closed tickets are as easily found as open ones -- anyone doing research in an attempt to understand current behavior should not be limiting their searches to only open tickets. The right state for this ticket is closed, which means it's been reviewed and determined that the current behavior is correct and nothing needs to be done to fix it. I would not term further comemnts "unwelcome", but they are not particularly useful unless someone has some new light to shed on the issue. 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-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: contrib.Auth
Vitaly Babiy On Tue, Feb 9, 2010 at 3:16 AM, James Bennett wrote: > On Tue, Feb 9, 2010 at 2:09 AM, Harro wrote: > > - Make email unique and username non-required on the model. That would > > make implementing something that authenticated by email a lot > > easier :) > > 1. It's *extremely* unlikely that changes will be considered which > require every Django install on the planet to undergo a DB schema > migration. > James this is true. Another reason it would be nice to have a migration framework for Django. > > 2. The appropriate time to discuss possible 1.3 features is when the > feature-discussion window for 1.3 comes up. That will happen sometime > in April, probably. Suggestions made now are likely to be forgotten by > the time that happens. > > Yeah I plan to bring this up again, around that time frame. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Is any thing for python like .jar files for java.
Hi all, Is there any concept in python like .jar files in java. If anybody of you know please reply me. -- Thanks and regards, chiranjeevi.muttoju -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Is any thing for python like .jar files for java.
On Tue, Feb 9, 2010 at 3:05 PM, chiranjeevi muttoju wrote: > Hi all, > Is there any concept in python like .jar files in java. If anybody of you > know please reply me. > > -- > Thanks and regards, > chiranjeevi.muttoju > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > The django-developers mailing list is for the development of django itself, not developing with Django, also please don't cross post. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: What The Enterprise wants from Django
On 21 Jan., 17:45, Andy McKay wrote: > On 2010-01-21, at 9:15 AM, chris.moff...@gmail.com wrote: > > > I agree that managing settings gets to be a bit difficult in many > > environments - even non Fortune 1000 environments. Its also an issue for us that write and use portable apps. Luckily a way for apps to provide defaults could easily be implemented in a admin.autodisover sort of way. Somebody already implemented something similar to what i wanted to write today: http://code.djangoproject.com/ticket/1282 For the rest of the "probelms", as someone who is constantly integrating heterogenous systems with django, I think the solution might be "outside" of django. Some problems are sometimes dealt easier in python space. Just as a deliverance similar/friendly solution might be a better solution than making a django admin skin "engine", a more generic configuration app might be better for advanced uses. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12801 : Allow empty non-nullable ForeignKey fields until save()
Maybe I can help Luc? I had similar questions once, because I started learning Django while deploying with a legacy database. On 8 fev, 20:31, Luc Saffre wrote: > You cannot ask user code to not even look at invalid data. I'm > not allergic to exceptions, but raising an exception when I ask for the > content of a field is not appropriate behaviour. > > Luc Raising the exception *is* appropriate behaviour, because when you access `a_model.b_related`, and `b_related` is a ForeignKey, you're not really accessing a value, but doing a lookup. This is consistent with both the ER and ORM model, where FK's are pointers, not values. And a FK pointing to a non-existant row *is* an exception. It means broken data. If you want the content of the *field*, what you really should check is `a_model.b_related_id is None`, which is checking if a pointer was set. Still, it doesn't guarantee that this pointer leads to anywhere valid. That's why dealing with the exception is a common idiom, "fail early, fail loudly", and particularly useful in this case to maintain DB consistency. I hope it helps in understanding the rationale behind the behaviour and why Luke marked as invalid. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
QuerySet.exists() - Possible bug?
Hi list
Using David Cramer's really nice replacement devserver
(http://github.com/dcramer/django-devserver), I noticed a bunch of
huge queries in some table generation code. Example:
http://dpaste.com/156907/
This is from one of my smallest tables, bigger ones with 120+ish rows
can take multiple ms to query.
I narrowed it down to a SomeModel.some_reverse_foreignkey.exists().
Using something as simple as .only("id").exists() will make the query
several dozen times faster.
Is this a bug, or am I missing something in exists() behaviour? From
what I understood, it's supposed to be faster than count() in
situations where I just need to know whether there are rows present.
Using psycopg2 with postgresql 8.4.
J. Leclanche / Adys
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: QuerySet.exists() - Possible bug?
On Wed, Feb 10, 2010 at 3:11 PM, Jerome Leclanche wrote:
> Hi list
>
> Using David Cramer's really nice replacement devserver
> (http://github.com/dcramer/django-devserver), I noticed a bunch of
> huge queries in some table generation code. Example:
> http://dpaste.com/156907/
> This is from one of my smallest tables, bigger ones with 120+ish rows
> can take multiple ms to query.
>
> I narrowed it down to a SomeModel.some_reverse_foreignkey.exists().
> Using something as simple as .only("id").exists() will make the query
> several dozen times faster.
>
> Is this a bug, or am I missing something in exists() behaviour? From
> what I understood, it's supposed to be faster than count() in
> situations where I just need to know whether there are rows present.
It certainly doesn't look right; .exists() should be faster than
.count(), and having all the extra columns in the query looks a little
weird.
However, to say for sure, we need a few more details:
* Does this only happen when using David's devserver, or does it
happen in a normal Django shell?
* Can you give a *specific* example of a model and query that is
causing this? Or, if it's happening in the process of running a
management command or other Django-internal activity, what do you need
to do to stimulate the problem?
* Are you doing anything interesting with select_related() or
anything like that?
* What version of Django (including SVN revision, if appropriate) are
you using?
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: QuerySet.exists() - Possible bug?
Django version 1.2 alpha 1 SVN-12267
I'm not using select_related at all anywhere at the moment, I just
started database optimization. David's server is just a wrapper
django-toolbar-like and doesn't perform anything smart on the sql or
the like.
I haven't yet tested on a vanilla setup, but I suppose something like
this should do the trick:
Class MyModel(Model):
field_1 = IntegerField()
field_2 = IntegerField()
field_3 = IntegerField()
field_4 = IntegerField()
field_5 = IntegerField()
class OtherModel(Model):
my_m2m = ForeignKey(MyModel, related_name="my_relation")
>>> MyModel.objects.all()[:1][0].my_relation.exists()
J. Leclanche / Adys
On Wed, Feb 10, 2010 at 9:22 AM, Russell Keith-Magee
wrote:
> On Wed, Feb 10, 2010 at 3:11 PM, Jerome Leclanche wrote:
>> Hi list
>>
>> Using David Cramer's really nice replacement devserver
>> (http://github.com/dcramer/django-devserver), I noticed a bunch of
>> huge queries in some table generation code. Example:
>> http://dpaste.com/156907/
>> This is from one of my smallest tables, bigger ones with 120+ish rows
>> can take multiple ms to query.
>>
>> I narrowed it down to a SomeModel.some_reverse_foreignkey.exists().
>> Using something as simple as .only("id").exists() will make the query
>> several dozen times faster.
>>
>> Is this a bug, or am I missing something in exists() behaviour? From
>> what I understood, it's supposed to be faster than count() in
>> situations where I just need to know whether there are rows present.
>
> It certainly doesn't look right; .exists() should be faster than
> .count(), and having all the extra columns in the query looks a little
> weird.
>
> However, to say for sure, we need a few more details:
>
> * Does this only happen when using David's devserver, or does it
> happen in a normal Django shell?
>
> * Can you give a *specific* example of a model and query that is
> causing this? Or, if it's happening in the process of running a
> management command or other Django-internal activity, what do you need
> to do to stimulate the problem?
>
> * Are you doing anything interesting with select_related() or
> anything like that?
>
> * What version of Django (including SVN revision, if appropriate) are
> you using?
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
