Re: can_introspect_default feature

2016-10-25 Thread Tim Graham 
It isn't always possible to transform arbitrary Python defaults 
(particularly callables) into SQL.

A search query would help you answer a question like this. I typed
"django database column defaults site:code.djangoproject.com" into Google 
and found
https://code.djangoproject.com/ticket/470 among other tickets.

...or searching the archives of this mailing list for "django database 
defaults" gives discussions such as:
https://groups.google.com/d/topic/django-developers/nrVzOnHBk64/discussion

On Tuesday, October 25, 2016 at 3:39:54 PM UTC-4, Chris Foresman wrote:
>
> Out of curiosity, why isn't this added as part of the column definition? 
> Isn't it better to enforce the default at the DB layer? Or is it to account 
> for differences across database types? (This trips me up a lot because we 
> have a lot of different apps/processes which have to touch the database and 
> only the API server is written in Django.)
>
>
> On Thursday, October 20, 2016 at 7:53:23 AM UTC-5, Tim Graham wrote:
>>
>> The 'default' model field option is used in Python rather than in the 
>> database. SchemaEditor might set a column default to ease populating a 
>> value on existing rows but that default shouldn't be left in the column's 
>> definition. self.assertIsNone(field.default) means that the column 
>> doesn't have a default.
>>
>> On Thursday, October 20, 2016 at 8:29:29 AM UTC-4, Maximiliano Robaina 
>> wrote:
>>>
>>> Hi Tim,
>>>
>>> Thanks for response.
>>>
>>> El martes, 18 de octubre de 2016, 12:07:34 (UTC-3), Tim Graham escribió:

 Hi Maxi,

 Did you take a look at the relevant commit that introduced the flag?

 https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc

>>>
>>> Yes, I was looking into this changeset, but I can't understand yet what 
>>> "And that the default is no longer set in the database." means in 
>>> test_add_field_default_dropped [1].
>>> field.default contains the column default definition not the default 
>>> value of the some table record, Is it that correct?, So, why this must be 
>>> None?
>>>
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc#diff-888b45a0a8f38ee67e8d22403cf994dbR1371
>>>
>>>
>>> Regards 
>>>
>>>
>>>

 On Tuesday, October 18, 2016 at 9:51:46 AM UTC-4, Maximiliano Robaina 
 wrote:
>
> Hi,
>
> How supposed to can_introspect_default must work?
>
> I'm working on django firebird backend and I'm trying to figured out 
> how this feature works, but the schema tests fails. 
> This default is at database level or django level?
>
> If I define a field with a default value, and do a metadata 
> introspection over this field to know if default value is defined, it 
> always returns True.
>
> I hope be clear (sorry for my bad english)
>
> ---
> Maxi
>


-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f68e1d3d-42f4-4cc2-ae25-31226cd2f980%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: can_introspect_default feature

2016-10-25 Thread Chris Foresman 
Out of curiosity, why isn't this added as part of the column definition? 
Isn't it better to enforce the default at the DB layer? Or is it to account 
for differences across database types? (This trips me up a lot because we 
have a lot of different apps/processes which have to touch the database and 
only the API server is written in Django.)


On Thursday, October 20, 2016 at 7:53:23 AM UTC-5, Tim Graham wrote:
>
> The 'default' model field option is used in Python rather than in the 
> database. SchemaEditor might set a column default to ease populating a 
> value on existing rows but that default shouldn't be left in the column's 
> definition. self.assertIsNone(field.default) means that the column 
> doesn't have a default.
>
> On Thursday, October 20, 2016 at 8:29:29 AM UTC-4, Maximiliano Robaina 
> wrote:
>>
>> Hi Tim,
>>
>> Thanks for response.
>>
>> El martes, 18 de octubre de 2016, 12:07:34 (UTC-3), Tim Graham escribió:
>>>
>>> Hi Maxi,
>>>
>>> Did you take a look at the relevant commit that introduced the flag?
>>>
>>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc
>>>
>>
>> Yes, I was looking into this changeset, but I can't understand yet what 
>> "And that the default is no longer set in the database." means in 
>> test_add_field_default_dropped [1].
>> field.default contains the column default definition not the default 
>> value of the some table record, Is it that correct?, So, why this must be 
>> None?
>>
>>
>>
>> [1] 
>> https://github.com/django/django/commit/75303b01a9cc900eebf1f27ba0bc6508334242fc#diff-888b45a0a8f38ee67e8d22403cf994dbR1371
>>
>>
>> Regards 
>>
>>
>>
>>>
>>> On Tuesday, October 18, 2016 at 9:51:46 AM UTC-4, Maximiliano Robaina 
>>> wrote:

 Hi,

 How supposed to can_introspect_default must work?

 I'm working on django firebird backend and I'm trying to figured out 
 how this feature works, but the schema tests fails. 
 This default is at database level or django level?

 If I define a field with a default value, and do a metadata 
 introspection over this field to know if default value is defined, it 
 always returns True.

 I hope be clear (sorry for my bad english)

 ---
 Maxi

>>>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05dd4112-84fd-4a1c-8d5c-0fbeac202649%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should we require pytz for timezone support in Django?

2016-10-25 Thread Aymeric Augustin 
Hello Tim,

Considering that there’s no evidence of anyone using the feature, that it 
doesn’t work well in all circumstances, that we have an alternative which works 
better and has no downsides (considering the new policy on dependencies), I 
think that’s reasonable.

I’m afraid we’ll get a couple complaints a few months after we’ll drop security 
support for 1.8, not during the 1.11 alpha period… But that doesn’t change my 
arguments. If we get feedback during 1.11 alpha then we’ll have to reconsider.

(Disclaimer — I’m more tolerant of backwards-incompatible changes than many 
other committers.)

-- 
Aymeric.

> On 24 Oct 2016, at 22:51, Tim Graham  wrote:
> 
> I asked on django-users [0] if anyone is using settings.TIME_ZONE=None and 
> didn't get any responses. Does it seem okay to drop that for now and react if 
> we get any complaints about its removal?
> 
> [0] https://groups.google.com/d/topic/django-users/CxAiS6PXs3U/discussion 
> 
> 
> On Wednesday, October 12, 2016 at 3:12:44 PM UTC-4, Tim Graham wrote:
> Would you be comfortable recommending that package for anyone who needs the 
> autodetection?  This seems to work:
> 
> from tzlocal import get_localzone
> TIME_ZONE = get_localzone().zone
> 
> What would change compared to the behavior of TIME_ZONE=None is that Django 
> will set os.environ['TZ'] (except on Windows). I don't really understand the 
> use case where doing that may have been a problem [0].
> 
> [0] https://code.djangoproject.com/ticket/1480 
> 
> On Wednesday, October 12, 2016 at 12:58:19 PM UTC-4, Aymeric Augustin wrote:
> > On 12 Oct 2016, at 18:22, Tim Graham > wrote: 
> > 
> > is there some other approach we could take? 
> 
> To obtain the pytz timezone for the local time, you’d need something like: 
> https://github.com/regebro/tzlocal  
> 
> It isn’t exactly straightforward… This approach seems sub-optimal. 
> 
> -- 
> Aymeric. 
> 
> 
> -- 
> 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/f83d112d-d2c6-4201-91ad-80578f23df0d%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  (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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7747B0D4-153D-4B6C-9F8F-2517E85BAFD9%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.