date:20140619

Re: no relationship between session and user model

2014-06-19 Thread Vladimir Ulupov (Vaal)

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 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 middleware for this purpose.
>
>
> https://docs.djangoproject.com/en/dev/ref/middleware/#django.contrib.auth.middleware.SessionAuthenticationMiddleware
>
> -- 
> Aymeric.
>

-- 
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/c4fbf21e-852f-4dca-b3e8-b2e7df225a2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: no relationship between session and user model

2014-06-19 Thread Aymeric Augustin

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 middleware for this purpose.

https://docs.djangoproject.com/en/dev/ref/middleware/#django.contrib.auth.middleware.SessionAuthenticationMiddleware

-- 
Aymeric.

-- 
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/CANE-7mVa7W2vTrPkoLbmWonVjvg8%2BvV_PGZtgqG7x47ta%2B7fpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: no relationship between session and user model

2014-06-19 Thread Alexandr Shurigin

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.com django-developers@googlegroups.com,
(Vaal) Vladimir Ulupov vaal...@gmail.com
Cc: vaal...@gmail.com vaal...@gmail.com
Subject: 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 caching expiring features.

I think dependency of user_id must not be in core, not all storages can
implement api (find all sessions of user for example) for this feature simple
(file based sessions for example. You will need to process all sessions or use
some type of meta file with dependencies). This is application level feature,
not framework. I think you can simple implement your session database backend
with this feature (don’t forget on user login/logout change user_id) included
and share for community if nobody did it already :)

--
Alexandr Shurigin

From: Ulupov (Vaal) Vladimir vaal...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 20 июня 2014 г. at 0:06:45
To: django-developers@googlegroups.com django-developers@googlegroups.com
Cc: vaal...@gmail.com vaal...@gmail.com
Subject: 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://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L81

How such a relationship may limit customizable? btw it's maybe as option...

четверг, 19 июня 2014 г., 20:40:14 UTC+4 пользователь Alexandr Shurigin написал:
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 http
protocol only, not user level.

This relation is not possible out of the box if we want to have highly
customizable framework :)

Don’t worry, my english is ugly too ;)

--
Alexandr Shurigin

From: Vaal vaa...@gmail.com
Reply: django-d...@googlegroups.com django-d...@googlegroups.com
Date: 19 июня 2014 г. at 23:36:28
To: django-d...@googlegroups.com django-d...@googlegroups.com
Subject: 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 user.
For example the user changes the password because he believes that pass has
been compromised. But if the attacker was already has active session - it will
not be interrupted.

p.s. sorry for my English
p.p.s. I understand that can modify the application sessions for their needs
and make a new application or to find a ready-made.
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/8ac582df-e1f1-4619-863c-134cadefc405%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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/848d8356-2614-4fc3-a20e-18b69786fda4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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

Re: no relationship between session and user model

2014-06-19 Thread Alexandr Shurigin

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 caching expiring features.

--
Alexandr Shurigin

How such a relationship may limit customizable? btw it's maybe as option...

This relation is not possible out of the box if we want to have highly
customizable framework :)

Don’t worry, my english is ugly too ;)

--
Alexandr Shurigin

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.

--
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/etPan.53a31b45.836c40e.15a%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

Re: no relationship between session and user model

2014-06-19 Thread Vladimir Ulupov (Vaal)


>
> 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://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L81

How such a relationship may limit customizable? btw it's maybe as option...



четверг, 19 июня 2014 г., 20:40:14 UTC+4 пользователь Alexandr Shurigin 
написал:
>
> 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 http protocol only, not user level.
>
> This relation is not possible out of the box if we want to have highly 
> customizable framework :)
>
> Don’t worry, my english is ugly too ;)
>
> -- 
> Alexandr Shurigin
>
> From: Vaal vaa...@gmail.com 
> Reply: django-d...@googlegroups.com  
> django-d...@googlegroups.com 
> Date: 19 июня 2014 г. at 23:36:28
> To: django-d...@googlegroups.com  
> django-d...@googlegroups.com 
> Subject:  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 user.
> For example the user changes the password because he believes that pass 
> has been compromised. But if the attacker was already has active session - 
> it will not be interrupted.
>
> p.s. sorry for my English
> p.p.s. I understand that can modify the application sessions for their 
> needs and make a new application or to find a ready-made.
>  --
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@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/8ac582df-e1f1-4619-863c-134cadefc405%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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/848d8356-2614-4fc3-a20e-18b69786fda4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird backend: migrations and NULL fields

