On 15 Feb, 12:30, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > When Adrian > proposed that API, he realised that almost always you're going to be > pulling back all of the fields or almost all of them. Once a database > has read a row to access some of the data, accessing all of the data in > the row is close to zero overhead. It's already had to read the block > off disk, for example, which is many kilobytes in size. Only for either > extremely large fields or for fields that need a large amount of > post-processing to be useful (such as polygon fields) is it really a win > to micro-manage what is pulled that. > > For most non-trivial SQL queries with modern databases, constructing > (extracting) the output columns, unless they are complex computations, > is a very small fraction of the timeslice devote to the query execution.
It's true but not all true. Often it's have sense to exclude even small non-used fields, because when you do joins with GROUP BY or similar for final 100 rows you may have temporary in-memory or even disc-table from 100*100 rows and size of each rows really matters. Then not only db-stage consume resources, but also network bandwidth is consumed, python database adapter consumes a lot on converting raw char stream to never used python objects, memory is wasted. It's extremely important on limited VPS-hostings. However, IMHO such technical details isn't important because ORM should not assume that things are "good enough". With ideal ORM I should be able to do _all_ that I can do with raw SQL. Everyone needs are special, same ORM will be good for small project but unacceptable for big project if ORM assumes that "this" and "those" limitations are acceptable for all. >> That's why the API is to specify what to exclude, rather than what to > include. I tend to agree with the proposal, too. From a performance > management perspective, it's going to be easier to use that way. I agree that in many cases exclude() may be useful and probably it's worth to add it also, but as I already wrote in my blog post, this patch come from real experience when you don't have "tutorial-like" models and when there is conscious data redundancy in many tables. It's typical task to show object_list and object_detail for any model and for each object_list I know exactly what fields I need and usually it's 3-5 fields from model itself and 2-3 fields from related models. I strongly believe that API should give me ability to receive only those fields even if all database severs will work with speed of light. > This isn't "standard Django lookup syntax", though. It's some entirely > new lookup syntax you created. There's nowhere in the current lookup > hierarchy that uses this method for referring to fields in another > model. Reusing the existing syntax makes more sense. It's less for > people to learn and it's less restrictive: with the double-underscore > syntax, I can list the fields in any order, since they're all positional > arguments. Your syntax has normal fields as positional arguments (so > they must come first) and related fields as keyword arguments that take > a sequence. I sure you know Django lookup syntax much better than me, but IMHO your proposition violates DRY, because if I need to select several fields from related model I need to repeat and repeat "user__address__fieldname". Your proposition is close to original SQL syntax of SELECT statement and due to this issue your proposition should be accepted probably even if it violates DRY but keeps conceptual integrity with underlaying SQL level. I think it's only several lines task to change syntax from fields(*fields, **related_fields) to fields(*args). So if sometimes core developers change own mind about fields() method I can add to my patch plain lookup syntax support. --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
