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 complicates deployment scripts. Should we add something like ./manage migrate --all ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b31bfba0-4d8c-4e23-9834-7186a75ee37c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
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 with contrib and third- party modules without their modification or monkey patching. Also, it conflicts with other custom Managers and QuerySets. 2. Monkey patching Django ORM (johnny-cache, cacheops). Probably simplest to use, not so simple to maintain. 3. Model subclass with ModelBase metasubclass (orm-cache). Has same problems as 1 and more. The situation now as with using external templates prior to django 1.2. -- 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.
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 take a look of #17025 (sql/ > WhereNode refactoring). In summary: test suite is 10% faster, creating > a simple objects.filter(pk=1) query is 30% faster, chained .filter() > calls can be multiple times faster and so on. The code is IMHO > cleaner. And it is much better documented. The patch is WIP, but > please try it on real world queries (especially if you have problems > with queryset cloning) and see if it makes any speed difference. And > of course if you can break it. > > Now, for the topic of the post. I have worked quite intensively (some > might say too intensively) around different issues in the ORM for the > last couple of weeks, and my take is that while the code in general > makes mostly sense and it is clear that it had a good design to start > with, it has slowly bitrotted into a situation where it is nearly > impossible to understand it. Case in point, take a look of add_q pre > and post #17025 patch. Can you tell from the pre-version what is done > and why? > > I would like to work on refactoring the ORM. This would be slow work, > one piece at a time, not a total rewrite. I think there is much > potential in the ORM. It needs to be cleaned first, and then we can > get hacking new and awesome features. I know there are other people > interested in this, too. > > For example I have been thinking for some time about something like > F() objects, but which could contain arbitrary SQL and references to > fields in the query. relabel_aliases and cloning would be handled for > you. These could be used in .order_by(), values_list, annotate() and > so on. SQLSnippet could be its name. This would allow us to > deprecate .extra, and would allow for some really fancy extensions. > > Using these you could implement an external SQL snippets library, the > PostgreSQL window functions in one library for example. Or custom > aggregate ModelAggregate (fetch related models using array_agg, > something like prefetch_related, but runs in single SQL query). I > really do believe this is possible. > > But we need to get the work started on refactoring the ORM first. I do > currently have some extra time, and I am willing to work on the ORM. > But we need some people reviewing the patches and most of all we need > core developers who have enough time to review and commit the ready > patches. Unfortunately the ORM-knowing core developers seem to be > really busy. > > I really do not know how to move forward. I guess I am asking all you > what do you think should be done with the ORM. We could take a > completely opposite direction and make it a wrapper around SQLAlchemy > (I saw this mentioned somewhere some time ago). Or decide that the ORM > is just fine now, or that there are higher importance items. Before > continuing my hacking, it would be nice to know if there is support > for ORM refactoring. > > Thank you for your time, > - Anssi Kääriäinen -- 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.
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 user, who himself doesn't hack into django may use third-party libs that do: migration, automatic caching, any orm, form and template extenders. And for the developers of that libs deprecation is a waste not help, at least what it feels for me. For common user this means he cannot upgrade until all hos libs upgraded or he himself is forced into hacking them. So dropping deprecation could be a strategic win in a sense it will help django infrastructure flourish. At least this is worth considering. -- 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.
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, will make it into a couple of days. The way it is done now still requires that two days but also make me think about separate deprecation concept, about what part of django is public and what is not cause they have separate deprecation policies. It also encourages me to slack at upgrading and use something deprecated for a while longer. On 2 окт, 00:10, Luke Plant wrote: > Hi all, > > The Django deprecation timeline [1] is very inconsistent in its usage of > the terminology 'deprecated'. For example, the 1.5 section often says > "is deprecated" or "has been deprecated", when what they mean is "will > be removed", which is what the other sections generally tend to say. > Some in section 1.6 say a feature "will be deprecated". > > Can we have a consistent policy on this terminology? > > Miriam-Webster: > > "deprecate: to express disapproval of" > > So something is 'deprecated' as soon as we say we are going to remove it > - we are expressing disapproval, but allowing it to continue > temporarily. The confusing thing from Python terminology is that we then > add PendingDeprecationWarning, followed by DeprecationWarning, which > suggest that deprecation is something that will happen in the *future*, > the thing that happens when we finally remove it. But that isn't normal > English usage, and we can't sensibly use 'deprecated' for both the > beginning and the end of the process. > > So I'd suggest that we stick to: > > - deprecated = the first time we say we are going to remove it, > and normally means we add PendingDeprecationWarning > > - removed - when we actually remove. > > In the deprecation timeline, we can simply say "X will be removed", or > "X will be removed in favour of Y". If it is outside the normal > deprecation policy in some way, we can mention that, otherwise no need > to say which version it was deprecated in. In our release notes, we > carry on announcing deprecation as we are doing now. The only problem is > that our 'deprecation timeline' effectively becomes a 'removal > timeline', but I think it will be clear enough if the rest of our > terminology is. > > Comments? > > Luke > > [1]https://docs.djangoproject.com/en/dev/internals/deprecation/ > -- > "It is a truth universally acknowledged, that a single man in > possession of a good fortune, must be in want of a wife." (Jane > Austen) > > Luke Plant ||http://lukeplant.me.uk/ -- 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.
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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 details -- 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.
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 to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Homogenization of User and UserProfile
On 18 мар, 21:22, Carl Meyer 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). > > You can have multiple subclasses of the User model (not that I recommend > subclassing). > > > contrib.auth can be fairly simply adjusted to use custom User model > > from settings instead of always using its own User. > > Yes, it could, but the entire ecosystem of reusable apps with FKs > pointing to contrib.auth.models.User can't. > > > In that sense I am totally for homogenization because it will make > > code cleaner and eliminate unnecessary sql request not because of > > serialization. > > Subclassing doesn't solve the extra SQL request unless the base User > model is turned into an abstract model, which would completely break > third-party FKs. I meaned making User model abstract the same way Tom Evans demonstrated. It can be still used with profiles. > I agree it's ugly, but if it bothers you it's fairly easy to wrap it up > into properties on your profile that proxy to the User model, and then > just always use your profile (you can even add a middleware that creates > a lazy-profile attribute directly on the request, if you want). One should fix problem not hide it. > Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned > they bring almost nothing to the table except for the "there can be only > one" restriction, and I'd be just as happy to see them deprecated at > some point. The only justification I've heard for them is that they > allow reusable code to access the user profile, but I'm not sure what > reusable code is going to usefully do with a custom profile model when > it has no idea what properties it has. > > Just use OneToOneField and the regular ORM access descriptors, and you > can have as many "user profiles" as you need. I always construct single profile model for a project with fields needed by all its apps. That's why I make my reusable apps provide mixins and abstracts of profiles. I think profile model is redundant itself, more of them even worse. It complicates code in many ways, constructing a form for registration and edit profile is a good example. -- 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.
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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
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 homogenization because it will make code cleaner and eliminate unnecessary sql request not because of serialization. Such code is really an eyesore: first_name = user.first_name middle_name = user.get_profile().middle_name last_name = user.last_name > It's kind of hard to talk about "typical" Django app because there are > so many different of them :-). However what's for sure is that > significant share of Django projects consist of many apps. And those app > may store their own profile information related to users. For example > imagine some community site with a forum (an app), news comment system > (another app) and anti-spam plugin (yet another app). A forum keeps > track of users' achievements, comment system knows users' OpenID and > anti-spam have a notion of users' karma. All those things are parts of a > user profile. What do you do in such situation? Create a profile class containing all required fields? And then if you update some app you need to update your composite UserProfile model? One solution could be making each app provide its profile model, abstract model and mixin. So that you can construct whatever you want from this pieces. -- 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.
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 reference to the QuerySet accidentally.* This > was done by keeping a "usage" count both in the inner query instance > and in the outer QuerySet instance. Can you find that patch and post somewhere? If not still thanks for this idea. -- 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.
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 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.
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 code can operate on both. You can easily upgrade/ downgrade your queryset when needed. I know namedtuples come only in python 2.6. We can provide a fallback or just don't support this for older pythons. -- 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.
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 times. Also, I cache db queries issued via ORM, so for cache hit I need to construct queryset but don't need to execute query. > unless you're doing loops with hundreds or thousands of clones, in which case > it can almost certainly be optimized via Q objects. not loops but many ifs. I already use dicts and Q objects (when need complex conditions) but I still have no less than 3 (filter + order_by + slice) clones for each query. Here we see an interesting thing - cloning querysets made me write less beautiful code. > If you really think it will make a significant difference for your app, > you can probably achieve this for yourself by using your own subclass of > QuerySet and overriding the _clone method. Already do this, but it does not cover User model and such. I probably go with some monkey patch for now. > This is not an option. It will break quite a lot of existing code, and > often in highly confusing ways. Not so much code. In most cases cloning is not needed. But it will be confusing breakage, I agree. On other hand for an unbiased person cloning can be confusing too. I wonder how many people were surprised why qs.filter(...) does not filter qs. Ok, if not by default, still we can provide some .mutating() method or .cloning(bool) method which switches queryset into/off mutating mode. Then we can use it in some django code such as Manager.get to avoid useless cloning. -- 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.
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 queryset not clone it.
For example:
Item.objects.filter(category=12).exclude(visible=False).order_by('-
date')[:20]
clones 4 times and 0 is needed. Using Q objects we can reduce it to 3
(still too much) and complicate the code.
Even
Item.objects.get(pk=2)
clones 2 times.
Personally, I would like all querysets mutate not clone by default.
And when one need a clone just make it explicitly.
--
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.
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 subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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=.
