Per my patches and what I believe Malcom has done with qsrf, the syntax for related fields was field__related__name, and yes, you would repeat this over and over, but it keeps it consistant.
I would like a values-like method to return partial objects, and then requesting any field thats not "filled" would hit the db in some fashion, but that's another story. On Feb 15, 3:42 am, Dima Dogadaylo <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
