Re: A.objects.getdefault
On 29 marras, 01:13, Wim Feijen wrote: > Hi, the patch has been updated and now works. > > Still, feedback would be appreciated. So, Anssi, Jacob? Apart of some whitespace errors the patch looks good to me. There isn't last() method in the patch. Implementing one is going to be a little more challenging as one needs to change the direction of all the ordering clauses. Do we want one in the same patch? A bigger problem might be that we already have .latest() which does something a bit different. I wonder if having both .last(filter_args) and .latest(by_field) is going to be confusing. Another API issue is that should .first() check for some ordering? This could add some protection. In testing conditions things might work, but when updates are done to the rows the expected ordering suddenly changes. One option is to do automatic ordering on PK if there isn't any other ordering present. I still like the idea of .get_default() mainly for the added "if multiple objects returned, then throw an error" protection it gives. >From implementation/maintenance perspective these are really easy additions, from API bloat perspective maybe not... - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: A.objects.getdefault
Hi, the patch has been updated and now works. Still, feedback would be appreciated. So, Anssi, Jacob? - Wim Op maandag 19 november 2012 22:48:36 UTC+1 schreef Wim Feijen het volgende: > > Hi, > > I do like the first() method and went ahead and *tried* to implement it. > > Ticket: > https://code.djangoproject.com/ticket/19326 > > Patch, including tests and doc changes: > https://code.djangoproject.com/attachment/ticket/19326/19326.diff > > Unfortunately, tests fail. Probably ordering is wrong, or I am making a > stupid mistake. > > Can somebody experienced at db/models/query.py have a look at my patch? > > Thanks! > > Wim > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/kJZjTBzqQzAJ. To post to this group, send email to django-developers@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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)
>> - A hypothetical middleware that appends debug information to the end
>> of the response. debug-toolbar may be able to work like this.
> Looking for the boils down to the same problem as above, and can't be
> implemented without consuming the content for the same reason.
It can be done, it's just a little harder for streaming. If the chunk
you are processing ends with any prefix of '', that is, ('<',
'' again.. I don't think this counts as 'consuming' the
content, because you'll only combine combine a few chunks, and only
when necessary.
This treatment, while difficult, is totally necessary when dealing
with iterators over responses, no matter the API. Since you have to
write the complex stream processing anyway (assuming you want to work
with streaming responses), HttpResponse should not force you to write
an additional implementation for the plain, non-streaming response.
> You can probably abstract the pattern in a response middleware base class.
That's a good idea, and it's probably what I'll do if this doesn't
make it into Django. I think this use case is common enough for
HttpResponse to handle, though.
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)
Hi Gavin,
The whole point of the HttpStreamingResponse API to access the content is to be
incompatible with HttpResponse. Otherwise it's too easy to consume streamed
content accidentally.
Re-introducing a common API ("streaming_content") would remove that benefit, it
would be confusing in the non-streamed case, and it would certainly be misused
("yes I just used ''.join(streamed_content), isn't that the canonical way to
access response content in all cases?").
The incompatible API is a hint that you must think about what you're doing when
you're writing streaming-aware middleware, and specifically, that you mustn't
consume the iterator.
Your goal is interesting but it seems optimistic to me. Out of the four
examples you gave, two are very hard to implement correctly for streaming
responses.
> - GzipMiddleware (compress_string(x) == compress_sequence([x]))
This one is implemented by Django. If you look at the code, you'll see it's
reasonable to use a different implementation for the streamed and not-streamed
cases.
> - StripWhitespaceMiddleware
For this one, the pattern would be:
if response.streaming:
response.streaming_content = itertools.imap(strip_whitespace,
response.streaming_content)
else:
response.content = strip_whitespace(response.content)
Yes, this is a bit of boilerplate. I'd like to reduce it, but not at the cost
of giving a streaming_content attribute to regular responses; it's too
confusing. You can probably abstract the pattern in a response middleware base
class. That works only when the "transform" function can be applied to any
subset of the content. I don't expect many useful middleware to fall in this
category
> - ContentDoctorMiddleware (https://github.com/unomena/django-content-doctor)
This won't work on streaming responses without consuming the content, because a
match for the regex may overlap a boundary between response chunks.
> - A hypothetical middleware that appends debug information to the end
> of the response. debug-toolbar may be able to work like this.
Looking for the boils down to the same problem as above, and can't be
implemented without consuming the content for the same reason.
--
Aymeric.
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Performance problems due to incorrect many-many primary key on many tables
On 27 marras, 21:11, Trey Raymond wrote: > Hi folks, > I'm a DB engineer working for Yahoo, and we have a new product using django > that I'm onboarding. We see a variety of easily fixed issues, but one > major one - there are 21 many-many tables here, yet they have auto > increment primary keys. This of course is very slow on any platform, but > particularly can't use clustering on innodb (you can't, obviously, use > myisam on a production system) and the performance of queries on these > tables is severely degraded. I can't onboard them properly until we fix > these, but they claim the code throws errors when I do - I can't figure out > what could possibly reference the field, but something does. If you have > any suggestions on an easy way (they have limited dev resources, and us > DBE's can't work on code directly) to remove these references, a setting or > a very simple change, I'd appreciate it...also consider this a bug report > for future versions. The problem is that m2m relations are using Models in the underlying implementation, and every Django model must have a single field primary key. I have a feeling that any hack allowing the removal of the redundant PK from m2m relations only is going to look really ugly. Although I am more than happy if somebody proves me wrong... I do agree that the "id" primary key in m2m relations isn't necessary and is bad for performance reasons for example. And that we should fix this. The best way forward might be to make the ORM work with composite primary keys. But we could still keep this non-public. There has been some work to support composite primary keys in Django. I haven't followed the work closely, but if I understand the situation correctly one of the biggest problems is that making all of Django composite PK friendly in one go is somewhat daunting. Actually, some parts of Django do not work too nicely with non-integer or modifiable primary keys. Of course after the ORM supports composite PKs then the next step would be to make rest of Django support composite PKs, too, and have a public API for composite PK models. All in all +1 to fixing this, but I am not sure what is the best way to achieve this. Ideas welcome... - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)
- GzipMiddleware (compress_string(x) == compress_sequence([x])) - StripWhitespaceMiddleware - ContentDoctorMiddleware (https://github.com/unomena/django-content-doctor) - A hypothetical middleware that appends debug information to the end of the response. debug-toolbar may be able to work like this. On Wed, Nov 28, 2012 at 11:07 AM, Aymeric Augustin wrote: > 2012/11/28 Gavin Wahl >> >> I would like to avoid having two code paths, one with streaming and one >> without, in new middleware. > > > Hi Gavin, > > Could you give an example of a middleware that: > - needs to alter the content, > - will work identically both on regular HttpResponses and > StreamingHttpResponses, > - will not consume a streamed content (that's part of the contract of > StreamingHttpResponse)? > > Thanks, > > -- > Aymeric. > > -- > 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 > 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-developers@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: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)
2012/11/28 Gavin Wahl > I would like to avoid having two code paths, one with streaming and one > without, in new middleware. > Hi Gavin, Could you give an example of a middleware that: - needs to alter the content, - will work identically both on regular HttpResponses and StreamingHttpResponses, - will not consume a streamed content (that's part of the contract of StreamingHttpResponse)? Thanks, -- Aymeric. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Performance problems due to incorrect many-many primary key on many tables
Hi folks, I'm a DB engineer working for Yahoo, and we have a new product using django that I'm onboarding. We see a variety of easily fixed issues, but one major one - there are 21 many-many tables here, yet they have auto increment primary keys. This of course is very slow on any platform, but particularly can't use clustering on innodb (you can't, obviously, use myisam on a production system) and the performance of queries on these tables is severely degraded. I can't onboard them properly until we fix these, but they claim the code throws errors when I do - I can't figure out what could possibly reference the field, but something does. If you have any suggestions on an easy way (they have limited dev resources, and us DBE's can't work on code directly) to remove these references, a setting or a very simple change, I'd appreciate it...also consider this a bug report for future versions. More info below, but thank you guys Trey Raymond Example, existing: CREATE TABLE `accounts_profile_starred_groups` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `profile_id` int(10) unsigned NOT NULL, `group_id` int(10) unsigned NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `profile_id` (`profile_id`,`group_id`), KEY `group_id_refs_id_e2f1545` (`group_id`) ) ENGINE=InnoDB; Fixed: CREATE TABLE `accounts_profile_starred_groups` ( `profile_id` int(10) unsigned NOT NULL, `group_id` int(10) unsigned NOT NULL, PRIMARY KEY (`profile_id`,`group_id`), KEY `group_id_refs_id_e2f1545` (`group_id`) ) ENGINE=InnoDB; The table list: accounts_profile_starred_groups accounts_profile_starred_review_requests accounts_reviewrequestvisit auth_group_permissions auth_user_groups auth_user_user_permissions reviews_defaultreviewer_groups reviews_defaultreviewer_people reviews_defaultreviewer_repository reviews_group_users reviews_review_comments reviews_review_screenshot_comments reviews_reviewrequest_changedescs reviews_reviewrequest_inactive_screenshots reviews_reviewrequest_screenshots reviews_reviewrequest_target_groups reviews_reviewrequest_target_people reviews_reviewrequestdraft_inactive_screenshots reviews_reviewrequestdraft_screenshots reviews_reviewrequestdraft_target_groups reviews_reviewrequestdraft_target_people -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ziyEeocC-9UJ. To post to this group, send email to django-developers@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: Namspace packages in Django
We are experiencing the same problem that DavidR mentioned. We took the patch that was provided by #19048 and tested it out and it worked for us; however, it was closed as a duplicate of #8280. They don't seem to be duplicates as #8280 is talking about the Django code actually searching for .py files and the code as it is today does not do that. #19048 does use the python APIs for importing modules, but that has already been done. #19048 does not implement the zip egg loader like the latest patch in #8280, but it does fix the namespace package problem. What needs to be done to get the patch from #19048 into core? How can I help? On Wednesday, January 5, 2011 1:46:13 PM UTC-7, nfg wrote: > > on., 05.01.2011 kl. 09.32 +0800, skrev Russell Keith-Magee: > > A similar request was made in ticket #14087. I closed that ticket as > > wontfix because allowing multiple applications with the same name is > > fundamentally problematic; however, you have highlighted that that > > this problem isn't tied to having two apps with the same name in a > > project. > > I have uploaded at git diff file to that ticket. > > > Even better, you've provided a test case that demonstrates the problem > > within normal usage. > > > > So - I'm happy to reopen this ticket, and use your github branch as an > > RFC patch. The core team is able to pull from github, but If you could > > upload a raw patch version to Trac, that would also be helpful. > > That's great :) > > -- > Nils Fredrik Gjerull > - > "Ministry of Eternal Affairs" > Computer Department > ( Not an official title :) ) > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/ev7mKwI4dCsJ. To post to this group, send email to django-developers@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.
Admin Javascript Roadmap/Brainstorming
Hi Djangonauts, I'm a frontend developer at a Django shop and lately we have doing a lot of projects that customize the Django admin interface. Adding confirmation popups, custom interface for certain types of content, etc. One very frustrating part of this has been overriding or extending the behaviour of a lot of the included Javascript. I'm starting this thread to cull the opinions of the Django community about what they'd like to see from the Admin Javascript. I'll start with some pain points, and some ideas I have to improve it: - jQuery: Inlines are written as a jQuery plugin, DateTime and i18n are written without jQuery. The version of jQuery included is 1.4.2, which is ~3 years old. Do we want to have jQuery in this project? I think Django should include it, as it helps solve a lot of browser inconsistencies and is familiar to all JS devs. But if so, we should try to keep it up to date. - Not extensible: Behaviour for the jQuery plugins are defined in template blocks which are somewhat easy to customize, while DateTimeShortcuts uses href="javascript:void" links generated dynamically, which are nearly impossible to override. I'd like to rewrite the Admin JS to use a Backbone like structure, where all the necessary JS is initialized as an instance from one place by calling `new` and a .extend() function can be used where the developer wants to customize behaviour. This change would be pretty radical but I feel it would be for the better. I'm eager to start working on pull requests for some of these changes (smaller first) but I wanted to take the pulse of django-developers first and see how they felt about it. Thanks, -Tyler -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/DDx51WNU-RIJ. To post to this group, send email to django-developers@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.
[ANNOUNCE] Django 1.5 beta 1 released
Our second milestone on the road to Django 1.5 came today, with the release of the first beta package. Blog post about it is here: https://www.djangoproject.com/weblog/2012/nov/27/15-beta-1/ Release notes are here: https://docs.djangoproject.com/en/dev/releases/1.5-beta-1/ And you can get the alpha from the downloads page: https://www.djangoproject.com/download/ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Streaming HttpResponse revisted. Any core devs, please take a look if you can :)
I would like to avoid having two code paths, one with streaming and one without, in new middleware. If `HttpResponse` followed the the `streaming_content` API as well, when writing a streaming-aware middleware instead of writing if response.streaming: response.streaming_content = wrap_streaming_content(response.streaming_content) else: response.content = wrap_content(response.content) One could write response.streaming_content = wrap_streaming_content(response.streaming_content) The behavior for `StreamingHttpResponse` would be the same, but `HttpResponse` would consume the iterator assigned to `streaming_content` and store it in `content`. Since an iterator (`streaming_content`) can be trivially converted to a string (`content`), this would prevent having to write to versions of `wrap_content`, one for iterators and the other for strings. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/QSNgS_hd4YcJ. To post to this group, send email to django-developers@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.
I'd like to make a contribution to the wiki
It's for promotional purposes really - I want to add my employers, PythonAnywhere, to the list of Django-Friendly-Web-Hosts https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts But it's not entirely one-sided and evil-marketing-spammy. We do offer Django hosting as part of our Free plan, so it's a nice place for people to come and try out Django, for free, maybe host a prototype web app... I'd be very happy help out more generally, by, say, cleaning up that page, fixing/removing broken links (I found a few), etc... I'd need WIKI_ADMIN privileges on the trac instance. my username is hjwp. rgds, Harry -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/h6XZT7_QucIJ. To post to this group, send email to django-developers@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.
Remove Trac ORM Aggregation component
I suggest that we merge the ORM Aggregation component to the Database layer component. The ORM Aggregation is the only subcomponent of the ORM. To be consistet we should either have more ORM subcomponents or none at all. I don't feel like splitting the Database layer into subcomponents improves the usage experience of Trac. For my usage experience the merge would be an improvement. I usually search using just the Database Layer. Having the ORM Aggregation component in the same category would thus make life a little bit easier for me. This isn't at all important. But if this is easy to do this seems like a good idea to me. - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trigger an event on add another
FTR, another solution is to intercept creation of tags with DOMNodeInserted. Requires no monkey patch and is compatible with django & django-grappelli out of the box: https://github.com/yourlabs/django-autocomplete-light/commit/1f1e715e20 Thanks again for your answer (which I credited in the related github issue). Rock'on -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/0WE7Hx4YOXwJ. To post to this group, send email to django-developers@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: Improved ajax support idea
Wow, thanks a lot. I would like to thanks everybody who answered. I have learned a lot from this thread and thanks to you I believe I am a better programmer. FTR, I've added an article to my blog which obsoletes the previous article. Kind regards from Spain On Tue, Nov 27, 2012 at 8:22 PM, Javier Guerra Giraldez wrote: > On Sun, Nov 25, 2012 at 12:04 PM, James Pic wrote: > > it would be great if we could make urls easier to reverse in Javascript. > > you shouldn't have to. > > good REST design means not using database IDs. any response that > references server resources should send a whole URL. no need to > construct them in the client. check the HATEOAS principle. > > http://www.slideshare.net/trilancer/why-hateoas-1547275 > > > > -- > Javier > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- http://blog.yourlabs.org Customer is king - Le client est roi - El cliente es rey. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
