Ticket #648 -- {# comment goes here #} style comments
Normally I wouldn't post here since I just posted to the ticket, but
since it's marked "closed" I didn't want it to be lost in the ether.
I've added a patch for ticket #648 and recommend reconsidering the
validity of the original point... Personally, I think that it would be
great to have {# comment goes here #} style comments.
http://code.djangoproject.com/ticket/648
Any feedback?
Thanks,
--Ben
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
> Some tests for > your patch wouldn't go amiss, though I realise it's a pain writing > tests for code when you don't know if it's going to be used. Unfortunately, I don't think I'll be able to find the time to write tests. Realistically, no external functionality should be impacted. Because the original code for template parsing was so elegant, the modifications were incredibly simple... if someone else has time to write a few tests, I'd be appreciative. --Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
> So - if you want your patches taken seriously, treat them seriously - > don't just write them, test them too (and not just a token test either > - REALLY test them). Especially when the testing framework is already > in place for something like template tags. I don't dispute the concept here, but it would help to have a django-testing document. I'm new to python (as are a lot of django-ers, I gather), so a hit-the-ground-running overview of the django test suite would allow me to make more meaningful contributions. There's a high barrier to entry when I have to deconstruct the test architecture before I can contribute a simple patch. If you have any recommendations of where I can look, I'm willing to learn... but I as with most developers, time is scarce. > This isn't in dispute. Adrian has decreed that #648 is rejected. It > wasn't because it was hard to implement. Check the mailing list > archives for the discussion that occurred when ticket #648 was > rejected for the reasoning behind the decision. Fair enough (though I obviously don't agree with the decision). I just saw that Adrian had made a few modifications to the ticket after it had already been closed. --Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
> So - if you want your patches taken seriously, treat them seriously - > don't just write them, test them too (and not just a token test either > - REALLY test them). Especially when the testing framework is already > in place for something like template tags. I don't dispute the concept here, but it would help to have a django-testing document. I'm new to python (as are a lot of django-ers, I gather), so a hit-the-ground-running overview of the django test suite would allow me to make more meaningful contributions. There's a high barrier to entry when I have to deconstruct the test architecture before I can contribute a simple patch. If you have any recommendations of where I can look, I'm willing to learn... but I as with most developers, time is scarce. > This isn't in dispute. Adrian has decreed that #648 is rejected. It > wasn't because it was hard to implement. Check the mailing list > archives for the discussion that occurred when ticket #648 was > rejected for the reasoning behind the decision. Fair enough (though I obviously don't agree with the decision). I just saw that Adrian had made a few modifications to the ticket after it had already been closed. --Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
I don't know how I missed that... still that's more a django-users guide from what I can discern... write tests for your own applications. It doesn't explain how the django-developers have constructed their test suites, and how one can build upon them. Nonetheless, having this doc helps and I'll work through it when I get a chance. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #648 -- {# comment goes here #} style comments
Awesome! Thanks Will :-) Seeing the diff you made makes it a lot easier to learn how to make my own tests. Also, thanks for performing the diff from the root this time. My mistake in issuing it from within the tree. Thanks again, --Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Compacting SQL queries
Hi all, I'm wondering if there's a way to generate more compact queries in the DB layer. For example, when I have a model: === class Object(models.Model): bar = models.ForeignKey(...) foo = models.CharField(...) something = models.DateTimeField(...) === Object.objects.get(pk=1) results in the following query (I think): === SELECT `app_object`.`id`,`app_object`.`bar_id`,`app_object`.`foo`,`app_object`.`something` FROM `app_object` WHERE (`app_object`.`id` = 1) === (138 chars) This could be turned into: === SELECT `a`.`id`,`a`.`bar_id`,`a`.`foo`,`a`.`something` FROM `app_object` as `a` WHERE (`a`.`id` = 1) === (100 chars ~ 25% reduction) Or in the general case (without .values(), all entries are requested): === SELECT * FROM `app_object` as `a` WHERE (`a`.`id` = 1) === (54 chars ~ 60% reduction) So, my first question is... is this possible? My second question is... if we can, is there any real value (specifically for very large sites)? Thanks, --Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Database race conditions when using multiple processes
Michael Radziej wrote: > > What about > SELECT ... FOR UPDATE > ) Michael, I know you're already aware of this (heck, you're CCed on the ticket), but for others... I created a patch in ticket http://code.djangoproject.com/ticket/2705 to allow a .for_update() modifier to be applied to a QuerySet, so you can do: something = models.Something.objects.filter(id=333).for_update().get() This wouldn't solve the get_or_create() problem, but it is helpful for a lot of other use cases. --Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
