Cache invalidating with generic class based views

Dear django developers, I've had to develop a middleware piece for the django website inkscape.org, the website requires page caching for it's django-cms parts, but was suffering horribly from over-caching on non-cms pages. What I want to ask is, is a generic solution to generic class based vie

Re: No access to the login page to the already logged-in user through url

Django 1.10 adds a "redirect_authenticated_user" parameter for the login view which, if I understand correctly, accomplishes what you want. https://docs.djangoproject.com/en/dev/topics/auth/default/#django.contrib.auth.views.login On Friday, April 29, 2016 at 4:40:37 PM UTC-4, rajat vijay wrote:

No access to the login page to the already logged-in user through url

Hey, Thank in advance I think that once the user has logged in he should not be able to access the template having the login form w/o getiing logged out. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. T

Re: Add support for LiveServerTestCase.setUpTestData

Hi, LiveServerTestCase doesn't inherit from django.test.TestCase intentionally, that's why it doesn't call setUpTestData(). If you need that functionality just inherit from both: class MyTestCase(LiveServerTestCase, TestCase): # ... Moritz Am 29.04.2016 um 21:46 schrieb Crono5788: > I am

Add support for LiveServerTestCase.setUpTestData

I am writing test cases and have some helper mixins, and when I try to use some of those mixins in tests that extend LiveServerTestCase, they don't work properly since LiveServerTestCase never calls setUpTestData. Is it possible/practical to get this method supported for LiveServerTestCase? -- Y

Re: unique_together does not work as expected with nullable fields

Hi Rich, > On 29 Apr 2016, at 19:52, Rich Rauenzahn wrote: > > I see now that I need to provide a sentinel value -- BOO=True,VAL=, > or manually create additional unique indexes. Indeed, you should write a migration with a RunSQL operation that creates a unique index on boo where boo = true.

Re: unique_together does not work as expected with nullable fields

On Friday, April 29, 2016 at 2:16:45 AM UTC-7, Anssi Kääriäinen wrote: > > If you really, really want an unique index that allows just a single > value, you might want to try unique index on (a, b, c) where c is not > null, and another unique index on (a, b) where c is null. That might > give

Re: unique_together does not work as expected with nullable fields

On Friday, April 29, 2016 at 12:51:31 AM UTC-7, Florian Apolloner wrote: > > > I am not against a note in the docs, but I find the fact that nulls are > not "unique" and can exist in an index more than once very useful (fwiw > ordering after a column with null can also be interesting across >

Good idea to transition from MS Access to local webapp built on Django?

Hi, I work for a very small company that I developed an application for, all using MS Access (it has back-end MS Access db - although this is planned to change to some more robust RDBMS, and a front-end app built in MS Access). Currently this app is used to calculate the exact wages of some emp

Re: is_authenticated as property

Well, actually, there is a problem with the check approach: People use proxy models with user models, to account for different types of users; and it could be that the actual class is decided before the user is authenticated (because of different entry URLs, different authentication backends, wh

Re: unique_together does not work as expected with nullable fields

If you really, really want an unique index that allows just a single value, you might want to try unique index on (a, b, c) where c is not null, and another unique index on (a, b) where c is null. That might give the results you are looking for, though I haven't tested this. SQL's nulls are weird,

Re: Change executed raw mysql queries to return timezone aware datetimes.

I'm mildly in favor of b), seems like most projects would want that anyways. If there is a really easy way for picking tz conversions per cursor, then that could be a good approach, too. Something like cursor = connection.cursor(convert_tz=True) might work. I know then MySQL would have a bit diffe

Re: unique_together does not work as expected with nullable fields

Hello, In SQL, defining a unique index on a nullable column will only enforce unicity of non-null values. This behavior seems more useful than allowing exactly one null value. Your example adds two more columns to the index. Other than that, it’s the exact same situation. In my opinion, the c

Re: unique_together does not work as expected with nullable fields

Hi, On Thursday, April 28, 2016 at 11:59:22 PM UTC+2, Rich Rauenzahn wrote: > > This is apparently an expected (and standardized) thing in SQL that ('A', > 'B', NULL) is unique to ('A', 'B', NULL) as NULL is never equal to another > NULL. > Yes, though the standard goes even further: every comp

Re: Change executed raw mysql queries to return timezone aware datetimes.

Hello Bryce, Oops! I didn’t realize that conversions were a parameter of the database connection on MySQL :-( So, yes, it is technically possible to implement the solution you’re describing. However I’m not positive that we should make this change. There’s an argument to be made that database