Re: Reversing translated urls in templates
On 04.07.2011, at 02:48, Chris Beaven wrote:
>
> On Monday, July 4, 2011 1:42:37 AM UTC+12, brocaar wrote:
> What about not implementing this as a url tag but as a translation-
> override tag? Then it is not only possible to specify the language to
> use for your URL translation, but as well for other translatable
> content. Example:
>
> {% transoverride language_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endtransoverride %}
Oh, I like that much better, too.
> That does have the advantage of being more flexible even in just the context
> of urls. For example, referring to a url via {{ obj.get_absolute_url }}.
> +1 for more flexibility.
>
> That's one ugly tag name though :D
Agreed, what about just "language", e.g.:
{% language lang_code %}
{% trans "Register account" %}: {% url account:register %}
{% endlanguage %}
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-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.
shell command breaking custom (PYTHONSTARTUP) autocomplete
Hi everyone and first thanks for the fine framework (getting finer everyday). So well, possibly not something very important, but it's been 2 years now since I first filled a ticket, and while it seems an easy fix, nothing happened so far. Any chance this will make it into the trunk someday ? https://code.djangoproject.com/ticket/9990 If there's anything more I can do to help, please just tell. TIA Bruno -- 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: Reversing translated urls in templates
On Monday, July 4, 2011 10:04:10 AM UTC+2, Jannis Leidel wrote:
>
> Agreed, what about just "language", e.g.:
>
> {% language lang_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endlanguage %}
>
>
> I agree too that the tag name in my example is quite ugly, it was only to
clarify my idea ;) Just "language" sounds perfect!
Orne
--
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/-/huy6SEXMIBkJ.
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: Named tuples queryset
Hi Yuri, I have not tested them for speed, but: - Named tuples have no instance dictionary, so their instances take no more space than a regular tuple (for example, casting thousands of sql records to named tuples has zero memory overhead). - They also use C-speed attribute lookup using property() and itemgetter() I don’t really think that speed of collection (which is built into python 2.6+) is much slower than dicts etc. On Jul 4, 2011, at 7:41 AM, burc...@gmail.com wrote: > Hi Paul, > > Is it correct that nametuple construction is much slower than for > normal ones or is this true only in older python versions? > > On Mon, Jul 4, 2011 at 1:47 AM, paulpmillr wrote: >> Hello. >> >> I've added an implementation for named tuples query set, see >> https://code.djangoproject.com/ticket/15648 >> >> - Named tuples could be iterated over with order saving (like lists / >> tuples). >> - Properties there could be accessed with dot notation - post.topic >> (almost like dicts). >> - They could be converted both to dicts and lists >> - Easy debugging (pros over queryset.deferred()) >> - I've provided a fallback implementation of named tuple for python >> 2.5 users >> - Tests are there too. >> >> Named tuples eliminate neediness in values & values_list because they >> have all their features. >> >> What do you think about it? > > -- > Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com > > -- > 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
+1 On Mon, Jul 4, 2011 at 6:13 AM, Ryan wrote: > Umm... How about now? I've been bitten by trailing/leading blank spaces in > form inputs several times now, and I'm tired of monkey patching django to > fix this. Thanks. > > Ryan > > -- > 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/-/qF5BK8fUsKMJ. > 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: Named tuples queryset
I was told that for Python 2.5 nametuples "emulation" is 8 times slower than regular tuples and dicts. That's why I'm interested in benchmarks. If it's significantly slower (at least for Python 2.4 and 2.5), this should be mentioned in docs. On Mon, Jul 4, 2011 at 5:19 PM, Paul Miller wrote: > Hi Yuri, > > I have not tested them for speed, but: > > - Named tuples have no instance dictionary, so their instances take no more > space than a regular tuple (for example, casting thousands of sql records to > named tuples has zero memory overhead). > - They also use C-speed attribute lookup using property() and itemgetter() > > I don’t really think that speed of collection (which is built into python > 2.6+) is much slower than dicts etc. > > > On Jul 4, 2011, at 7:41 AM, burc...@gmail.com wrote: > >> Hi Paul, >> >> Is it correct that nametuple construction is much slower than for >> normal ones or is this true only in older python versions? >> >> On Mon, Jul 4, 2011 at 1:47 AM, paulpmillr wrote: >>> Hello. >>> >>> I've added an implementation for named tuples query set, see >>> https://code.djangoproject.com/ticket/15648 >>> >>> - Named tuples could be iterated over with order saving (like lists / >>> tuples). >>> - Properties there could be accessed with dot notation - post.topic >>> (almost like dicts). >>> - They could be converted both to dicts and lists >>> - Easy debugging (pros over queryset.deferred()) >>> - I've provided a fallback implementation of named tuple for python >>> 2.5 users >>> - Tests are there too. >>> >>> Named tuples eliminate neediness in values & values_list because they >>> have all their features. >>> >>> What do you think about it? >> >> -- >> Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com >> >> -- >> 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. > > -- Best regards, Yuri V. Baburov, Skype: yuri.baburov, MSN: bu...@live.com -- 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: Named tuples queryset
On Mon, Jul 4, 2011 at 11:19 AM, Paul Miller wrote: > Hi Yuri, > > I have not tested them for speed, but: > > - Named tuples have no instance dictionary, so their instances take no more > space than a regular tuple (for example, casting thousands of sql records to > named tuples has zero memory overhead). > - They also use C-speed attribute lookup using property() and itemgetter() > > I don’t really think that speed of collection (which is built into python > 2.6+) is much slower than dicts etc. > > It would be easier just to benchmark the before and after and see. Using statistics we can easily then see what the effect is. http://ivoras.net/blog/tree/2009-12-02.using-ministat.html Cheers Tom -- 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: Resetting cache gracefully at the end of every test?
I've created a ticket for this and uploaded a patch: https://code.djangoproject.com/ticket/16401 Please feel free to review and let me know if this is a good idea in the first place, as well as if the patch makes sense and is the right approach. Thanks, Jim -- 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: Reversing translated urls in templates
I like this quite a bit. It's clean, and it allows for a common i18n pattern
where the footer contains a translation link for each supported language, and
the language names are localized to themselves (i.e. "Español | Français |
Deutsch").
Sam
On 2011-07-04, at 5:23 AM, brocaar wrote:
> On Monday, July 4, 2011 10:04:10 AM UTC+2, Jannis Leidel wrote:
> Agreed, what about just "language", e.g.:
>
> {% language lang_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endlanguage %}
>
>
>
> I agree too that the tag name in my example is quite ugly, it was only to
> clarify my idea ;) Just "language" sounds perfect!
>
> Orne
>
> --
> 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/-/huy6SEXMIBkJ.
> 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On Mon, Jul 4, 2011 at 12:13 AM, Ryan wrote: > Umm... How about now? Sorry, but this isn't going to happen. I left more information on the ticket: https://code.djangoproject.com/ticket/6362#comment:43. Jacob -- 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: Resetting cache gracefully at the end of every test?
On Mon, Jul 4, 2011 at 8:54 AM, Jim Dalton wrote: > I've created a ticket for this and uploaded a patch: > https://code.djangoproject.com/ticket/16401 > Please feel free to review and let me know if this is a good idea in the > first place, as well as if the patch makes sense and is the right approach. Hm. While I think the feature's a good idea (I've been stung by tests running against a live cache) I can't say I'm particularly thrilled by the approach here. Monkeypatching is acceptable in situations like these, but there's a limit... and I think patching five methods is starting to reach it. Remember: as much as possible, tests should operate just like production. Any difference, no matter how small, introduces the worst kind of bugs: ones that only show up in production. I have an alternate proposal: Instead of using the default cache defined in CACHES, use a "test cache." This can safely be flushed, meaning that no monkeypatching is needed. The added benefit here is that this works similarly to the database engine, so it'll be fairly easy to understand. Now, unlike DB test we can't just prefix "test_" to the database name (because we haven't got one), nor can we prefix keys (because not all cache backends can do something like "delete test:*"). So I'd suggest we look for a "test" backend defined in CACHES and fall back to a local memory cache if not defined. I think this simplifies things immensely, and also gives a fair bit of control -- if I want to test against a real cache backend, I just define CACHES['test'] and roll. Jacob -- 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On Jul 4, 4:52 pm, Jacob Kaplan-Moss wrote: > On Mon, Jul 4, 2011 at 12:13 AM, Ryan wrote: > > Umm... How about now? > > Sorry, but this isn't going to happen. I left more information on the > ticket:https://code.djangoproject.com/ticket/6362#comment:43. It sounds like you've never been bitten by strip bugs. Here's the ones I've been through: 1. User inputs "foo " in some kind of identifier that is matched verbatim when doing a DB query. User can now not login/find his stuff/ whatever. Or the error is catched by a check regexp and instead the poor sod cannot create a user and don't understand why as the space is invisible. EmailField and date/time fields used to have this bug: https://code.djangoproject.com/log/django/trunk/django/forms/fields.py 2. User clears a field by selecting the text and hitting space bar (why you would do that is beyond me, but some people do it). Now the field is submitted as " " instead of "" which to Django is not blank. Code that kicks in if the field is not blank now kicks in even though there's no value. Something breaks. 3. User inputs "Foo " as first name, everything looks fine in HTML because HTML strips extraneous spaces, but once you send the person a text confirmation, you send it to "Dear Foo ," instead of "Dear Foo,". The truth is that almost all char form fields intended for humans should be stripped (do you think this is incorrect?), and it's easy to forget to do it. Ole -- 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: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On Mon, Jul 4, 2011 at 10:59 AM, Ole Laursen wrote: > It sounds like you've never been bitten by strip bugs. Then I must haven't been clear enough -- sorry -- because I certainly have, many times. I've also found it incredibly easy to solve in my user code: ``form.cleaned_data['field'].strip()``. Explicit is better than implicit, remember? :) Doesn't do anything to change my point, though: a framework can't go about stripping user input. That's a user-code decision. If Django strips out data I wanted, there's nothing I can do to get it back. Jacob -- 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: [GSoC form-rendering] Weekly Check-in
Hi, I wrote mainly documentation in the last week for how to use the new form rendering as well as references in the template tag listing. I've also implemented the form, formrow and formfield tags, I thought we might want to have something to play with sooner than later. The docs/tests etc can be found in my github branch. -- Servus, Gregor Müllegger -- 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.
Django ORM enchantments
I have implemented proof of concept versions of conditional
aggregation, F-lookups in aggregates and annotating fields to a model
(qs.field_annotate(age_x2=F('age')*2), note: no aggregation here). See
ticket #11305 for more details.
I would also hope to implement a patch which would allow to annotate
reverse related models. The idea would be most useful for fetching
translation models.
Given models:
Article(
id=IntegerField()
default_lang=CharField()
)
ArticleTranslation(
article=ForeignKey(Article, related_name='translations')
name=TextField()
abstract=TextField()
content=TextField()
lang=CharField()
class Meta:
unique_together = ('article', 'lang')
)
And queryset:
Aricle.objects.annotate(
translation_def=ModelAnnotation(
'translations',
only=Q(translations__lang=F('default_lang'))
),
translation_fi=ModelAnnotation(
'translations',
only=Q(translations__lang='fi')
)
)
The above query would generate something like this:
select article.id, article.default_lang, t1.name, ..., t3.name
from article
left join article_translation t1 on article.id = t1.article_id and
t1.lang = 'fi'
left join article_translation t3 on article.id = t3.article_id and
t3.lang = article.default_lang
And the objects returned would have (possibly None-valued)
translation_fi and translation_def instances attached to them.
These features require a lot of work before anything commit-quality is
ready. I would ask if the community would consider these ideas before
I do too much work. These patches would also require some attention
from somebody with more ORM knowledge than I have. The ModelAnnotation
idea is probably too hard for me to implement in even near commit-
quality.
These features would naturally make the ORM more powerful, but I see
some objections to these features:
1. They will make the already complex ORM even more complex. This
will result in new bugs and it will be harder to add new features to
the ORM.
2. Django ORM has the philosophy of "80/20". Meaning that the ORM
should make it possible to run 80% of your queries, the rest can be
done using raw SQL. Are these features beyond the 80% threshold?
3. As the queries become more complex, it is likely that the ORM will
not be able to generate efficient SQL. If this is the case raw SQL is
needed. Back to square 1.
4. The ORM is nearing the point where the API is too complex. Instead
of writing complicated SQL, you will be writing complicate ORM
queries.
On the other hand, combined with custom F() expressions, the need
for .extra() would be smaller and maybe it could even be deprecated in
the future.
- 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: Resetting cache gracefully at the end of every test?
On Jul 4, 2011, at 8:01 AM, Jacob Kaplan-Moss wrote: > On Mon, Jul 4, 2011 at 8:54 AM, Jim Dalton wrote: >> I've created a ticket for this and uploaded a patch: >> https://code.djangoproject.com/ticket/16401 >> Please feel free to review and let me know if this is a good idea in the >> first place, as well as if the patch makes sense and is the right approach. > > Hm. > > While I think the feature's a good idea (I've been stung by tests > running against a live cache) I can't say I'm particularly thrilled by > the approach here. Monkeypatching is acceptable in situations like > these, but there's a limit... and I think patching five methods is > starting to reach it. Remember: as much as possible, tests should > operate just like production. Any difference, no matter how small, > introduces the worst kind of bugs: ones that only show up in > production. Yeah, I agree with you in principle there. I'm definitely an advocate of avoiding monkey patching like the plague in production code. While I also agree that this code looks a bit hairy when you sort of squint your eyes at it, if you actually look closely at what's going on, we're not modifying things in any way that's tricky or complicated. Really, the only two things we are doing are adding a bit of code that that tracks keys and then swapping a few methods out. Pretty similar to what we do already with Template.render -- just x5. The monkey patching stuff is not modifying any arguments or results, nor is it changing the observable behavior of the modified methods. The tests demonstrate this pretty thoroughly. The only place I've managed to think of where this is different from production is in the length of the key. Because we are appending "_test_" to the start of KEY_PREFIX, you're going to get 6 less characters in your key than you would otherwise. It *is* a difference, so I don't want to downplay it, but at the same time it's a difference where you'll get an error in testing that you wouldn't get in production -- which is better than the opposite. The only other place where someone might run into trouble is if they themselves were monkey patching the cache and their changes collided somehow. I understand that this is the kind of thing that happens in Ruby a lot, and it strikes me as unpleasant. Anyhow, that's not to say that there isn't a better solution or that your proposal below isn't preferable (more on that in a sec), but I'd argue that my patch is at least a plausible solution, i.e. it works in lieu of a better alternative. > I have an alternate proposal: > > Instead of using the default cache defined in CACHES, use a "test > cache." This can safely be flushed, meaning that no monkeypatching is > needed. The added benefit here is that this works similarly to the > database engine, so it'll be fairly easy to understand. > > Now, unlike DB test we can't just prefix "test_" to the database name > (because we haven't got one), nor can we prefix keys (because not all > cache backends can do something like "delete test:*"). So I'd suggest > we look for a "test" backend defined in CACHES and fall back to a > local memory cache if not defined. > > I think this simplifies things immensely, and also gives a fair bit of > control -- if I want to test against a real cache backend, I just > define CACHES['test'] and roll. So, in many ways I like this idea. I agree that the implementation is going to be more straightforward. Here's just a quick list of concerns or possible drawbacks I was able to think of: * Not sure how to handle multiple cache backends. I imagine if you're someone who has implemented multiple cache backends, then you are using them in specific ways for specific reasons. If your tests end up sharing a test backend, that could result in unpredictable behavior. One possible resolution would be to amend your proposal a bit: For each cache backend defined, we swap it out with the locmem backend unless you have yourself defined a test_CACHE_NAME version of that cache. So e.g. fi I have three backends named "default", "file" and "db", I then need to define test_default, test_file and test_db if I want to specify how the test framework is going to set up the test cache. Otherwise, it'll fall back to replacing it with a locmem cache. * At least when it comes to memcached, this doesn't help you much with the cache.clear() issue, since cache.clear() will blank your entire memcached cache. So if we're calling cache.clear() at the end of each test and it's blanking the whole cache, I start to wonder why we bother at all? In other words, why not just call cache.clear() at the end of every test and call it a day, and make a note in the documentation that running the test will clear any cache you have defined in BACKENDS, so use it with caution. One response is that the same thing is not true for db, file and locmem -- in these cases you'll only be deleting the test cache which was set up for them
Re: Django ORM enchantments
Very nice work Akaariai.
I'll check this out over the next couple of days :)
Cal
On Mon, Jul 4, 2011 at 10:10 PM, akaariai wrote:
> I have implemented proof of concept versions of conditional
> aggregation, F-lookups in aggregates and annotating fields to a model
> (qs.field_annotate(age_x2=F('age')*2), note: no aggregation here). See
> ticket #11305 for more details.
>
> I would also hope to implement a patch which would allow to annotate
> reverse related models. The idea would be most useful for fetching
> translation models.
>
> Given models:
> Article(
> id=IntegerField()
> default_lang=CharField()
> )
> ArticleTranslation(
> article=ForeignKey(Article, related_name='translations')
> name=TextField()
> abstract=TextField()
> content=TextField()
> lang=CharField()
> class Meta:
> unique_together = ('article', 'lang')
> )
>
> And queryset:
> Aricle.objects.annotate(
> translation_def=ModelAnnotation(
> 'translations',
> only=Q(translations__lang=F('default_lang'))
> ),
> translation_fi=ModelAnnotation(
> 'translations',
> only=Q(translations__lang='fi')
> )
> )
>
> The above query would generate something like this:
> select article.id, article.default_lang, t1.name, ..., t3.name
> from article
> left join article_translation t1 on article.id = t1.article_id and
> t1.lang = 'fi'
> left join article_translation t3 on article.id = t3.article_id and
> t3.lang = article.default_lang
>
> And the objects returned would have (possibly None-valued)
> translation_fi and translation_def instances attached to them.
>
> These features require a lot of work before anything commit-quality is
> ready. I would ask if the community would consider these ideas before
> I do too much work. These patches would also require some attention
> from somebody with more ORM knowledge than I have. The ModelAnnotation
> idea is probably too hard for me to implement in even near commit-
> quality.
>
> These features would naturally make the ORM more powerful, but I see
> some objections to these features:
> 1. They will make the already complex ORM even more complex. This
> will result in new bugs and it will be harder to add new features to
> the ORM.
> 2. Django ORM has the philosophy of "80/20". Meaning that the ORM
> should make it possible to run 80% of your queries, the rest can be
> done using raw SQL. Are these features beyond the 80% threshold?
> 3. As the queries become more complex, it is likely that the ORM will
> not be able to generate efficient SQL. If this is the case raw SQL is
> needed. Back to square 1.
> 4. The ORM is nearing the point where the API is too complex. Instead
> of writing complicated SQL, you will be writing complicate ORM
> queries.
>
> On the other hand, combined with custom F() expressions, the need
> for .extra() would be smaller and maybe it could even be deprecated in
> the future.
>
> - 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.
>
>
--
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: [GSoC form-rendering] Weekly Check-in
Hi Gregor, I've just put up a new version of django-forms [1] which implements a similar version of the proposal with the main difference being "extends". Take a look. 1. https://github.com/SmileyChris/django-forms -- 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/-/YgJhiTAVUlEJ. 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: Named tuples queryset
> Named tuples eliminate neediness in values & values_list because they > have all their features. Not in your implementation. The order of fields in each tuple corresponds to order in sql but not to order of fields in namedtuples() call. See ValuesListQueryset.iterator() implementation for details -- 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.
