Re: using "dictionary with attribute-style access" for newform
How about: def filter_keys(hash, keys): # I'm convinced there must be a better way to write this return dict([ item for item in hash.iteritems() if item[0] in keys ]) def save(self): Blog.objects.create(**filter_keys(self.clean_data, ['name', 'description']) Although I can often omit the filter_keys, it's a fairly common idiom in my code so I have it stashed globally anyways ;) The other one is messier... def set_initial_values_from_attrs(fields, from_object, keys): for key in keys: fields[key].initial = getattr(from_object, key) def __init__(self, blog, *args, **kw): super(MyForm, self).__init__(*args, **kw) set_initial_values_from_attrs(self.fields, blog, ['title']) ... less typing, but also less clear... - Paul def __init__(self, blog, *args, **kwargs): On Mar 7, 1:47 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote: > Hi, > > I have an enhancement request for new forms, instead of doing > > def save(self): > > > Blog.objects.create(title=self.clean_data["title"], description= > > self.clean_data["description"]) > > and > > def __init__(self, blog, *args, **kw): > > > super(MyForm, self).__init__(*args, **kw) > > self.fields["title"].initial = blog.title > > It would be better to use: > > def save(self): > > > Blog.objects.create(title=self.clean_data.title, description= > > self.clean_data.description) > > and > > def __init__(self, blog, *args, **kw): > > > super(MyForm, self).__init__(*args, **kw) > > self.fields.title.initial = blog.title > > Its easier on eyes as well as fingers. > > Please! I love you, I beg you! :-) > > -- > Amit Upadhyay > +91-9820-295-512 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC 2007 - Object-Level Caching
Hello all! Continuing with the string of posts regarding this year's GSoC, I'm pleased to be working on new caching functionality for Django's ORM under the mentorship of Gary Wilson[1]! Big thanks to him and all the people from the community who made this possible. Now I've just got to hold up my end of the bargain ;) An updated version of my original proposal is available on Django's wiki[2] and the project repository is available from Google Project Hosting[3]. This project aims to condense common caching idioms into simple QuerySet methods that deal with cached data intelligently, refill expired cache, track instance modification/deletion, descend through relationships, and so on. I've tried to make it accommodate the most common use cases, be it dumping front-page news articles to cache or keeping user profile data on hand when rendering a more dynamic site, but I'd definitely love to hear about how cached data is really used out in the field. Currently, three QuerySet methods, .cache(), .cache_related(), and .cache_set() handle individual, relation, and aggregate data caching, respectively. Each can take arguments to specify options like expiry time. Signals are registered behind the scenes to sync the cache, and there's also a proposal for transactional caching. Generic relations will also benefit greatly from .cache_related(). More detail is available on the wiki page, but lots of the little issues that surround the implementation are still bouncing around in my head; the page is going to be expanding and mutating throughout the next few months, I'm sure. The timeline is a little underdeveloped, for one. Comments and criticisms are always welcome! The project itself is currently a single module which has a class derived from QuerySet with all of the new functionality, and a little hack to inject the .cache(), etc methods right back into QuerySet. It also ships with a project in which I'll be writing proper tests. Some sort of miniature cache-testing framework may be in order too. Eventually, perhaps it'll become fit for inclusion in the Django proper--but either way it doesn't require a huge amount of core modification. I'm also curious about the progress of QuerySet refactoring, which would understandably have a huge impact on the code I'm writing. Either way, this new code applies directly to a Django project I've been working on for the last while, so I have the motivation to maintain this project wherever it may go! Thanks, Paul Collier [1] http://gdub.wordpress.com/ [2] http://code.djangoproject.com/wiki/ObjectLevelCaching [3] http://code.google.com/p/django-object-level-caching/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GSoC 2007 - Object-Level Caching
> If I update o1 in some other part of the > code, what assumptions are made about qs? Hmm, yeah... I haven't focused enough attention on .cache_set() yet, heheh. I was definitely just going to implement (1) first, and then worry about something more advanced once I got to the "smart" functionality (which I might just be making default behaviour now). At some point I'll be writing a class with which cached queries register so that pre/post_save signals can freshen the cache; that's should lightweight enough to scale by itself, but to implement (3) I guess it'd also have to track which PKs are present. I'm not really sure if (2) is desirable. > What we can do is add a > reliable __hash__ method or something similar to the Query class (the > thing that does the SQL construction) so that instead of you having to > replace QuerySet.iterator() and look at the query as it is constructed, > you can just ask the QuerySet.query attribute what its hash is and use > that to ascertain identity. Sounds great. I was wondering if there was some way to automatically generate cache keys for .cache_set() as well. Perhaps this could tie in quite nicely. Also, the approach I'm taking currently with the overriden QuerySet worries me because I think it only really works right now if .cache*() is the last method on the chain. > The good news/bad news (are you a glass half-full or glass half-empty > kind of guy?) is that the QuerySet refactor is now my major project, as > the unicode branch is winding down and we have to get this sucker done. It sounds good to me! I've had a good experience migrating to new Django features in the past (thank you newforms!) and this sounds like it's definitely the way to go. I'm just wondering now if I should maintain two versions of the project... guess I'll have to see once it rolls around. Thanks for the comments! Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC 2007 Object-level Caching - Update
Hello! (Internet is acting up; I hope this doesn't double-post.) It's been a week since coding started. In the meantime I've been fleshing out the interface for the new QuerySet and incorporating suggestions from last week. I implemented a 'registry' that tracks cached QuerySets and listens for instance modification, a simple hash() for QuerySet to identify which filters are in effect, and reorganized/refactored the way QuerySets are handled. More code is copy-pasted from query.py right now, but I'm happier with the layout now. (All code that overrides old code got moved into a separate file.) The registry doesn't use an optimal algorithm by far; it currently contains a dict that associates primary key values to the set() of cached QuerySets that contain the primary key. The code that sets it all up seems a little bulky and expensive too... but as Malcolm said it should be good for a first try! Some things I'd like to finish this week include the rest of the regular QuerySet methods and then some special cases, figuring out how to test caching behaviour for correctness, and looking further into how multiple instances are handled and when QuerySets become updated. The QuerySet.__hash__ will probably need to be extended some, and I still need to move things out of iterator(). Also I need to update the site/wiki/schedule, check code in more often, and get creative with the tests ;) - Paul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Event based caching
Hello Henrik!
(I think this has to do with what you're trying to accomplish, correct
me if wrong ;) In terms of keeping cache synced with data in models,
this is something I'm trying to address with my GSoC project for the
summer[1]. In fact, the current code already has a mechanism for
tracking model updates and deletes using signals. Basically, if you
call .cache_set("mycachekey") on your existing QuerySet it'll hook up
the appropriate signals and update the cache when relevant model
instances are modified. (It also does the QuerySet lookup using the
cache rather than the database for you.) It's not very mature code
right now, though. More functionality and better implementation coming
shortly...
- Paul
[1] http://code.google.com/p/django-object-level-caching/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
