Re: How to let users to block private messages in Django-postman?

[Tim Graham]

This mailing list is for the development of Django itself. Please write to 
django-users for usage questions.

On Thursday, February 11, 2016 at 7:24:11 PM UTC-5, Lukas wrote:
>
> Hi all,
>
> I have instlled django-postman but it works great. However I'd like to 
> allow users to opt for not receiving any private messages. 
>
> I'm wondering how the easiest way to do so?
>
> I've looked at the docs 
>  but 
> could not find such settings so I guess it requires some hacking the source.
>
> I'm not sure where and how it should be applied. 
>
> So appreciate your hints. 
>

-- 
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/64f371c4-8598-49af-95fb-febf319c72ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to let users to block private messages in Django-postman?

[Lukas]

 

Hi all,

I have instlled django-postman but it works great. However I'd like to 
allow users to opt for not receiving any private messages. 

I'm wondering how the easiest way to do so?

I've looked at the docs 
 but could 
not find such settings so I guess it requires some hacking the source.

I'm not sure where and how it should be applied. 

So appreciate your hints. 

-- 
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/86a662cb-2c5e-4e2d-a3d2-1248298c5878%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Curtis Maloney]

On 11/02/16 20:11, Andy Baker wrote:

 > As customisable as it can be, I find the problem to be it is
a data-centric view of your system, closely tied to the database models.

You're correct that a truly 'task-centric' UI would be a lot of effort -
but really - how common are such interfaces in their fullest sense? In
reality nearly every admin UI is a fairly clear mirror of the underlying
data schema. Show me a web app and I've got a fairly good chance of
predicting the db tables.


I think this is a matter of scale... for many small to medium scale 
apps, you can run close to the schema.  But for some of the large 
projects I've worked on, we really needed to hide a lot of complexity 
from the users.



I suspect that what is much more common is the ability to have
'cross-cutting concerns' - i.e. actions that involved and orchestrate
changes over multiple tables. There are many places that you can enable
such things without needing to twist the admin too far out of shape:
usertools, admin actions, custom changelist columns etc etc.


I absolutely agree with this.  Again, for the cases where admin fits, it 
works well.  But going beyond that, there's not a lot of clarity in how 
to fit in with it.



I'm not claiming any of this results in the 'perfect ui' and given the
budget - yes - a ground-up custom admin would probably be superior. But
real-life projects are nearly always budget constrained - especially
away from the public-facing side - and quite frankly - the Django admin
has enabled me to complete projects that would have been financially
impossible to develop without it.


Unfortunately, what I've seen time and again is when people finally hit 
the wall in admin customisation, they're too invested in admin to go any 
other path.  So I always advise caution in this - make sure people go in 
with "eyes open".



 > Is it possible to add other views to admin?  Sure... though it's
not clear, or well documented.

I would argue that it's also fairly clear as it's mostly "just django".
At its simplest an admin view is just a Django view that uses the admin
base template. What's unclear about that? How to incorporate linkage
between the admin-proper and custom views is fairly simple but maybe not
immediately obvious to a beginner. The various hooks for this are fairly
well documented although the documentation is scattered through various
places on this rather monolithic
page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/


Well, part of the problem is, I believe, that admin is structured very 
differently to almost every other part of Django.  It follows that has 
been called a "publisher" pattern, where all related views, etc, for a 
given resource are provided in a single class (more or less).


This monolithic nature is quite different to the "collection of views in 
a module" approach used elsewhere.


I'm not saying this is wrong, but it does mean you have to learn a whole 
new approach in order to work with it on anything beyond a superficial 
level.



A single 'common ways to customize the admin' page could go a long way
to helping here.


+1

--
Curtis

--
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/56BD14D1.4020505%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Chris Foresman]

FWIW, we used to tell clients that Django offers a basic admin interface 
"for free". However, we NEVER had a client that was sufficiently familiar 
with what a database is or how data modeling works for this to ever 
suffice. The first thing we always do on new project is immediately disable 
the admin and simply design APIs that allow our front-end teams to build 
some kind of custom dashboard/admin interface.

