Re: Feedback on ticket #12399
The second patch [1] fixes the memcached backend. [1] http://code.djangoproject.com/attachment/ticket/12399/memcached-timeout-fixes.diff -- Gert Mobile: +32 498725202 Web: http://gert.selentic.net On Wed, Jan 27, 2010 at 08:28, Kristian Klette wrote: > > It's a nasty bug which leads to a 100% cache misses situation on > > memcached when using long keys timeouts. > > Wouldn't it be better to fix this in the memcache backend itself? It does > cause a backward compatibility problem for users that do takes this > memcached > behaviour into account in their code though. > > Either way, this memcached behaviour should be mentioned in the cache > documentation. > > - Kristian > > -- > 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.
Re: Feedback on ticket #12399
> It's a nasty bug which leads to a 100% cache misses situation on > memcached when using long keys timeouts. Wouldn't it be better to fix this in the memcache backend itself? It does cause a backward compatibility problem for users that do takes this memcached behaviour into account in their code though. Either way, this memcached behaviour should be mentioned in the cache documentation. - Kristian -- 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: Deleting related objects in the admin: patch for #6191
On Jan 26, 7:24 pm, Russell Keith-Magee wrote: > I'll put it on my list. It will probably still be a 'post 1.2-beta' > activity, but I'll try to look at it at the start of the bugfixing > phase. Great, thanks. Looking forward your feedback. Carl -- 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: Pony request: refetch method to models
On Wed, Jan 27, 2010 at 12:59 AM, Jukka wrote: > Hi all, > > I'd like to propose adding a method to Model that can be used to fetch > a "fresh" version of a model object from the database. This isn't a completely unreasonble idea, but it is an unreasonable time to suggest it :-) We are days away from our feature freeze for 1.2. At this point, any new ideas will need to wait until 1.3. I'm fairly certain this idea has been proposed before, so there's probably a ticket for it, too. If there isn't, open a new ticket so we don't forget the idea. If you want to propose this for 1.3, keep an eye on the release schedule; once 1.2 is released, we'll start discussing the features we want 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: Deleting related objects in the admin: patch for #6191
On Wed, Jan 27, 2010 at 2:00 AM, Carl Meyer wrote: > Hey all, > > During the Chicago sprint a few weeks ago I put together a patch for > #6191: the admin's "the following related objects will be deleted" > list in some cases omits items that actually are deleted (oops!). The > admin has its own routine for collecting related objects for > notification, separate from the ORM code that collects the objects for > deletion. This situation seemed ripe for further discrepancies down > the road, so rather than just fixing the immediate bug in the admin > routine I opted to make the admin notification reuse the ORM's > collect_sub_objects() method, so the same logic that is used to > actually delete the objects is used for the notification. > > I'd love to get this fix in for 1.2 if possible, since it involves > silent loss of data. It's a bug fix, so can go in post-beta; but it's > also a relatively large patch, so it seems like getting more eyes on > it sooner rather than later would be good. Patch works well for me, I > added a number of new tests and tests are passing (well, two unrelated > admin_views tests currently fail for me with or without the patch). > Anyone up for taking a look? I'll put it on my list. It will probably still be a 'post 1.2-beta' activity, but I'll try to look at it at the start of the bugfixing phase. 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: Feedback on ticket #12399
On Wed, Jan 27, 2010 at 12:30 AM, Giuseppe Ciotta wrote: > http://code.djangoproject.com/ticket/12399 > > It's a nasty bug which leads to a 100% cache misses situation on > memcached when using long keys timeouts. > > Do you think we can have this included in 1.2? Should i mark it with > Version:1.2 or something? The patch itself is trivial. Marking the ticket as "Milestone 1.2" will put it on the list of bugs that will be considered for 1.2. Looking at the patch, the one thing that is missing is tests. Without tests, a patch won't get anywhere near trunk, no matter how trivial. 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: Feedback requested: One last time with multi-db
On Jan 23, 7:05 am, Russell Keith-Magee wrote: > A full explanation, including an example is in the documentation > portion of the patch, attached to ticket #12542. > > Comments? This fixed our only (known) blocking problem towards 1.2, thanks so much. Brett -- 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: Pony request: refetch method to models
On Jan 26, 11:59 am, Jukka wrote: > Hi all, > > I'd like to propose adding a method to Model that can be used to fetch > a "fresh" version of a model object from the database. This is > something that I personally would often find useful. Usually this > happens when I'm testing some view code using the test client, and the > view is supposed to save some model changes into database. For > example: > > client.post('some_url', {'id': obj.id, 'description': 'new'}) > fresh_obj = ObjClass.objects.get(pk=obj.pk) > self.assertEqual('new', fresh_obj.description) > > Now, I think that way of refreshing a model object is inelegant. What > I propose is a method that would be functionally identical to how a > fresh object is fetched above: > > fresh_obj = obj.refetch() > > This is a convenience method, but based on my own experience it would > be... well, convenient. I'd like to hear whether you think the > convenience would be worth extending the api. If you think it's worth > it, I'd be happy to write a patch. > > --Jukka Why not just make a custom model method? -- 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.
Deleting related objects in the admin: patch for #6191
Hey all, During the Chicago sprint a few weeks ago I put together a patch for #6191: the admin's "the following related objects will be deleted" list in some cases omits items that actually are deleted (oops!). The admin has its own routine for collecting related objects for notification, separate from the ORM code that collects the objects for deletion. This situation seemed ripe for further discrepancies down the road, so rather than just fixing the immediate bug in the admin routine I opted to make the admin notification reuse the ORM's collect_sub_objects() method, so the same logic that is used to actually delete the objects is used for the notification. I'd love to get this fix in for 1.2 if possible, since it involves silent loss of data. It's a bug fix, so can go in post-beta; but it's also a relatively large patch, so it seems like getting more eyes on it sooner rather than later would be good. Patch works well for me, I added a number of new tests and tests are passing (well, two unrelated admin_views tests currently fail for me with or without the patch). Anyone up for taking a look? Thanks, Carl [1] http://code.djangoproject.com/ticket/6191 -- 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: Proposal: errors with URLs in them
On 2010-01-21, at 3:53 PM, Russell Keith-Magee wrote: > On Fri, Jan 22, 2010 at 1:35 AM, Andy McKay wrote: >> >> This is of course won't be possible for all errors or all parts of Django, >> but would work for some of the more common errors that crop up regularly. >> Would this be a course worth pursuing? > > I'd say yes - with some caveats. > > Firstly, we need to be careful about casting too wide a net in > catching errors. We don't want to accidentally catch errors and give a > solution that is wrong. We also don't want to hide useful errors under > a 'helpful' blanket (e.g., the way that Django sometimes masks import > errors). If we're going to introduce specific error messages, we need > to make sure they actually refer to a specific problem. Absolutely, this should be used sparingly. It just can be a bit frustrating because some of the start up or import errors can be a bit silent or cryptic. > I'm always hesitant to blame the user for problems like this. If the > user isn't following instructions, maybe the instructions aren't clear > enough. Maybe the error message in question is just too pithy -- > perhaps if they redirected to a single page in the docs that gave a > verbose explanation of the problem (including examples and workarounds > where appropriate), we might be able to avoid a few of these > questions. > However, in the words of Cool Hand Luke: "some folks, you just can't reach". > :-) I think it might help, you are right and we can't save everyone. But I think if we can document the error properly and in some detail somewhere, we'll at least feel good that we've done everything we can. > So - if you can produce a patch that demonstrates 5-10 examples of > patterns that would benefit from an elaborate error message, I > certainly think that patch could find it's way into trunk. Rightio, we'll give it a try a for a few and see how it lookis. Thanks for the -- Andy McKay, @clearwind http://clearwind.ca/djangoski -- 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.
Pony request: refetch method to models
Hi all, I'd like to propose adding a method to Model that can be used to fetch a "fresh" version of a model object from the database. This is something that I personally would often find useful. Usually this happens when I'm testing some view code using the test client, and the view is supposed to save some model changes into database. For example: client.post('some_url', {'id': obj.id, 'description': 'new'}) fresh_obj = ObjClass.objects.get(pk=obj.pk) self.assertEqual('new', fresh_obj.description) Now, I think that way of refreshing a model object is inelegant. What I propose is a method that would be functionally identical to how a fresh object is fetched above: fresh_obj = obj.refetch() This is a convenience method, but based on my own experience it would be... well, convenient. I'd like to hear whether you think the convenience would be worth extending the api. If you think it's worth it, I'd be happy to write a patch. --Jukka -- 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.
Feedback on ticket #12399
http://code.djangoproject.com/ticket/12399 It's a nasty bug which leads to a 100% cache misses situation on memcached when using long keys timeouts. Do you think we can have this included in 1.2? Should i mark it with Version:1.2 or something? The patch itself is trivial. -- 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: AnonymousUser has_perm/has_module_perms function check authentication backends
On Jan 26, 3:19 pm, Harro wrote: > - If the default backend always returns false for anonymous users then > pluggable apps have to either expect some row level permission system > is installed and used or don't check permissions for things that an > anonymous user can access. Why do they have to expect a row level permission system to be installed? The ModelBackend would always return False for anonymous, so everything would stay as it is… > I think the best solution is to add anonymous user permissions as > proposed by me a bit up, but only actually check them if a settings > flag is set to True (with a default on False). If it's not set it will > simply return False for anonymous users, otherwise it will check the > permissions. I am -1 on that, using `supports_anonymous_users` is way better and allows a cleaner upgrade path (as every backend will have to support anonymous users sooner or later) -- 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: AnonymousUser has_perm/has_module_perms function check authentication backends
On Tuesday 26 January 2010 12:12:23 Jari Pennanen wrote: > I read from "1.2 beta" thread that this might make it to the 1.2 > beta of Django, any status on that? Is someone trying to commit > the patches? Florian Apolloner pointed out that it had backwards incompatibility issues. I'm hoping to look at it tonight and see what I can do, probably along the lines of a 'supports_anonymous_users' attribute, like the 'supports_object_permissions' attribute. If anyone else can do a patch and let me know before 21:00 GMT, that would be great. Luke -- "The first ten million years were the worst. And the second ten million, they were the worst too. The third ten million, I didn't enjoy at all. After that I went into a bit of a decline." (Marvin the paranoid android) 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: AnonymousUser has_perm/has_module_perms function check authentication backends
I think so far we agree that we need to add something for anonymous users, because the added enhancement currently doesn't add enough to integrate row level permissions as they should be. The problems are: - Anonymous users should check the authentication backend for permissions, so it is possible to implement anonymous user permissions - If the default backend always returns false for anonymous users then pluggable apps have to either expect some row level permission system is installed and used or don't check permissions for things that an anonymous user can access. I think the best solution is to add anonymous user permissions as proposed by me a bit up, but only actually check them if a settings flag is set to True (with a default on False). If it's not set it will simply return False for anonymous users, otherwise it will check the permissions. That way pluggable apps decide for themselves if they want to check permissions for all users and if they do throw an error if the flag is not set. Or if they simply do it the old way by doing a login_required for the views that need logged in users. On Jan 26, 1:12 pm, Jari Pennanen wrote: > I read from "1.2 beta" thread that this might make it to the 1.2 beta > of Django, any status on that? Is someone trying to commit the patches? -- 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: Translation patch and the I18N mailinglist
On Tue, Jan 26, 2010 at 11:04, Jannis Leidel wrote: > Am 25.01.2010 um 23:06 schrieb TiNo : > > > Hi, >> >> I posted a message [1] to the Django I18N list on the 28th of December. >> Apparently, it is also the last message to that list. Is the I18N list dead? >> > > No, the mailing list isn't dead :) > > Jannis Ok, then I'll assume no dutch people are reading it, or nobody has an objection to the translation I suggested :) Tino -- 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: 1.2 beta?
On Tuesday 26 January 2010 11:30:45 Florian Apolloner wrote: > Hi, > > I am far away from beeing a commiter, but would like to get some > thoughts about the AnonymousUser permission checks written down > (I'll keep it short to not hijack this thread): By the time I > moved permission checks to the backends I didn't thought much > about anonymous users (I guess that was bad, but by that time I > never needed it). The current situation is as follows: If we pass > the AnonymousUser into the backend we will berak any code that > relied on the User object to be in the database [disclaimer: as > far as I can tell, we always said that the programmer should check > if the User is authenticated or not, but as we never passed > AnonymousUser into the backends I doubt someone checks that. > Though I guess most people used the backends to check against ldap > etc, so this would be a non issue…]. If you are okay with that, I > am +1 on whatever needs to be done to get this feature in. That's a good catch. Previously I was thinking that the change only affected the "per object" code, which was added since 1.1. The changed required to handle AnonymousUser is pretty simple, as demonstrated by the patch on the provided auth backend. However, it could easily catch people out. One possible migration strategy is to add a 'supports_anonymous_user' attribute, similar to 'supports_object_permissions'. Luke -- "The first ten million years were the worst. And the second ten million, they were the worst too. The third ten million, I didn't enjoy at all. After that I went into a bit of a decline." (Marvin the paranoid android) 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: 1.2 beta?
Am 26.01.2010 um 12:30 schrieb Florian Apolloner: > I am far away from beeing a commiter, but would like to get some > thoughts about the AnonymousUser permission checks written down (I'll > keep it short to not hijack this thread): By the time I moved > permission checks to the backends I didn't thought much about > anonymous users (I guess that was bad, but by that time I never needed > it). The current situation is as follows: If we pass the AnonymousUser > into the backend we will berak any code that relied on the User object > to be in the database [disclaimer: as far as I can tell, we always > said that the programmer should check if the User is authenticated or > not, but as we never passed AnonymousUser into the backends I doubt > someone checks that. Though I guess most people used the backends to > check against ldap etc, so this would be a non issue…]. If you are > okay with that, I am +1 on whatever needs to be done to get this > feature in. As mentioned in the other thread, I'm sceptical about adding more meaning to the AnonymousUser (making it a workflow item instead of a placeholder for "this request was made by a non-authorized user"). -0 The major issue here is backwards compatibility though. I'd be glad to know how we'd handle this. > Aside from that I would like to know what the status on admin-ui is, > as Janis worked on that lately. That said I don't see any real reason > why we would need to postpone the beta. This is indeed on my today's todo list, I worked on it during the sprint last weekend. Jannis -- 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: AnonymousUser has_perm/has_module_perms function check authentication backends
I read from "1.2 beta" thread that this might make it to the 1.2 beta of Django, any status on that? Is someone trying to commit the patches? -- 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: 1.2 beta?
Hi, I am far away from beeing a commiter, but would like to get some thoughts about the AnonymousUser permission checks written down (I'll keep it short to not hijack this thread): By the time I moved permission checks to the backends I didn't thought much about anonymous users (I guess that was bad, but by that time I never needed it). The current situation is as follows: If we pass the AnonymousUser into the backend we will berak any code that relied on the User object to be in the database [disclaimer: as far as I can tell, we always said that the programmer should check if the User is authenticated or not, but as we never passed AnonymousUser into the backends I doubt someone checks that. Though I guess most people used the backends to check against ldap etc, so this would be a non issue…]. If you are okay with that, I am +1 on whatever needs to be done to get this feature in. Aside from that I would like to know what the status on admin-ui is, as Janis worked on that lately. That said I don't see any real reason why we would need to postpone the beta. Cheers, Florian -- 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: Translation patch and the I18N mailinglist
Am 25.01.2010 um 23:06 schrieb TiNo : Hi, I posted a message [1] to the Django I18N list on the 28th of December. Apparently, it is also the last message to that list. Is the I18N list dead? No, the mailing list isn't dead :) Jannis -- 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: Translation patch and the I18N mailinglist
On Tue, Jan 26, 2010 at 01:55, Russell Keith-Magee wrote: > On Tue, Jan 26, 2010 at 6:06 AM, TiNo wrote: > > Hi, > > The reason I posted there was to see if anybody had any objections to the > > one-liner patch [2] I suggested for a dutch translation that is wrong at > the > > moment. It would be really nice to see this checked in for 1.2, as it has > > been looking quite confusing in the admin for quite a while now. > > Translations are traditionally the last thing that gets committed.As > long as the ticket is marked for the translations component, it's > almost guaranteed to get committed before 1.2 final. > Ok, thanks. -- 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.