Migrate all databases

If I have 2 databases in my project like 'default' and 'second'. I wrote database router that models are created for right dbs. But anyway each time I need to call both: ./manage.py migrate ./manage.py migrate --database=second It leads into forgetting one of dbs from time to time and also

Re: Feature request prop for django db cache extention

As one of the authors of multiple third-party packages I can say that though it is not too hard still integrating cache into ORM have some problems. There are several approaches: 1. Custom Manager and QuerySet subclasses (cachebot, cache-machine). The clearest one and lest powerful - can't use

Re: ORM refactoring

I use a bunch of hacks and monkey patches to make ORM master. So I consider a proper cleanup very valuable. This one for example for more efficient pickling: https://gist.github.com/974735 On 10 окт, 03:28, Anssi Kääriäinen wrote: > First, if you have time for it, please

Re: deprecation vs removal

> It allows you the luxury of taking the time, > and encourages you to upgrade even if you don't have time to make > application changes. It doesn't really saves time for me. But maybe I'm an uncommon case. Some of things I do with django are pretty tied up to its internals. But even a common

Re: deprecation vs removal

For me, as an extensive django user, a whole deprecation thing is somewhat useless and confusing. I'd prefer deprecated elements were just removed. Then when I upgrade django I'll just upgrade it and fix any wrong calls, imports, monkey patches etc. Proper upgrading docs, which you write anyway,

Re: minify static files (css and js)

I prefer webassets. You may also look into. -- 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

Re: Named tuples queryset

> Named tuples eliminate neediness in values & values_list because they > have all their features. Not in your implementation. The order of fields in each tuple corresponds to order in sql but not to order of fields in namedtuples() call. See ValuesListQueryset.iterator() implementation for

Re: Deprecation policy for IE6

IE 7 should be probably dropped with IE6, I can't see point in keeping it -- 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

Re: Homogenization of User and UserProfile

On 18 мар, 21:22, Carl Meyer <c...@oddbird.net> wrote: > On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: > > > I think using subclass of User model for your fields has the same > > flexibility as separate profile model (since you can have only one). > > Yo

Re: QuerySet subclass based on namedtuple()

I implemented it in a gist https://gist.github.com/876324 -- 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

Re: Homogenization of User and UserProfile

I think using subclass of User model for your fields has the same flexibility as separate profile model (since you can have only one). contrib.auth can be fairly simply adjusted to use custom User model from settings instead of always using its own User. In that sense I am totally for

Re: Expensive queryset cloning

> I had a patch for this problem somewhere, but can't find it now. > Basically it added inplace() method to queryset, and after that no > cloning of the inner query class would happen. The outer QuerySet > would still be cloned, but that is relatively cheap. This was to > prevent usage of the old

Re: Expensive queryset cloning

> We haven't yet, but had been planning on exploring a way to mutate the > existing class in most circumstances, but haven't > dug into it too much yet. I have and I use this monkey patch for now: https://gist.github.com/872145 -- You received this message because you are subscribed to the

QuerySet subclass based on namedtuple()

It would be nice to have a QuerySet subclass based on namedtuple(). namedtuples takes less memory than dicts (from ValuesQuerySet), much more convenient and induce more readable code than tuples (ValuesListQuerySet). Namedtuples use same dot notation as model instances. So the same simple enough

Re: Expensive queryset cloning

> I'd be surprised if the cloning of querysets is actually a > significant bottleneck relative to the database query itself I was too. Query via ORM is 2-4 times slower for me than just database query + network roundtrip. It is not only due queryset cloning, but cloning takes 0.5-1 of that 2-4

Expensive queryset cloning

I was optimizing my django app and ran into this. My app was spending too much time cloning querysets. I looked into code but didn't find any simple way to make it faster. But this is not needed actually. In most use cases "a parent" of a clone is thrown out. So usually one just need to mutate

Re: Design decision on FileField removing abandoned files?

I agree, currently I am deleting old file in view handling form, which does not feel right. I also need to check for upload errors and in case of ImageField if it's a valid image, which feels really wrong since the field is doing it on itself -- You received this message because you are