Re: Should AdminSite be able to handle different namespace?
On Sun, Nov 10, 2013 at 7:47 PM, Florian Apolloner wrote: > Hi Russ, > > > On Saturday, November 9, 2013 11:34:53 PM UTC+1, Russell Keith-Magee wrote: >> >> I'm a little concerned about this talk about deprecation here -- the >> app_name exists for a reason, and at time the app_name feature was added, >> it worked (to the best of my knowledge, anyway). >> > > It most likely did, till we switched the admin to not use hardcoded URLs: > https://github.com/django/django/commit/aaf77c1676e44019abe544911ff7a06eb2690295-- > I have to say that I completely missed app_name there since the tests > didn't seem to cover it and URL namespaces had been kind of a blackbox to > me. That said; we changed this two years ago, so my question is: is this a > feature we want to have? Also I'd appreciate if you can come up with a few > ideas of how to fix it and probably explain the rationale for adding it in > the first place so I can understand how this was ment to be used. > The use case was simple -- deploy two instances of admin in a single project. For example, you might have a truly 'access-all-areas' admin, and a cut down/modified admin for trusted editors that has specially customised workflows, etc. Admin has been specifically designed to allow this, and it's a documented feature [1]. [1] https://docs.djangoproject.com/en/1.0/ref/contrib/admin/#multiple-admin-sites-in-the-same-urlconf Is this a feature we want? Well, I've never used it myself; and the fact that nobody has complained until now suggests that it's not especially well used. On the broader conceptual point, I see value in being able to isolate deployments of a block of URLs… but again, I can't say this is something I'm using. As for how to fix it -- that's a bigger question. It's been a while since I spelunked in that particular code, so I'd need to go digging to offer an opinion. Russ %- ) -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CAJxq84-c0QAy2nrrJT9okUSjAzPDwzhS2yEc3SVasU2jc2870w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: New suggestion: ignoring certain fields on INSERTs and UPDATEs
On Tue, Nov 12, 2013 at 4:20 PM, Apostolos Bessas wrote: > Hello, > > I would like to ask, whether the following feature should/could be > part of Django. > > There are cases that you would the database to handle certain fields. > For instance, > > - set fields to their default value in the dabase-level (such as a > `created` timestamp), > - have the value of fields computed always by the database (e.g. with > a trigger), > - have virtual fields in the database etc. > > The first case is especially important for timestamps, since setting > the default to `NOW()` will make sure (at least in postgres) that all > rows inserted under the same transaction will have the same timestamp > (compared to how auto_now_add works). This means that, when you insert > a lot of objects in one transaction, they will all have the exact same > timestamp. Moreover, relying on the database for setting default > values to fields reduces the amount of data that need to be sent to > the database server. > > The second and third case allow to move some of the logic to the > database and take advantage of some features they offer as well as > speed up some things. > > I understand there are alternatives at python-level, but I am not sure > how well they would work for high-traffic sites etc, without resorting > to raw queries for certain operations. > > In order to achieve this (without resorting to hacks, like ignoring > the values that django sends in the database), django should ignore > these fields, when constructing an INSERT or UPDATE query. This could > be done by allowing a field to tell django to ignore it on INSERT or > UPDATE queries, the same way it does now for AutoFields. > > You can find an implementation of this approach at > > https://github.com/mpessas/django/commit/a663d8f95d9cca5112ccd33e3a303cae82908b60 > and a demo project at https://github.com/mpessas/dbfield (timestamp > app). > > So, does this sound like something that should be in core django? If > so, should I create a ticket in trac? Can anyone think of a better way > to achieve the same effect? > Broadly speaking, it sounds interesting, and is at least worth a ticket in Trac. I don't have a whole lot of use for this myself, but I can see how others might. Regarding the specific implementation you've provided -- I don't see why use_on_update/insert need to be class variables, instead of instance variables like all the other field configuration flags. This would have the benefit that you don't need to subclass every field that you want to be INSERT-ignored; you just need to pass in CharField(max_length=100, use_on_insert=False). As for other ways to the same effect -- the only alternative I can think of would be to treat this as a model-level property, effectively a default value for save(update_fields). This would be the approach to use as a ghetto implementation without requiring any modifications to Django itself (you just need to provide a save() implementation that removes the fields you want, based on whether pk is set), but as a solution for core, I think a field configuration argument is the better approach. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CAJxq848QVnvU6ce%2B4zZZtLA2agsgDQRbr7e70HFyUN9gbWOJ3Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Should we care about performance in not-so-updated Python3 (Python 3.2)?
On Wed, Nov 13, 2013 at 12:31 AM, Vajrasky Kok wrote: > Greetings, friends! > > We just added lru_cache in Django. > https://github.com/django/django/commit/9b7455e918a437c3db91e88dcbf6d9c93fef96f8 > > As you can see in django/utils/lru_cache.py, if Python is not shipped > with lru_cache (Python 3.1 for example), we provide lru_cache for them. > This lru_cache is just a backport from Python 3.3 lru_cache. > http://code.activestate.com/recipes/578078-py26-and-py30-backport-of-python-33s-lru-cache/ > > The problem happens if we use Python 3.2. Python 3.2 comes with lru_cache > which is inferior from our lru_cache. > http://hg.python.org/releasing/3.2.4/file/7680dbf5cb3f/Lib/functools.py. > Should we detect this corner case so if user uses Python 3.2, we overshadow > their "inferior" lru_cache? > > According to Raymond Hettinger (Python core developer) who wrote lru_cache: > > "The Python 3.3 version was also refactored, beautified, and optimized. It > consumes less memory than the 3.2 version. It makes half as many hash > calls." > > In my opinion, we should just use "inferior" version of lru_cache in > Python 3.2 I bet the difference would be unnoticeable. But I am just > curious what Django developers think about this. > Hi Vajrasky, As a library, Django is at the start of the Python 3 transition. Python 3.3 was released *before* Django 1.5 - the first release of Django that officially supported Python 3. Most Django users moving to Python 3 will be adopting Python 3.3, not earlier releases. Therefore the set of people we're talking about here is small to start with. In order to do what you're proposing, we're going to need a complex mechanism to implement this -- Ok, not unbelievably complex, but certainly more complex than the current implementation of "if it doesn't exist, you can get it here". And, at some point in the not too distant future, we're going to drop support for Python 3.2. So - we've got a moderately complex implementation, which will be used by a very small audience, which won't be needed in the near(ish) future. You're completely correct that there would be a performance boost for people using Python 3.2 if we overrode lru_cache. However, unless that performance boost is significant (by which I mean making the difference between Python 3.2 being a viable platform for deployment, not just a 2% performance bump) I'm just not sure it's worth the effort to build and maintain the feature for the set of people that need/want it. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CAJxq84-f%3DwT3TMqYFFgrqRQQoR6%3Dm0LNOSg%2B_xoaRY%2BWfg1gww%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to livereload Django templates?
Hi Nikolay, this mailing lists is about the development of Django itself; you might wanna ask that on django-users Regards, Florian On Monday, November 11, 2013 5:45:42 PM UTC+1, Nikolay Georgiev wrote: > > Do you know some tips or concrete steps on how to livereload Django > templates? > > Livereloading means that if I change the HTML Template, CSS or JS files > that these files will be automatically reloaded in the browser, without me > having to refresh the page manually. This leads to increased productivity. > http://livereload.com/ > > Thank you very much! > > Nikolay > -- You received this message because you are subscribed to the Google Groups "Django developers" 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/3695135a-fc8e-4e5b-9d64-9053715b5e9b%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Should we care about performance in not-so-updated Python3 (Python 3.2)?
Greetings, friends! We just added lru_cache in Django. https://github.com/django/django/commit/9b7455e918a437c3db91e88dcbf6d9c93fef96f8 As you can see in django/utils/lru_cache.py, if Python is not shipped with lru_cache (Python 3.1 for example), we provide lru_cache for them. This lru_cache is just a backport from Python 3.3 lru_cache. http://code.activestate.com/recipes/578078-py26-and-py30-backport-of-python-33s-lru-cache/ The problem happens if we use Python 3.2. Python 3.2 comes with lru_cache which is inferior from our lru_cache. http://hg.python.org/releasing/3.2.4/file/7680dbf5cb3f/Lib/functools.py. Should we detect this corner case so if user uses Python 3.2, we overshadow their "inferior" lru_cache? According to Raymond Hettinger (Python core developer) who wrote lru_cache: "The Python 3.3 version was also refactored, beautified, and optimized. It consumes less memory than the 3.2 version. It makes half as many hash calls." In my opinion, we should just use "inferior" version of lru_cache in Python 3.2 I bet the difference would be unnoticeable. But I am just curious what Django developers think about this. Cheers, Vajrasky -- You received this message because you are subscribed to the Google Groups "Django developers" 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/ca33baf4-6ca1-4abf-a058-d993b3dd1271%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
New suggestion: ignoring certain fields on INSERTs and UPDATEs
Hello, I would like to ask, whether the following feature should/could be part of Django. There are cases that you would the database to handle certain fields. For instance, - set fields to their default value in the dabase-level (such as a `created` timestamp), - have the value of fields computed always by the database (e.g. with a trigger), - have virtual fields in the database etc. The first case is especially important for timestamps, since setting the default to `NOW()` will make sure (at least in postgres) that all rows inserted under the same transaction will have the same timestamp (compared to how auto_now_add works). This means that, when you insert a lot of objects in one transaction, they will all have the exact same timestamp. Moreover, relying on the database for setting default values to fields reduces the amount of data that need to be sent to the database server. The second and third case allow to move some of the logic to the database and take advantage of some features they offer as well as speed up some things. I understand there are alternatives at python-level, but I am not sure how well they would work for high-traffic sites etc, without resorting to raw queries for certain operations. In order to achieve this (without resorting to hacks, like ignoring the values that django sends in the database), django should ignore these fields, when constructing an INSERT or UPDATE query. This could be done by allowing a field to tell django to ignore it on INSERT or UPDATE queries, the same way it does now for AutoFields. You can find an implementation of this approach at https://github.com/mpessas/django/commit/a663d8f95d9cca5112ccd33e3a303cae82908b60 and a demo project at https://github.com/mpessas/dbfield (timestamp app). So, does this sound like something that should be in core django? If so, should I create a ticket in trac? Can anyone think of a better way to achieve the same effect? Regards, Apostolis -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CAEa3b%2BpHoXwcApaOS8CcPUMiYVLG2ocVHR4QQZz2r-%3D9dfHk2Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
How to livereload Django templates?
Do you know some tips or concrete steps on how to livereload Django templates? Livereloading means that if I change the HTML Template, CSS or JS files that these files will be automatically reloaded in the browser, without me having to refresh the page manually. This leads to increased productivity. http://livereload.com/ Thank you very much! Nikolay -- You received this message because you are subscribed to the Google Groups "Django developers" 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/c869800d-8493-4605-960c-52ba03f5d239%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Enable storing NULL in database
Alesandro: Thanks for link, but this does not quite solve the issue. 1. I don't want user to decide how data gets stored in database. That's my (developer) decision. 2. There are other text fields which stores data as text in database - e.g. URLField and even the FileField. Vlastimil Dne sobota, 9. listopadu 2013 10:49:40 UTC+1 Alessandro Pagnin napsal(a): > > I had the same problem to solve, and I made this app to solve the problem > https://github.com/alepane21/django-nullablecharfield. > On the "widget level" it adds to the right of the field a checkbox to > click to set the value to None/NULL. > > On Thursday, November 7, 2013 11:37:47 AM UTC+1, Vlastimil Zíma wrote: >> >> Hi everybody, >> >> I know this was here before, but it is really a problem. We need (I >> literally mean need, not just want) a simple way to store NULL in database >> instead of ''. Using empty string has several serious consequences (in >> databases which distinguishes between NULL and '', which are to my >> knowledge all but oracle). >> >> * You can't make a model with unique optional field. Django admin will >> let you store only one object without the value, because others with >> conflict the unique constraint. >> * It is useless to set NOT NULL constraints on text fields. Because >> Django stores empty string as empty value, database will not complain about >> invalid data and just stores the rubbish. >> >> I don't want to enforce anybody to use only NULL as empty value, I just >> want Django to store NULL in database when I told it to. And I don't mean >> the way of overriding all the form fields as I have to now. >> >> Regards, >> Vlastimil >> > -- You received this message because you are subscribed to the Google Groups "Django developers" 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/8361e71a-bd3b-47cf-8d69-ee31480d196a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