2014-06-19 Thread Andrew Godwin

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:
>>
>>
>> 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 implementation of those methods is private so we can change it
>>> around a little (or at least, we can add to the available overrides; I
>>> wouldn't go removing those things on backend implementers like yourself).
>>>
>>> I've also added the implied_column_null database feature in this commit:
>>> https://github.com/django/django/commit/1b07781292c2cef9367b521dc0f2b4
>>> 0f4d363083
>>>
>>> Just set it to True and you should get the behaviour you need.
>>>
>>> Andrew
>>>
>>
>>
>> Hi Andrew,
>>
>> Are you going to backport this to version 1.7?
>>
>>
>>
>>
>>>
>>>
>>> On Fri, May 16, 2014 at 10:00 PM, Maximiliano Robaina <
>>> maxir...@gmail.com> wrote:
>>>


 El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió:

> Let's go with a feature for this then.
>
> Maxi, did you want to submit a patch, or do you want me to add it at
> some point next week!
>
> Andrew
>

 I'll appreciate if you can add it.
 BTW, are there other areas that need some work, for instance, add_field
 method [1], if I try to delete a default value on a column that does not
 have a previous default value definition I get an error on firebird, for
 which reason, I need to check if that field has got defined a default value
 before.
 Then I need to rewrite add_field method too.
 I think, for not to delay django 1.7 release, I'll do some workaround
 and I'll try to send you a pull request or a patch with some proposal 
 later.

 [1] https://github.com/django/django/blob/master/django/db/
 backends/schema.py#L401


 Best regards.


>
>
> On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin  polytechnique.org> wrote:
>
>> For what it’s worth, I recently added a feature to add “FROM DUAL”
>> where Oracle needs it.
>>
>> This looks roughly similar. Maybe we could use the same approach. (I
>> didn’t look closely.)
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 14 mai 2014, at 17:06, Andrew Godwin  wrote:
>>
>> Hmm, I'm not sure about adding more features, but it might be
>> cleaner...
>>
>> Andrew
>>
>>
>> On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck 
>> wrote:
>>
>>> How about adding a flag to Operations? implied_null, perhaps.
>>> On May 14, 2014 7:52 AM, "Andrew Godwin" 
>>> wrote:
>>>
 Hi,

 That's currently the only approach I'm afraid - there's an open
 issue (raised by Shai Berger I believe) that column_sql should be 
 broken
 down into more component pieces so it can be more easily changed, but
 that's a difficult task to do and not something I want to go and change
 completely as we're trying to release 1.7.

 What we could do is change those NULL and NOT NULL strings to be
 defined on the schema editor class itself, and then you could set
 sql_null_suffix = "" or similar - do you think that would be a 
 reasonable
 approach?

 Andrew


 On Wed, May 14, 2014 at 7:05 AM, maxi  wrote:

> Hi,
>
> I'm trying to implement the new schema migration of django 1.7 for
> django-firebird backend.
> In column_sql method, when the field can be null, in firebird, is
> not necessary add the NULL keyword. So to change this behavior I need
> override the entire column_sql method just to change one line:
>
>
> if null:
> sql += " NULL"<-- Here
> else:
> sql += " NOT NULL"
>
> I just need:
> if not null:
> sql += " NOT NULL"
>
>
> Is the correct approach rewrite the column_sql method? Are there
> other approach?
>
> Regards.
>
> --
> 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-develop...@googlegroups.com.
>

Re: no relationship between session and user model

2014-06-19 Thread Alexandr Shurigin

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 http
protocol only, not user level.

This relation is not possible out of the box if we want to have highly
customizable framework :)

Don’t worry, my english is ugly too ;)

--
Alexandr Shurigin

From: Vaal vaal...@gmail.com
Reply: django-developers@googlegroups.com django-developers@googlegroups.com
Date: 19 июня 2014 г. at 23:36:28
To: django-developers@googlegroups.com django-developers@googlegroups.com
Subject: 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.

--
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/etPan.53a31260.4353d0cd.15a%40MacBook-Pro-dude.local.
For more options, visit https://groups.google.com/d/optout.

no relationship between session and user model

2014-06-19 Thread Vaal

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 user.
For example the user changes the password because he believes that pass has 
been compromised. But if the attacker was already has active session - it 
will not be interrupted.

