I have to agree with Marteen.
>From my experience what really slow down the migrate and makemigrations
command is the rendering of model states into concrete model classes. This
is something I concluded from my work on adding the plan object to
pre_migrate
and post_migrate signals.
As soon as
On Saturday, November 5, 2016 at 4:53:49 PM UTC+1, Patryk Zawadzki wrote:
>
> 1. Dependency resolution that turns the migration dependency graph into an
> ordered list happens every time you try to create or execute a migration.
> If you have several hundred migrations it becomes quite slow. I'm
W dniu sobota, 5 listopada 2016 19:57:38 UTC+1 użytkownik Aymeric Augustin
napisał:
>
> My solution is to throw away and remake all migrations on a regular basis.
> Then I `TRUNCATE TABLE django_migrations` and `django-admin migrate
> --fake`. Obviously this isn’t a great solution.
>
> Since I
W dniu sobota, 5 listopada 2016 18:40:24 UTC+1 użytkownik Shai Berger
napisał:
>
> > 2. Dependency resolution is only stable as long as the migration set is
> > frozen. Sometimes introducing a new migration is enough to break
> existing
> > migrations by causing them to execute in a slightly
On Saturday, November 5, 2016 at 6:56:29 PM UTC+1, Sjoerd Job Postmus wrote:
>
> If you go with storing the base domain in the threadlocals, why not go
> full in and store the request itself in the locals? [1]
>
Because that opens a whole new can of worms, if possible we want less
threadlocals,
Light week due to Django Under the Hood travel and attendance. Busy day of
sprints today. Jenkins hasn’t yet recovered!
Triaged
---
https://code.djangoproject.com/ticket/27410 - Clarify staticfiles "is
enabled (default)" in ref (fixed)
https://code.djangoproject.com/ticket/27414 -
Hello,
My solution is to throw away and remake all migrations on a regular basis. Then
I `TRUNCATE TABLE django_migrations` and `django-admin migrate --fake`.
Obviously this isn’t a great solution.
Since I work mostly on small projects with just a couple developers on staff,
doing this every
W dniu sobota, 5 listopada 2016 17:30:15 UTC+1 użytkownik Andrew Godwin
napisał:
>
> Hello! I have opinions about this :)
>
>
>> Possible solution (or "how I'd build it today if there was no existing
>> code in Django core"):
>>
>> a. Make migrations part of the project and not individual
If you go with storing the base domain in the threadlocals, why not go full in and store the request itself in the locals? [1]
As far as using it in the templates... We have a RequestContext right? So in most cases that should not be an issue I presume.
But yes, Celery would be a problem, unless
Hi,
On Saturday 05 November 2016 17:53:49 Patryk Zawadzki wrote:
>
> I'm typing this from the comfort of Django: Under the Hood sprints so
> please excuse poor grammar and the somewhat chaotic explanations that
> follow. I'm very tired and English is not my mother tongue. This is not a
> DEP but
What I was trying to suggest is that the base domain gets stored in one of
our threadlocals so that we can generate the full URL without having access
to the domain (though I just realize that this wouldn't work in the case of
celery etc :/)
On Saturday, November 5, 2016 at 5:53:49 PM UTC+1,
For me use cases were callback urls sent to some 3rd party and of course -
emails.
Yeah, I wasn't thinking about url tag.
I'm not 100% sure I understand what you are suggesting.
If we choose to go down the path of using kwarg I could change this in the
`reverse` method itself. That way
Hello! I have opinions about this :)
> Possible solution (or "how I'd build it today if there was no existing
> code in Django core"):
>
> a. Make migrations part of the project and not individual apps. This takes
> care of problem 3 above.
>
It also means it's impossible for apps to ship
W dniu sobota, 5 listopada 2016 13:24:28 UTC+1 użytkownik Jacob Kaplan-Moss
napisał:
>
> Hi all -
>
> DEP 7 proposes a new dependency policy. In a nutshell, the policy is:
> Python packaging is good now. Django can have dependancies.
>
> For full details, please check out the DEP:
>
Greetings, Jazz Guitarists,
I've briefly talked about this with Markus and he mentioned that the
subject was already brought up by Tyson Clugg but I think it deserves a
proper discussion here.
I'm typing this from the comfort of Django: Under the Hood sprints so
please excuse poor grammar and
To be honest, I think I do not really see the usecase here. I know that
sometimes it is required to generate full urls (especially in emails), but
quite often in those you do not have access to the request at all. Also,
how would this play together with the url tag? Personally I would set the
It looks like Mysql pretty much works like postgres.
Same Collate function works just fine, when i create database with utf8
charset and then use collations like utf8_estonian_ci for
estonian, utf8_general_ci for english and utf8_swedish_ci for swedish. I
guess mysql experts can comment on if
Hi!
So during DUTH sprints i took on an issue that i created over 3 years
ago: https://code.djangoproject.com/ticket/21181...
The actual fix or improvement for my case right now actually really simple:
class Collate(Func):
function ='COLLATE'
template = '(%(expressions)s) COLLATE
As discussed with many core team members (Simon Charette, Josh Smeaton,
Marc Tamlyn, Tim Graham) at DUTH 2016 sprints, myself and Joachim
Jablon have proposed a new, simpler solution to this.
See https://code.djangoproject.com/ticket/27446
The proposal therefore is to add a `readonly` option
During the sprint in Amsterdam I created a pull request
https://github.com/django/django/pull/7484
In it I'm adding an optional argument `request` to
`django.urls.base.urls.reverse`method.
The idea is that using `request` object one can get a fully qualified URL.
The idea is taken from Django
I think the "maturity" criteria are pretty sensible, though I am slightly
concerned about the potential for a project to be effectively unmaintained
even though there's someone's name on it who are active elsewhere.
Do you think there's a sensible way we could outline a few checks for what
it
Hi everyone,
It's been almost a year since the Channels funding project started, and a
little while since it became an official Django project, and it's been hard
to know what the state of it is at times.
I'm going to start doing monthly updates on how Channels is progressing and
what's going
Hi all -
DEP 7 proposes a new dependency policy. In a nutshell, the policy is:
Python packaging is good now. Django can have dependancies.
For full details, please check out the DEP:
https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst
I'd appreciate any comments and
23 matches
Mail list logo