IME, the admin is "sufficient" for sysadmins or technically experienced 
users, but in practice those are few and far between.



On Thursday, February 11, 2016 at 12:08:08 PM UTC-6, bliy...@rentlytics.com 
wrote:
>
> While I think it's true that a process centric workflow (wizards, or hubs 
> anyone?) would be incredibly useful, that does not take away from the fact 
> that the model centric admins are also incredibly useful, and time saving.  
> It's so easy to add search, sorting, bulk actions, etc to an admin--these 
> are things I've often spent days or weeks working on in other systems.  
> With django it is often a matter of minutes to add these incredibly common 
> features.  This is probably one of my favorite things about the django 
> framework.
>
> On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney wrote:
>>
>>
>>
>> On 11/02/16 00:55, Andy Baker wrote: 
>> > I can't help but feel that the "admin is very rudimentary and hard to 
>> > customize" is perpetually overplayed by many in the community. Maybe 
>> I'm 
>> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>>
>> I must admit I'm a large proponent of warning against getting caught up 
>> in "Admin as my management console". 
>>
>> As customisable as it can be, I find the problem to be it is a 
>> data-centric view of your system, closely tied to the database models. 
>>
>> IMHO a management interface for site should be a _process_ centric view, 
>> abstracting away the implementation details of tables and fields. 
>>
>> Perhaps a better way to think of it as the difference between a 
>> "management" and a "maintenance" interface. 
>>
>> True, in a lot of cases these can be the same thing, and for simpler 
>> sites Admin works "just fine".  However, I've been on too many projects 
>> that wind up spending a lot of time and effort customising Admin to do 
>> things that would have been simpler in a custom view. 
>>
>> Worse still, I've seen projects alter their schema design to accommodate 
>> Admin's limitations [like lack of nested inlines] 
>>
>> Is it possible to add other views to admin?  Sure... though it's not 
>> clear, or well documented. 
>>
>> Can documentation alone overcome this problem?  I'm not convinced it can. 
>>
>> For some years now I've been proposing an investigation into slicing 
>> Admin into two layers: a base "management interface framework" layer, 
>> and "admin" built atop this framework. 
>>
>> Then we can keep providing the Admin we all know and love, and also make 
>> it easier for people to build their own management interfaces. 
>>
>> However, I don't currently have the time [or admin familiarity] to 
>> undertake this work. 
>>
>> -- 
>> Curtis 
>>
>

-- 
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/7fe074dc-dfbe-484c-8a2c-75f1fa098545%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Carl Meyer]

Hi Anssi,

On 02/11/2016 02:51 AM, Anssi Kääriäinen wrote:
> I created a proof-of-concept pull request for improved deferred fields
> loading. See https://github.com/django/django/pull/6118. In short, it is
> faster and cleaner (no more dynamically created subclasses for deferred
> loading!) than the previous implementation, but we have a couple of
> backwards incompatibilities:
> 1) |Model.__init__()| will be called with value DEFERRED for those
> fields which are deferred. Previously those fields were not given to
> |__init__()| at all.
> 2) The class level attribute Model._deferred must be removed (we
> can't have class level attribute as we don't have dynamic classes any more)
> 3) A potential name clash for fields when one has a class method and
> field with clashing names.
> 
> Of these the Model.__init__() case could be problematic for those users
> who have overridden __init__().
> 
> Before doing any further work on this we should decide if the
> Model.__init__() problem is bad enough to stop this cleanup, and if so,
> do anybody have any ideas of how to avoid the problem?

Overriding Model.__init__() is specifically called out in the
documentation as something to avoid, and there is no mention in the
documentation of what is passed to __init__() in the case of defer/only.
I think this is a fine change to just document in the release notes.

Carl

-- 
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/56BCDB8F.4080408%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: thinking about the admin's scope and its description in the docs

[bliyanage]

