Hi everyone,
I'm happy to announce RabbitMQ channel layer for Django Channels!
During last month an a half I'm developing this library and achieve some
meaningful results. I hope you will find this library interesting and will
give it a try.
You can find released package on PyPI:
https:/
Hi everyone,
I'm happy to announce RabbitMQ channel layer for Django Channels!
During last month an a half I'm developing this library and achieve some
meaningful results. I hope you will find this library interesting and will
give it a try.
You can find released package on PyPI:
https:/
The Django API is powering a single-page app, so while there are tokens
instead of sessions, from the user point of view there is an explicit login
process to grab a signed token. I wanted to hook to the corresponding
signal to log these login events. It's probably better if I do it inside my
l
In the end, I don't use MySQL but if a similar change were made for
PostgreSQL, I would find the current approach more annoying (bothering me
about changing defaults over two release cycles) than cautious.
I'm also uncertain that duplicating a deprecation warning in a system check
is a good pre
>
> aside from some very performance-sensitive websites that already worked
> around Django’s bugs
Tbf it's true I already added READ-COMMITTED at work
I’d love if this fix made it into 1.10
On 13 January 2017 at 15:05, Aymeric Augustin <
aymeric.augustin.2...@polytechnique.org> wrote:
>
Hello,
I think there’s been little feedback because this issue is very, very far from
the concerns of most Django users — aside from some very performance-sensitive
websites that already worked around Django’s bugs and will add the
configuration line needed to keep whatever the isolation level
Are you sure you need to depend on users "logging in" through an API? Most
authentication methods used in APIs are stateless and there is no explicit
login and logout process. You either include the credentials (be it bearer
token, auth header, custom data or whatever) or not. The credentials ar
I guess three days is too little time to get a consensus on this. At this
point I'm thinking to defer this from 1.11.
On Wednesday, January 11, 2017 at 9:50:27 AM UTC-5, Patryk Zawadzki wrote:
>
> To add some context, REPEATABLE READ can break get_or_create among other
> things (not sure how man
Hello,
I agree that this setting has become less useful now that has
won.
It made more sense when it wasn’t clear whether XHTML1.1 would take over HTML4.
I’d be interested to hear about use cases, if someone still uses it and reads
this.
--
Aymeric.
> On 13 Jan 2017, at 04:10, charettes