p.s. sorry for my English
p.p.s. I understand that can modify the application sessions for their 
needs and make a new application or to find a ready-made.

-- 
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/8ac582df-e1f1-4619-863c-134cadefc405%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird backend: migrations and NULL fields

2014-06-19 Thread Tim Graham

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 - 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 implementation of those methods is private so we can change it 
>> around a little (or at least, we can add to the available overrides; I 
>> wouldn't go removing those things on backend implementers like yourself).
>>
>> I've also added the implied_column_null database feature in this commit: 
>> https://github.com/django/django/commit/1b07781292c2cef9367b521dc0f2b40f4d363083
>>
>> Just set it to True and you should get the behaviour you need.
>>
>> Andrew
>>
>
>
> Hi Andrew,
>
> Are you going to backport this to version 1.7?
>
>
>  
>
>>
>>
>> On Fri, May 16, 2014 at 10:00 PM, Maximiliano Robaina > > wrote:
>>
>>>
>>>
>>> El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió:
>>>
 Let's go with a feature for this then. 

 Maxi, did you want to submit a patch, or do you want me to add it at 
 some point next week!

 Andrew

>>>
>>> I'll appreciate if you can add it.
>>> BTW, are there other areas that need some work, for instance, add_field 
>>> method [1], if I try to delete a default value on a column that does not 
>>> have a previous default value definition I get an error on firebird, for 
>>> which reason, I need to check if that field has got defined a default value 
>>> before.
>>> Then I need to rewrite add_field method too.
>>> I think, for not to delay django 1.7 release, I'll do some workaround 
>>> and I'll try to send you a pull request or a patch with some proposal later.
>>>  
>>> [1] 
>>> https://github.com/django/django/blob/master/django/db/backends/schema.py#L401
>>>
>>>
>>> Best regards.
>>>  
>>>


 On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin  wrote:

> For what it’s worth, I recently added a feature to add “FROM DUAL” 
> where Oracle needs it.
>
> This looks roughly similar. Maybe we could use the same approach. (I 
> didn’t look closely.)
>
> -- 
> Aymeric.
>
>
>  
> On 14 mai 2014, at 17:06, Andrew Godwin  wrote:
>
> Hmm, I'm not sure about adding more features, but it might be 
> cleaner...
>
> Andrew
>
>
> On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck  
> wrote:
>
>> How about adding a flag to Operations? implied_null, perhaps.
>> On May 14, 2014 7:52 AM, "Andrew Godwin"  wrote:
>>
>>> Hi,
>>>
>>> That's currently the only approach I'm afraid - there's an open 
>>> issue (raised by Shai Berger I believe) that column_sql should be 
>>> broken 
>>> down into more component pieces so it can be more easily changed, but 
>>> that's a difficult task to do and not something I want to go and change 
>>> completely as we're trying to release 1.7.
>>>
>>> What we could do is change those NULL and NOT NULL strings to be 
>>> defined on the schema editor class itself, and then you could set 
>>> sql_null_suffix = "" or similar - do you think that would be a 
>>> reasonable 
>>> approach?
>>>
>>> Andrew
>>>
>>>
>>> On Wed, May 14, 2014 at 7:05 AM, maxi  wrote:
>>>
 Hi,

 I'm trying to implement the new schema migration of django 1.7 for 
 django-firebird backend.
 In column_sql method, when the field can be null, in firebird, is 
 not necessary add the NULL keyword. So to change this behavior I need 
 override the entire column_sql method just to change one line:
  

 if null:
 sql += " NULL"<-- Here
 else:
 sql += " NOT NULL"

 I just need:
 if not null:
 sql += " NOT NULL"


 Is the correct approach rewrite the column_sql method? Are there 
 other approach?

 Regards.

 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/

Re: django-firebird backend: migrations and NULL fields

2014-06-19 Thread Maximiliano Robaina


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 implementation of those methods is private so we can change it 
> around a little (or at least, we can add to the available overrides; I 
> wouldn't go removing those things on backend implementers like yourself).
>
> I've also added the implied_column_null database feature in this commit: 
> https://github.com/django/django/commit/1b07781292c2cef9367b521dc0f2b40f4d363083
>
> Just set it to True and you should get the behaviour you need.
>
> Andrew
>


Hi Andrew,

Are you going to backport this to version 1.7?


 

>
>
> On Fri, May 16, 2014 at 10:00 PM, Maximiliano Robaina  > wrote:
>
>>
>>
>> El viernes, 16 de mayo de 2014 09:49:15 UTC-3, Andrew Godwin escribió:
>>
>>> Let's go with a feature for this then. 
>>>
>>> Maxi, did you want to submit a patch, or do you want me to add it at 
>>> some point next week!
>>>
>>> Andrew
>>>
>>
>> I'll appreciate if you can add it.
>> BTW, are there other areas that need some work, for instance, add_field 
>> method [1], if I try to delete a default value on a column that does not 
>> have a previous default value definition I get an error on firebird, for 
>> which reason, I need to check if that field has got defined a default value 
>> before.
>> Then I need to rewrite add_field method too.
>> I think, for not to delay django 1.7 release, I'll do some workaround and 
>> I'll try to send you a pull request or a patch with some proposal later.
>>  
>> [1] 
>> https://github.com/django/django/blob/master/django/db/backends/schema.py#L401
>>
>>
>> Best regards.
>>  
>>
>>>
>>>
>>> On Wed, May 14, 2014 at 6:27 PM, Aymeric Augustin >> polytechnique.org> wrote:
>>>
 For what it’s worth, I recently added a feature to add “FROM DUAL” 
 where Oracle needs it.

 This looks roughly similar. Maybe we could use the same approach. (I 
 didn’t look closely.)

 -- 
 Aymeric.


  
 On 14 mai 2014, at 17:06, Andrew Godwin  wrote:

 Hmm, I'm not sure about adding more features, but it might be cleaner...

 Andrew


 On Wed, May 14, 2014 at 8:00 AM, Jeremy Dunck  wrote:

> How about adding a flag to Operations? implied_null, perhaps.
> On May 14, 2014 7:52 AM, "Andrew Godwin"  wrote:
>
>> Hi,
>>
>> That's currently the only approach I'm afraid - there's an open issue 
>> (raised by Shai Berger I believe) that column_sql should be broken down 
>> into more component pieces so it can be more easily changed, but that's 
>> a 
>> difficult task to do and not something I want to go and change 
>> completely 
>> as we're trying to release 1.7.
>>
>> What we could do is change those NULL and NOT NULL strings to be 
>> defined on the schema editor class itself, and then you could set 
>> sql_null_suffix = "" or similar - do you think that would be a 
>> reasonable 
>> approach?
>>
>> Andrew
>>
>>
>> On Wed, May 14, 2014 at 7:05 AM, maxi  wrote:
>>
>>> Hi,
>>>
>>> I'm trying to implement the new schema migration of django 1.7 for 
>>> django-firebird backend.
>>> In column_sql method, when the field can be null, in firebird, is 
>>> not necessary add the NULL keyword. So to change this behavior I need 
>>> override the entire column_sql method just to change one line:
>>>  
>>>
>>> if null:
>>> sql += " NULL"<-- Here
>>> else:
>>> sql += " NOT NULL"
>>>
>>> I just need:
>>> if not null:
>>> sql += " NOT NULL"
>>>
>>>
>>> Is the correct approach rewrite the column_sql method? Are there 
>>> other approach?
>>>
>>> Regards.
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/
>>> e9f2-a5bf-4e13-b7c1-0a08abd18a4a%40googlegroups.com 
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

Re: Building a library of SQL functions into Django

2014-06-19 Thread Josh Smeaton

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,
> 
> 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', mongo_lower)
> I would spell this as
> 
> Lower.as_mongo = mongo_lower
> 
> Is there a reason I'm missing not to do so?
> 
> Thanks,
>Shai.
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/HggiPzwkono/unsubscribe.
> To unsubscribe from this group and all its topics, 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/201406191404.32091.shai%40platonix.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/61CA02CC-2444-4B66-9C68-48E9A7FFDBCF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

2014-06-19 Thread Shai Berger

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', mongo_lower)
> 
I would spell this as

Lower.as_mongo = mongo_lower

Is there a reason I'm missing not to do so?

Thanks,
Shai.

-- 
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/201406191404.32091.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Stack Overflow Open Source Advertising, 2H 2014

2014-06-19 Thread Jorge Cardoso Leitão

I would like to propose that Django participates in the Stack Overflow Open
Source Advertising

for
the second semester of 2014

*What it is:*
- is a free advertisement program for promote contributions to open source
projects
- ads are voted by SO users and appear on the SO sidebar.
- the program runs on a semester basis.

*Why it may be important:*
Results of the first semester of 2014
show:
- best ad had ~3000 clicks, avg of ~20 clicks/day
- worse ad had ~500 clicks, avg of ~3 clicks/day

Since the effort is relatively low, I believe it is worth. Even if we
don't receive positive feedback in terms of contributions, IMO
just having an ad on SO already improves Django's visibility.

*1. The product*
Main advantages to contribute to Django that we could explore here:

1.1 it improves your Python
1.2 it gives you experience on a production environment
1.3 [put your own]

*2. Target audience*
Potential audiences:
2.1 people that develop websites in Python (e.g. Django, Pyramid)
2.2 people that use Python but don't know Django
2.3 [put your own]

*3. Ad constraints*
3.1 The message must be to *contribute to project X*, not *project X*.
3.2 The ad must follow Django trademark
policy.
3.3 [put your own]

*4. Concrete proposal*
For this semester, I propose we focus on 1.1, and 2.1: i.e. we assume the
reader knows Python and likes web development, but may be not familiar with
Django.

Focusing on 1.1 and 2.1, 4 days ago I created an ad,
http://i.stack.imgur.com/OgP1X.png, that I retracted yesterday from SO
because it failed to comply with trademark policy, 3.2, as Russell pointed
out
.
The "dj" is the favicon of the Django website.

Russell also pointed out and I agree with him that the style can be
improved. However, before we move to the specifics, I would like to ask if
there are objections against participating in the program, and suggestions
or criticisms to the bullets above.

Also, I have no strong feelings about the focus I'm proposing: feel free to
propose other focus.

Regards,
Jorge

--
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/CAOYPqDCXDqGP936TRmRfjH_ZU%3DnULOANX%2Bh66Bh-MaiTNdyyRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Building a library of SQL functions into Django

2014-06-19 Thread Anssi Kääriäinen

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 signatures and names are generally
> pretty stable across backends), but the option exists to easily extend
> or modify the generated SQL where needed. I think this equally
> supports 3rd party backends and function authors.
> 
> 
> Do you think this is appropriate? Have I missed something fundamental
> above where this process isn't fair to backends or library authors?

This is pretty much how I intended this to work. There are two downsides
with this approach:
  1) We don't have .register() method. If we go with this plan we might