While I think it's true that a process centric workflow (wizards, or hubs 
anyone?) would be incredibly useful, that does not take away from the fact 
that the model centric admins are also incredibly useful, and time saving.  
It's so easy to add search, sorting, bulk actions, etc to an admin--these 
are things I've often spent days or weeks working on in other systems.  
With django it is often a matter of minutes to add these incredibly common 
features.  This is probably one of my favorite things about the django 
framework.

On Wednesday, February 10, 2016 at 5:33:03 PM UTC-8, Curtis Maloney wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote: 
> > I can't help but feel that the "admin is very rudimentary and hard to 
> > customize" is perpetually overplayed by many in the community. Maybe I'm 
> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>
> I must admit I'm a large proponent of warning against getting caught up 
> in "Admin as my management console". 
>
> As customisable as it can be, I find the problem to be it is a 
> data-centric view of your system, closely tied to the database models. 
>
> IMHO a management interface for site should be a _process_ centric view, 
> abstracting away the implementation details of tables and fields. 
>
> Perhaps a better way to think of it as the difference between a 
> "management" and a "maintenance" interface. 
>
> True, in a lot of cases these can be the same thing, and for simpler 
> sites Admin works "just fine".  However, I've been on too many projects 
> that wind up spending a lot of time and effort customising Admin to do 
> things that would have been simpler in a custom view. 
>
> Worse still, I've seen projects alter their schema design to accommodate 
> Admin's limitations [like lack of nested inlines] 
>
> Is it possible to add other views to admin?  Sure... though it's not 
> clear, or well documented. 
>
> Can documentation alone overcome this problem?  I'm not convinced it can. 
>
> For some years now I've been proposing an investigation into slicing 
> Admin into two layers: a base "management interface framework" layer, 
> and "admin" built atop this framework. 
>
> Then we can keep providing the Admin we all know and love, and also make 
> it easier for people to build their own management interfaces. 
>
> However, I don't currently have the time [or admin familiarity] to 
> undertake this work. 
>
> -- 
> Curtis 
>

-- 
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/26ee6e6b-f5dd-4959-a8d9-d1be6acfad4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Florian Apolloner]

On Thursday, February 11, 2016 at 1:41:44 PM UTC+1, Florian Apolloner wrote:
>
>  * Unless I miss something, YourModel.__init__ is Model.__init__ if the 
> user didn't change it -> pass is DEFERRED
>

Sadly this is not true, you can check if __init__ is in dict though…

-- 
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/4eb340e5-dfbb-49c4-a597-e24559a66e5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Florian Apolloner]

Oh, I somewhat missread and though there would be a new DEFERRED argument, 
the backwards issue is easy enough though:

 * Unless I miss something, YourModel.__init__ is Model.__init__ if the 
user didn't change it -> pass is DEFERRED
 * If the user changed it check for model._meta.new_style_deferred and 
continue accordingly
 * Raise a warning if the __init__ is a custom one and new_style_deffered 
is not set…

On Thursday, February 11, 2016 at 1:38:44 PM UTC+1, Florian Apolloner wrote:
>
>
>
> On Thursday, February 11, 2016 at 10:51:59 AM UTC+1, Anssi Kääriäinen 
> wrote:
>>
>> Before doing any further work on this we should decide if the 
>> Model.__init__() problem is bad enough to stop this cleanup, and if so, do 
>> anybody have any ideas of how to avoid the problem?
>>
>
> I do not think Model.__init__() is anywhere near public API, add it to the 
> release notes and be done with it, worst case add a try/except around it…
>
> Cheers,
> Florian 
>

-- 
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/e5689091-2c2a-4902-b348-9f57d4375cd2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Florian Apolloner]

On Thursday, February 11, 2016 at 10:51:59 AM UTC+1, Anssi Kääriäinen wrote:
>
> Before doing any further work on this we should decide if the 
> Model.__init__() problem is bad enough to stop this cleanup, and if so, do 
> anybody have any ideas of how to avoid the problem?
>

I do not think Model.__init__() is anywhere near public API, add it to the 
release notes and be done with it, worst case add a try/except around it…

Cheers,
Florian 

