I will only add new things, and won't break any current API. Why this is needed: You can actually do *database independent* queries with full control. The current API is IMO limited when trying to execute queries with joins. Especially when you want to aggregate data from the joined table. Yes, since django 1.1 you have the aggregate and annote methods, but this doesn't work with generic foreign keys. select_related only works with foreign keys, and doesn't support aggregation.
When you do care about optimizing the number of queries of your website, you'll always need fairly complex joins. Currently the only way to create such join, is the QuerySet.query.join method. A method which is used in a totally other way than the QuerySet API. Didn't know about the same API is used for the app engine, but if the current api works, there must be a way to let this work with it too. Maybe the method names won't really match with what you're really doing, it's up to you guys if that's a real problem or not. Lucas On 19 mrt, 23:01, Taylor Marshall <[email protected]> wrote: > On Fri, Mar 19, 2010 at 11:09 AM, Karen Tracey <[email protected]> wrote: > > However, it does seem to be in direct conflict with the idea of getting to > > the ORM working on non-SQL databases. The additional methods mentioned > > (select, from, leftJoin) together all sound like they are moving the app-ORM > > interface closer to raw SQL rather than away from it. Given the more > > long-standing interest in getting the ORM working with things like app > > engine's BigTable, I can't see a proposal for movement more towards raw SQL > > being accepted. > > I agree with this sentiment. To me, the example API shown here reads > almost just like SQL. There's already a mechanism for writing raw > SQL, and the example provided doesn't seem to be a whole lot simpler. > > Maybe a solution is some extension to django.db.connection that would > let you get back objects with named fields (or maybe just dicts) in > place of plain tuples? You'd get all the flexibility that you want, > but more readable code (accessing field names rather than sequence > indices). > > Taylor -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. 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.
