Re: [Question] MySQL Microseconds stripping

Erik, I'm using MySQL 5.6.x and indeed it has microseconds support, but that's not the issue. The issue is that every datetime column created has no microseconds (since they were created with django 1.7, so it is actually a datetime(0) column) and I would like to keep it that way, however,

Re: [Question] MySQL Microseconds stripping

> Den 19. dec. 2015 kl. 07.52 skrev Cristiano Coelho : > > Hello, > > After django 1.8, the mysql backend no longer strips microseconds. > This is giving me some issues when upgrading from 1.7 (I actually upgraded to > 1.9 directly), since date times are not stored

Re: [Question] MySQL Microseconds stripping

Also I would like to add, that even if the mysql column is a 0 fractional datetime column, and you send a datetime with some fraction in it (which is what django does right now), it won't handle it correctly (ie trim the fraction since the actual column has no fraction) but instead just try to

[Question] MySQL Microseconds stripping

Hello, After django 1.8, the mysql backend no longer strips microseconds. This is giving me some issues when upgrading from 1.7 (I actually upgraded to 1.9 directly), since date times are not stored with micro second precision on mysql, but the queries are sent with them. As I see it, my only

Re: structural & functional review of django documentation

Hi Doug, On 12/18/2015 04:35 PM, Doug Epling wrote: > I filed bug report > > #25952 > > but apparently it was in the wrong place. In case it wasn't clear, it wasn't in the wrong place because it was documentation-related, it was in the wrong

structural & functional review of django documentation

I filed bug report #25952 but apparently it was in the wrong place. And I referenced this post , but I was thinking it was this group ...

Re: Channels integration plan, first draft

On Fri, Dec 18, 2015 at 5:34 PM, Marc Tamlyn wrote: > [Note: I have not read all the channels docs, sorry if some of these > points are covered there.] > > On a packaging note, is there a way to use django[channels] type syntax > like flask does? I'm not familiar with the

Re: Channels integration plan, first draft

On Friday, December 18, 2015 at 6:34:41 PM UTC+1, Marc Tamlyn wrote: > > I've said this in person to you, but I think a REDIS_SERVERS setting like > DATABASES would be a hugely useful feature for django independently of > channels, especially if it supported tests well. I'm yet to find a third

Re: Channels integration plan, first draft

That syntax allows you to add extra, opt in lists of dependencies to install. It does not pass through to runtime. Sent from my iPhone > On Dec 18, 2015, at 12:34 PM, Marc Tamlyn wrote: > > On a packaging note, is there a way to use django[channels] type syntax like >

Re: Channels integration plan, first draft

On Fri, Dec 18, 2015 at 5:28 PM, Anssi Kääriäinen wrote: > On Friday, December 18, 2015, Andrew Godwin wrote: > >> >> >> On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin wrote: >> >>> > You seem to be assuming I'm here to foist a brand

Re: Channels integration plan, first draft

[Note: I have not read all the channels docs, sorry if some of these points are covered there.] On a packaging note, is there a way to use django[channels] type syntax like flask does? I'm not familiar with the restrictions of this but it may remove the need for try/except imports. I'm also

Re: Channels integration plan, first draft

On Friday, December 18, 2015, Andrew Godwin wrote: > > > On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin > wrote: > >> > You seem to be assuming I'm here to foist a brand new middle layer on >>

Re: Make template caching a feature of the Django template engine

On 18 déc. 2015, at 16:21, Tim Graham wrote: > Seems okay to me, but what about the point "It would also be useful to have > caching enabled in development so the template loading behaviour is (mostly) > the same in development as it is in production.” Would it be

Re: Channels integration plan, first draft

On Fri, Dec 18, 2015 at 3:44 PM, Mark Lavin wrote: > > You seem to be assuming I'm here to foist a brand new middle layer on > everyone; I'm not. I'm here to make one that fits neatly into Django, that > I think most people will want to turn on, and that provides a lot of

Re: Make template caching a feature of the Django template engine

When I created my initial branch for this, it was easy enough to auto reload a file once it changed, but it was difficult to deal with template directory precedence. For instance, if `admin/base.html` was cached, but a custom `admin/base.html` was added in a loader or directory with higher

Re: Channels integration plan, first draft

> You seem to be assuming I'm here to foist a brand new middle layer on everyone; I'm not. I'm here to make one that fits neatly into Django, that I think most people will want to turn on, and that provides a lot of value in exchange for a slight round-trip performance hit - my goal is sub-5ms,

Re: Make template caching a feature of the Django template engine

Seems okay to me, but what about the point "It would also be useful to have caching enabled in development so the template loading behaviour is (mostly) the same in development as it is in production." Would it be feasible to always enable the cached template loader and control the proposed

Re: Channels integration plan, first draft

On Fri, Dec 18, 2015 at 2:00 PM, Mark Lavin wrote: > Anssi criticisms are fair and I feel that some of these responses are > glossing over the details. > I'm sorry if it comes across like that - a lot of these are things I've been considering for a while and so I can

Re: Channels integration plan, first draft

Anssi criticisms are fair and I feel that some of these responses are glossing over the details. You've claimed this is the same or equivalent to a forked worker model but it isn't because there is no process management/link between the interface and worker and because you've chosen to make this

Re: Channels integration plan, first draft

On Fri, Dec 18, 2015 at 7:34 AM, Anssi Kääriäinen wrote: > I have a gut feeling this isn't going to work that well. The reasons > include: > - Backwards compatibility: how is a large site going to upgrade from 1.9 > to 1.10? > None of the core view API will change. A 1.9