-- 
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/35f2d046-530d-483f-9842-4f1820f8deaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review Request] Added support for database delegated fields (like AutoField)

[Anssi Kääriäinen]

On Wednesday, February 3, 2016 at 8:47:16 AM UTC+2, Anssi Kääriäinen wrote:

> For the update_fields change, I think we can do that completely 
> separately. The same goes for changing the way how deferred fields are 
> implemented.
>

I created a proof-of-concept pull request for improved deferred fields 
loading. See https://github.com/django/django/pull/6118. In short, it is 
faster and cleaner (no more dynamically created subclasses for deferred 
loading!) than the previous implementation, but we have a couple of 
backwards incompatibilities:
1) Model.__init__() will be called with value DEFERRED for those fields 
which are deferred. Previously those fields were not given to __init__() at 
all.
2) The class level attribute Model._deferred must be removed (we can't 
have class level attribute as we don't have dynamic classes any more)
3) A potential name clash for fields when one has a class method and 
field with clashing names.

Of these the Model.__init__() case could be problematic for those users who 
have overridden __init__().

Before doing any further work on this we should decide if the 
Model.__init__() problem is bad enough to stop this cleanup, and if so, do 
anybody have any ideas of how to avoid the problem?

 - Anssi

-- 
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/ced9d758-4cfe-4012-b7fc-37aaf221a83e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: thinking about the admin's scope and its description in the docs

[Andy Baker]

> As customisable as it can be, I find the problem to be it is 
a data-centric view of your system, closely tied to the database models. 

You're correct that a truly 'task-centric' UI would be a lot of effort - 
but really - how common are such interfaces in their fullest sense? In 
reality nearly every admin UI is a fairly clear mirror of the underlying 
data schema. Show me a web app and I've got a fairly good chance of 
predicting the db tables.

I suspect that what is much more common is the ability to have 
'cross-cutting concerns' - i.e. actions that involved and orchestrate 
changes over multiple tables. There are many places that you can enable 
such things without needing to twist the admin too far out of shape: 
usertools, admin actions, custom changelist columns etc etc.

I'm not claiming any of this results in the 'perfect ui' and given the 
budget - yes - a ground-up custom admin would probably be superior. But 
real-life projects are nearly always budget constrained - especially away 
from the public-facing side - and quite frankly - the Django admin has 
enabled me to complete projects that would have been financially impossible 
to develop without it.

> Perhaps a better way to think of it as the difference between 
a "management" and a "maintenance" interface. 

I'm not sure I am clear on the distinction you are making here.

> True, in a lot of cases these can be the same thing, and for 
simpler sites Admin works "just fine".  However, I've been on too many 
projects that wind up spending a lot of time and effort customising Admin 
to do things that would have been simpler in a custom view. 

This comes back to my point that it's not a binary choice. The 
admin+customization gets you 80% of the way there quickly. When you find 
something that doesn't fit nicely just add a line to urls.py and a {% 
extends "admin/base_site.html" %} to the top of your template and you've 
got the full power of Django to solve that one particular piece of the 
problem.

> Is it possible to add other views to admin?  Sure... though it's 
not clear, or well documented. 

I would argue that it's also fairly clear as it's mostly "just django". At 
its simplest an admin view is just a Django view that uses the admin base 
template. What's unclear about that? How to incorporate linkage between the 
admin-proper and custom views is fairly simple but maybe not immediately 
obvious to a beginner. The various hooks for this are fairly well 
documented although the documentation is scattered through various places 
on this rather monolithic 
page: https://docs.djangoproject.com/en/1.9/ref/contrib/admin/

A single 'common ways to customize the admin' page could go a long way to 
helping here.