still be able to add .register() to 1.7 (it is a trivial classmethod).
  2) The as_vendor() method will need to do a bit more, and know a bit
more about the expression than is strictly needed. The backend approach
would be:
def as_sql(self, compiler, connection):
lhs_sql, lhs_params = compiler.compile(self.lhs)
rhs_sql, rhs_params = compiler.compile(self.rhs)
return connection.less_than_sql(lhs_sql, rhs_sql, lhs_params,
rhs_params)
# In mongo backend
def less_than_sql(self, lhs_sql, rhs_sql, lhs_params, rhs_params):
return "%s < %s" % (lhs_sql, rhs_sql), (lhs_params, rhs_params)

The as_vendor approach gives:
def as_mongo(self, compiler, connection):
lhs_sql, lhs_params = compiler.compile(self.lhs)
rhs_sql, rhs_params = compiler.compile(self.rhs)
return "%s < %s" % (lhs_sql, rhs_sql), (lhs_params, rhs_params)

That is, the as_{vendor} methods need to repeat the compile() calls, and
also know how to compile the internal attributes of the LessThan class.

I'm not sure how to design the backend approach in a way that is both
fast, and also allows for default implementation, and custom
implementation if a backend needs it.

As said before the lookups and transforms already use as_{vendor}. I
hope it will work just fine, but it is hard to be sure about this. If we
add the .register() API to lookups and transforms to 1.7, then we can
change how the registration works internally, and also deprecate the
current way if there is need to do that.

 - Anssi

-- 
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/1403163020.6531.252.camel%40TTY32.
For more options, visit https://groups.google.com/d/optout.

Re: no relationship between session and user model

Re: no relationship between session and user model

Re: no relationship between session and user model

Re: no relationship between session and user model

Re: no relationship between session and user model

Re: django-firebird backend: migrations and NULL fields

Re: no relationship between session and user model

no relationship between session and user model

Re: django-firebird backend: migrations and NULL fields

Re: django-firebird backend: migrations and NULL fields

Re: Building a library of SQL functions into Django

Re: Building a library of SQL functions into Django

Stack Overflow Open Source Advertising, 2H 2014

Re: Building a library of SQL functions into Django

14 matches

Site Navigation

Mail list logo

Footer information