Re: no relationship between session and user model

You are right about my question. Next time I will read carefully the release notes. Thx! четверг, 19 июня 2014 г., 21:34:02 UTC+4 пользователь Aymeric Augustin написал: > > Previous answers explain why the sessions API makes it impossible to > create a FK from Session to User. However, it looks

Re: no relationship between session and user model

On Thu, Jun 19, 2014 at 1:07 PM, Vaal wrote: > This would be useful in a situation when the user changes the password, and > we could remove all the sessions of that user. > For example the user changes the password because he believes that pass has > been compromised. But if the attacker was alr

Re: no relationship between session and user model

Previous answers explain why the sessions API makes it impossible to create a FK from Session to User. However, it looks like this isn't the question you wanted to ask. Your real question seems to be: "how can I invalidate sessions on password change?" Fortunately, Django 1.7 includes a new middle

Re: no relationship between session and user model

Take a look for https://pypi.python.org/pypi/django-user-sessions please. Looks like what you need. --  Alexandr Shurigin From: Shurigin Alexandr alexandr.shuri...@gmail.com Reply: Shurigin Alexandr alexandr.shuri...@gmail.com Date: 20 июня 2014 г. at 0:18:03 To: django-developers@googlegroups.c

Re: no relationship between session and user model

Other storages doesn’t need it. cached_db inherits DbStorage  https://github.com/django/django/blob/master/django/contrib/sessions/backends/cached_db.py#L17 and of course have implemented same clear_expired. signed_cookies uses cookie expiring i think (not checked). and cache storages uses cach

Re: no relationship between session and user model

> > This relation is not possible out of the box if we want to have highly > customizable framework :) But backends already have differences. For example: only two implemented a method clear_expired https://github.com/django/django/blob/master/django/contrib/sessions/backends/file.py#L190 https

Re: django-firebird backend: migrations and NULL fields

Thanks Tim. I sometimes just forget to run the backport script... Andrew On Thu, Jun 19, 2014 at 8:04 AM, Tim Graham wrote: > Backported in 30d8b95139a1fa3070f3b112115e624ffcf8e555, thanks for the > reminder. > > > On Thursday, June 19, 2014 9:36:54 AM UTC-4, Maximiliano Robaina wrote: >> >> >

Re: no relationship between session and user model

Interesting question. Really django provides few sessions backends by default and only 2 of them store any session info in database (db, cached_db). All other backends save session info in various cache storages like memcache, redis, files, local cache, etc. Right now sessions built as a part of

no relationship between session and user model

Hello! There is a reason why in the framework (by default), there is no connection between the models user and session? I mean ForeignKey(to User) in Session model for example. This would be useful in a situation when the user changes the password, and we could remove all the sessions of that us

Re: django-firebird backend: migrations and NULL fields

Backported in 30d8b95139a1fa3070f3b112115e624ffcf8e555, thanks for the reminder. On Thursday, June 19, 2014 9:36:54 AM UTC-4, Maximiliano Robaina wrote: > > > El martes, 20 de mayo de 2014 09:27:48 UTC-3, Andrew Godwin escribió: >> >> Yes, I'm aware add_field is also in need of expansion points -

Re: django-firebird backend: migrations and NULL fields

El martes, 20 de mayo de 2014 09:27:48 UTC-3, Andrew Godwin escribió: > > Yes, I'm aware add_field is also in need of expansion points - the same > issue was raised with the MSSQL backend too. > > I'm more than happy to add these in now or after 1.7 in a point release; > the actual implementatio

Re: Building a library of SQL functions into Django

Nope that's completely fine. I copied that example from the tests earlier on which interpolates connection.vendor into a string. If you know which backend you're modifying (and you should) then Func.as_vendor = .. Would be preferred. > On 19 Jun 2014, at 21:04, Shai Berger wrote: > > Hi, > >

Re: Building a library of SQL functions into Django

Hi, A minor style point: On Thursday 19 June 2014 02:56:10 Josh Smeaton wrote: > > class Lower(Func): > function = 'LOWER' > >[...] > > def mongo_lower(self, compiler, connection): > self.function = '$toLower' > return self.as_sql(compiler, connection) > > setattr(Lower, 'as_mongo

Stack Overflow Open Source Advertising, 2H 2014

Hi I would like to propose that Django participates in the Stack Overflow Open Source Advertising for the second semester of 2014

Re: Building a library of SQL functions into Django

On Thu, 2014-06-19 at 02:56 +0300, Josh Smeaton wrote: > > Lower.register('mongo', mongo_lower) # register would > internally just call the setattr() above > > > I think this process is pretty good. Everyone gets to use the default > implementation for free (function s