On Thursday, 11 February 2016 01:33:03 UTC, Curtis Maloney wrote:
>
>
>
> On 11/02/16 00:55, Andy Baker wrote: 
> > I can't help but feel that the "admin is very rudimentary and hard to 
> > customize" is perpetually overplayed by many in the community. Maybe I'm 
> > suffering Stockholm Syndrome but I'd like to raise a dissenting voice. 
>
> I must admit I'm a large proponent of warning against getting caught up 
> in "Admin as my management console". 
>
> As customisable as it can be, I find the problem to be it is a 
> data-centric view of your system, closely tied to the database models. 
>
> IMHO a management interface for site should be a _process_ centric view, 
> abstracting away the implementation details of tables and fields. 
>
> Perhaps a better way to think of it as the difference between a 
> "management" and a "maintenance" interface. 
>
> True, in a lot of cases these can be the same thing, and for simpler 
> sites Admin works "just fine".  However, I've been on too many projects 
> that wind up spending a lot of time and effort customising Admin to do 
> things that would have been simpler in a custom view. 
>
> Worse still, I've seen projects alter their schema design to accommodate 
> Admin's limitations [like lack of nested inlines] 
>
> Is it possible to add other views to admin?  Sure... though it's not 
> clear, or well documented. 
>
> Can documentation alone overcome this problem?  I'm not convinced it can. 
>
> For some years now I've been proposing an investigation into slicing 
> Admin into two layers: a base "management interface framework" layer, 
> and "admin" built atop this framework. 
>
> Then we can keep providing the Admin we all know and love, and also make 
> it easier for people to build their own management interfaces. 
>
> However, I don't currently have the time [or admin familiarity] to 
> undertake this work. 
>
> -- 
> Curtis 
>

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

Re: Logged out sessions are resurrected by concurrent requests (ticket 21608)

[Tore Lundqvist]

Thanks for all the help with the patch! I hope its close to being 
acceptable now. Can someone have a look at the PR?

Den tisdag 2 februari 2016 kl. 13:08:51 UTC+1 skrev Tore Lundqvist:
>
> Ok, got that sorted now. How about the fix, is it reasonable?
>
>
> Den tisdag 2 februari 2016 kl. 11:51:19 UTC+1 skrev is_null:
>>
>> Just click "Details" and then "Console output". You'll find this: 
>>
>> + flake8 
>> ./django/contrib/sessions/backends/db.py:91:30: E901 SyntaxError: invalid 
>> syntax 
>>
>> ERROR: 
>> /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py 
>> Imports are incorrectly sorted. 
>> --- 
>> /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:before 
>> 2016-02-01 16:04:24.701654 
>> +++ 
>> /home/jenkins/workspace/isort/django/contrib/sessions/backends/db.py:after 
>> 2016-02-01 16:04:30.952126 
>> @@ -1,8 +1,10 @@ 
>>  import logging 
>>
>> -from django.contrib.sessions.backends.base import CreateError, 
>> SessionBase, UpdateError 
>> +from django.contrib.sessions.backends.base import ( 
>> +CreateError, SessionBase, UpdateError, 
>> +) 
>>  from django.core.exceptions import SuspiciousOperation 
>> -from django.db import IntegrityError, router, transaction, DatabaseError 
>> +from django.db import DatabaseError, IntegrityError, router, transaction 
>>  from django.utils import timezone 
>>  from django.utils.encoding import force_text 
>>  from django.utils.functional import cached_property 
>>
>

-- 
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/b4e867e5-1dda-48a5-9a92-c7c647c42c0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] MySQL Microseconds stripping

[Adam Johnson]

I've released the forementioned command as part of Django-MySQL, see here: 
https://django-mysql.readthedocs.org/en/latest/management_commands/fix_datetime_columns.html

