On Apr 22, 2:42 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Yes, it would work. Why is it necessary to introduce the complexity (and > risk of screwing it up), though? We have the default attribute on models > for this type of thing. You're really leaking abstractions here.
I'm not saying we need to have it on INSERTs, I mainly want it for UPDATE :) > Conceptually, Django works with Python models that just happen to be > stored (sometimes) in an SQL database. You are trying to bring the SQL > database more into the foreground here (which is admittedly something > that happens elsewhere too -- not ideal in any of those cases). I'm not > sure that you're solving a problem that needs solving here. Where else could it be solved though? The only other solution I can see is locking the entire row to prevent conflicts, but that can definitely slow things down :) > As an aside, the information about SELECT statements is not really > accurate. In a moderately complex query, filtering the data is a much > larger component of the time budget than reading the results from disk, > regardless of the columns retrieved. One reason for this is that the > database doesn't just read the columns you want from disk. It has to > read in multiples of some contiguous block size (typically 8K or more), > so it will read a large portion of the contents of each row whenever you > access any random selection of data in the row -- ergo reading the data > for a table is relatively constant and working out which rows to > actually read is more important (disk access is sloooowww). You *can* > blow this rule out of the water by using horribly complex computed > columns or trivial constraints, but the first case is rare, particularly > in Django scenarios, and the second case is so fast anyway that the > proportion of the time budget spent on each part is effectively > irrelevant. > > I don't have any similar information for updates, although I suspect > there's going to be similar conditions at play. Particularly because the > Django usage patterns will involve updating only a single row in each > table at a time -- so there aren't any complex constraints used to > filter the rows -- which again falls into the situation where the total > elapsed time is so small as not be worth micro-optimising. Timing the > performance will be necessary. Ok, I stand corrected on that aspect of performance :) -- Collin Grady --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
