On Thu, Jan 8, 2009 at 7:12 PM, Malcolm Tredinnick <malc...@pointy-stick.com > wrote:
> > Hopefully this will be confusing enough to prove my point: > > On Thu, 2009-01-08 at 11:24 -0600, Alex Gaynor wrote: > > Ok, I've spent some time working with this, > > 5. Clear now? > > 4. Because it makes it very hard to follow what is going on and is > really sodding annoying. Is your email client broken or something? If > so, get a better tool. > > 3. Why? > > 2. Please stop top-posting all the time. > > 1. This mail demonstrates how hard it is to have to read from bottom to > top and try to work out the context. This is the first line of the > reply. The first line of what I'm replying to refers to stuff way later > in the message you are replying to and completely lacks any context. > Like many others, I have an interest in following what's going on here, > but it's only one thread amongst hundreds of emails I read every day, so > it would be nice if it didn't take a minute to decode what you're > talking about each time. > > Thankyou for your consideration. > > Malcolm > > > > > > Top posting is the default in my mail client(Gmail), it also makes it easier it easier to write, and ultimately it wasn't something I thought about, but whatever. I'll try to restate my previous message in a manner that makes more sense. As I said, the usage of F() across related fields now works correctly. There were several things that had to be overcome to allow this to work. First any value with an as_sql() method on it was getting converted into a QueryWrapper which didn't work since the F() needed to be able to relabel it's aliases. To that effect I also added a hook to allow values with relabel_alises methods to be called from inside a WhereNode. Finally I ported over the trim_join method Russ abstracted as a part of the aggregation work, there wasn't any changes to it, it's join a note. The actual implementation issue arrise with the usage of F() for related fields in update queries. Specifically one of my concerns was the portability of the SQL. I spoke with Michael Trier this afternoon and it appears to me that the SQL is almost totally non portable. Postgres uses a UPDATE ...SET ...FROM style query. MySQL uses UPDATE [table list ] SET... style query. I'm not sure how SQLite or Oracle do it. I gather that it is possible to do a subquery such a UPDATE table SET field = (SELECT value FROM related_table WHERE "related_table"."id" = "table"."id"); but this is apparently not very performant(has the potential to result in a large number of subqueries in the case of multiple updated fields, in addition to where clauses, etc.). Therefore I am not sure how to proceed with the update portion. Hopefully this is more clear than my previous message. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." --Voltaire "The people's good is the highest law."--Cicero --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