On Friday, February 5, 2016 at 1:03:42 PM UTC, Adam Johnson wrote:
>
> Hi,
>
> I've just finished converting all the datetime columns to datetime(6) in 
> our database after an upgrade to MySQL 5.6. We don't use Django migrations, 
> many of these were done manually with *pt-online-schema-change*. Just 
> catching up on this thread, throwing some ideas in.
>
> Why not strip the microseconds explicitly as soon as you're handed a datetime 
>> with microseconds? 
>
>
> A note here: stripping isn't what MySQL does - it actually *rounds*. This 
> is the most annoying thing since it breaks a 5.6 replica feeding off a 5.5 
> master - it's reported as unfixed bug here: 
> https://bugs.mysql.com/bug.php?id=76948 . (Note: MariaDB kept the 
> stripping behaviour).
>
> We actually ended up patchy.patch ing 
> MySQLdb.times.DateTime2literal so that microseconds never escaped the 
> Python layer in the whole application, whilst we upgraded:
>
> from MySQLdb.times import DateTime2literal
> patchy.patch(DateTime2literal, """\
> @@ -1,3 +1,4 @@
>  def DateTime2literal(d, c):
>  \"""Format a DateTime object as an ISO timestamp.\"""
> +d = d.replace(microsecond=0)
>  return string_literal(format_TIMESTAMP(d), c)
> """)
>
> converting every datetime column of every table to datetime(6) and afford 
>> the extra storage (and probably
>
>
> There's no extra storage usage in fact - the old format of datetime 
> columns in 5.5 was less efficient than the new one in 5.6. Also, whenever 
> you migrate a table that was created on 5.5 with datetime columns on 5.6, 
> they get converted to the new format automatically. 
>
> Does Django have visibility of the field constraints at insert/select 
>> queryset time? 
>>
>
> Django could lookup the precision of datetime columns from 
> *information_schema.columns* , but I don't think it's necessarily a great 
> idea to change the field behaviour to match this.
>
> ./manage.py mysql-upgrade-microseconds && ./manage.py migrate ?
>>
>
> If you're imagining a command to generate migrations, you can't do this 
> for third party apps. It might be better to have a command that simply 
> outputs, or runs, the SQL to alter all tables, outside of the migrations 
> framework? I'd've liked that, I ended up using a little script like that 
> here to generate the SQL and then run it manually/with 
> *pt-online-schema-change*. I'll look at open sourcing it in Django-MySQL 
> so you guys can look at it.
>
> On Tuesday, December 22, 2015 at 2:56:41 AM UTC, Cristiano Coelho wrote:
>>
>> I think a simple setting allowing to use the old behaviour should be 
>> enough, shouldn't it? How does it handle other db backends? I'm not sure if 
>> oracle has an option for datetime precision, but if it does, it makes sense 
>> to have a global setting for datetime precision, as right now you are 
>> pretty much forced to always go with a precision of 6 (at least on mysql?) 
>> and that might be just too much if you want a simpler datetime.
>>
>> El lunes, 21 de diciembre de 2015, 19:54:29 (UTC-3), Josh Smeaton 
>> escribió:
>>>
>>> I think this is a fairly big oversight that should be fixed in the most 
>>> backwards compatible way, so users don't need to change their code, or only 
>>> have to change it minimally. I'm with Aymeric here. Does Django have 
>>> visibility of the field constraints at insert/select queryset time? Ideally 
>>> Django would handle the differences transparently. If that's not possible 
>>> then we should have a migration or script that'll do the conversion on 
>>> behalf of users once off.
>>>
>>> ./manage.py mysql-upgrade-microseconds && ./manage.py migrate ?
>>>
>>>
>>> On Monday, 21 December 2015 19:39:44 UTC+11, Aymeric Augustin wrote:

 2015-12-20 22:57 GMT+01:00 Cristiano Coelho :

> Thanks for the suggestion, I think that work around might just add too 
> much code, so I'm probably going the way of converting every datetime 
> column of every table to datetime(6) and afford the extra storage (and 
> probably a little performance impact ?).
> I think the documented change might need a little more of attention, 
> and mention something about that any equality query will stop working if 
> you either don't strip microseconds or update datetime columns to 
> datetime(6) (and not even datetime(3) will work...)
>

 If that's the solution we end up recommending -- because the horse has 
 left the barn months ago... -- then we must document it in detail.

 This is a large backwards incompatibility that may result in subtle 
 bugs and requires non-trivial steps to fix. It doesn't live up to Django's 
 standards.

 -- 
 Aymeric.

>>>

-- 
You received this message bec