Re: Feature idea: forms signals

I'm +1 on adding some signals to forms, because I feel it's weird for Django to have several signals for models, and none for forms. However I don't really have an opinion on what the useful signal points are, because I don't touch forms that often. On 7 March 2017 at 11:13, James Pic wrote: > S

Re: Commitable json dumps

Wait, I just looked into this further, and discovered that the ordering of fields was made deterministic for all serializers in #24558 - this was released in Django 1.9! Enjoy👌 On 7 March 2017 at 22:23, Adam Johnson wrote: > Ah yes, PyYAML just does

Re: Commitable json dumps

Ah yes, PyYAML just does this. It can be disabled by passing a different option to yaml.dump (I think default_flow_style=False) but that would be similar to changing the JSON serializer.. On 6 March 2017 at 16:53, Brice PARENT wrote: > > Le 06/03/17 à 15:44, Brice PARENT a écrit : > >> Le 06/03/

Re: In-memory queryset

On 2017-03-07 07:17, Jacob Kaplan-Moss wrote: > It's certainly _possible_ to implement a in-memory datastore, and > it might be pretty useful. It's just pretty dang hard to do more > than the first 20% or so. Would there also be issues with WSGI spinning up/down various Django processes? Any in-m

Re: In-memory queryset

Hey Paul - There are a couple of implementations I'm aware of: https://github.com/stphivos/django-mock-queries https://github.com/dcramer/mock-django Neither are a complete implementation of the QuerySet API, and I think this is because the QuerySet API surface is _huge_. Implementing the entire

Re: In-memory queryset

This look like a question for django user. The QuerySet API is only an abstraction layer to SQL code. That's why it require a database. If you really don't want to store your object on a filesystem, sqlite support database living only in memory. That's mainly for testing purpose but that could fit

In-memory queryset

Hi, It would be really convenient for me if there was an implementation of the QuerySet API which instead of using a database as its data source, used in-memory model instance that had not been persisted to the database at all. I looked around and found nothing like this. Is this because nothi

Re: Database connection retry

It seems like we have 2 kind of issues: - code broke runserver, - network broke runserver. In the first case, runserver waits for a code reload event which is perfect ;) In the second case, runserver also waits for a code reload event, which is not very intuitive after fixing a network error. So

Re: Database connection retry

Hello, > On 7 Mar 2017, at 13:30, James Pic wrote: > > My question is: is there anything we can do to automate this ? I'm not seeing an obvious solution to this problem. Django has no way to tell it's a temporary issue. -- Aymeric. -- You received this message because you are subscribed to

Re: Database connection retry

It works on SyntaxErrors because updating the code triggers a reload, but if the check fails for something that's not related to code (db conn, redis conn...) then it's stuck and we have to manually interrupt runserver to start it again, unless we touch some code just to trigger the reload as you m

Re: Decoupling forms from models

Sure, this probably involves allowing Form instance definition by composition with a new object (ie. FormConfiguration, ModelFormConfiguration ...) rather than by subclassing Form or ModelForm. I'll make a complete writeup about it ala Diderot then haha -- You received this message because you a

Re: Database connection retry

The behavior of runserver hanging on a check error seems fine to me. That gives you an opportunity to fix the error without having to manually restart the server afterward -- just the same as if you had a SyntaxError. Am I missing the reason why the behavior is problematic? On Tuesday, March 7,

Re: Decoupling forms from models

I don't think this is such a large feature that it requires a DEP but feel free to write more about the problem and possible solution on this thread to see if there's consensus about how to solve it. On Saturday, December 24, 2016 at 10:11:25 AM UTC-5, is_null wrote: > > There is a history of pr

Re: Database connection retry

Thanks for sharing some of your insight Aymeric, if I'm not mistaken then the auto-reload feature/case invalidates Shai's suggestion: would you recommend that the runserver process exits with non-zero when a check fails rather than being stuck waiting for another code change to trigger a reload, so

Re: Feature idea: forms signals

Seems similar to this discussion: https://groups.google.com/forum/#!searchin/django-developers/forms%7Csort:relevance/django-developers/zG-JvS_opi4/wS-4PBfPBwAJ Yes, signal/slot is a pattern that allows quick and easy decoupling of components that have to work on the same payload, and I've been us

Re: Feature idea: forms signals

Hi David, It's good to hear that you did significant research in this area (which I couldn't tell from your original email). I get how this feature can come in handy and I won't stand in the way if it gets implemented. Improving the guidance about when (not) to use signals in the process would

Re: Feature idea: forms signals

I totally agree that signals are open to misuse, and I take your points. Inexperienced developers often seem to use them just because they're there, rather than to encapsulate their apps and avoid circular dependencies. The Django signals documentation could probably do with a bit more guidan