Hi,
one of the things I like about channels is how simply it fits into
development workflow with runserver. I remember how painful it was to run
celery on my laptop with all the rabbitmq, worker and celery beat
processes. However, I now ran into usecase requiring the use of the delay
server an
Hi Vaclav,
This is because there's only so much we can pack into runserver; when you
develop with Celery, for example, you would probably need to run Celery
unless you turn ALWAYS_EAGER on (and then not actually see any potential
race conditions).
If you don't want to run Redis locally, you can u
dj-database-url gives Django developers two main things:
1. the ability to represent their database settings via a string (a-la
sqlalchemy); very useful for environmnent variables and 12factor apps.
2. it will automatically use the DATABASE_URL environment variable, if present.
I'm not sure if
Hi Kenneth,
I think there are a few things to consider before we can merge/reuse
dj-database-url.
* How are third party backends going to fit into this scheme?
* What about other options like CACHES which very much suffers from the
same problem.
Cheers,
Florian
--
You received this message
I don't think the code will be able to be re-used as much as the
idea/ux/functionality that it provides.
I can imagine any backend being able to convert from a url string with some
methods (e.g. `detect_url` (bool return) and `parse_url` (settings dict return
type).)
Perhaps the same scheme c
Ah, I see what you're saying about third-party backends.
I imagine that you'd have to be able to merge a url string with a settings dict
(one overrides the other). This is how usage of that functionality is manually
provided in dj-database-url.
--
You received this message because you are su
My two cents: connection strings/database URI's are a feature I've sorely
missed in Django.
Built-in functionality to convert environment variables like
DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant
DATABASE setting would make some deployment situations a lot simpler.
Cur
To elaborate on this feature request:
When working on a Django project with other people, a common issue is
unintentionally creating conflicting migrations. These happen silently if
two developers create and merge migrations in parallel. It's not clear
there is a problem until after the second
I am personally unsure about this - it's extra overhead for smaller Django
sites, and something that larger teams could easily adopt themselves. I
think it might make more sense as a third-party app that plugs in?
Andrew
On Wed, May 24, 2017 at 12:39 PM, wrote:
> To elaborate on this feature re
On Wednesday, May 24, 2017 at 9:42:20 PM UTC+2, Andrew Godwin wrote:
>
> I am personally unsure about this - it's extra overhead for smaller Django
> sites, and something that larger teams could easily adopt themselves.
>
Yeah, I do not see an immediate need for this either.
--
You received th
After two years, made a PR for this during PyCon
sprints: https://github.com/django/django/pull/8546 🍾
Em sábado, 5 de dezembro de 2015 04:31:12 UTC-8, Collin Anderson escreveu:
>
> Basically, the origin check would only be useful for safari (in this
> case). Everywhere else we'd still need to re
11 matches
Mail list logo