Re: Scaling Django for Multiple Teams
My bad--see you guys on the other side. -Ben On Mon, Apr 18, 2016 at 5:31 PM, Tim Graham <timogra...@gmail.com> wrote: > This mailing list is for the development of Django itself. Please use > django-users for usage questions. Is there some place we could improve that > would have helped you identify the correct list? > > On Monday, April 18, 2016 at 8:11:38 PM UTC-4, bliy...@rentlytics.com > wrote: >> >> Hey, >> >> I have two issues I'm looking at solving at work, and I'm looking for a >> couple suggestions as to how other people have solved this. The two things >> are: >> >> * scale out their django installation to allow for smaller releases (I'm >> thinking microservices, but it could also be internal django apps or who >> knows what else) >> * minimizing the impact of migrations during releases (aka we want to be >> able to release in the middle of the afternoon >> >> Currently we put up a maintenance page whenever we are doing database >> operations (aka migrations). This seems like a recommended best practice. >> >> One way I was thinking about addressing this issue was to break all of >> our models out into a separate repo. That way we'd only need to deploy >> migrations when the models themselves have deployed. For code that needs >> the models, we could pip install the repo as an app and away we go. >> Likewise it seems like I could break up different parts of our app via a >> similar strategy. >> >> Does this seem viable? How have other people solved this kind of problem? >> >> Thanks, >> >> -Ben >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/dTTtiSXgiz0/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/80d98b66-4c80-4b45-af68-a24bbaa7a6bd%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/80d98b66-4c80-4b45-af68-a24bbaa7a6bd%40googlegroups.com?utm_medium=email_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.* Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com 1132 Howard Street, San Francisco CA 94107 Visit our Website <http://www.rentlytics.com> | Watch our Video <http://youtu.be/Pe_9KE_fj34> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADgLBUPcg0%2BO-_2tGe%3D%2BXrE_qZqtWeSEniCmFrg%2BaTZuNnnRWg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Revisiting lazy middleware initialization
ause problems with the test suite which seems to rely on >> the old behaviour in places. The above proposal passes all existing tests >> as is. >> >> >> ### 4. Backwards compatibility issues >> >> Middleware constructors have no means of accessing the request object or >> anything that depends on it. They are called right at the start of the >> handler's `__call__` method before the `request_started` signal is sent and >> before the `script_prefix` thread-local is set. Therefore it cannot matter, >> from the middleware class's perspective, whether it is instantiated before >> or after the first request comes in. >> >> >> I'm aware this issue probably isn't high on anyone else's priority list, >> but I think it would count as a genuine -- if small -- improvement to >> Django. >> >> Thanks, >> >> Dave >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > <https://groups.google.com/d/msgid/django-developers/f61a2b50-01e3-48ef-809f-82edc23d9da4%40googlegroups.com?utm_medium=email_source=footer> > https://groups.google.com/d/msgid/django-developers/f61a2b50-01e3-48ef-809f-82edc23d9da4%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/iIm7M6aUJmU/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/56F861CF.8060909%40bristle.com > <https://groups.google.com/d/msgid/django-developers/56F861CF.8060909%40bristle.com?utm_medium=email_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.* Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com 1132 Howard Street, San Francisco CA 94107 Visit our Website <http://www.rentlytics.com> | Watch our Video <http://youtu.be/Pe_9KE_fj34> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADgLBUOqur2bRirOgps8gPYSFQBFcRCav29XGnxd4unN1SxR7Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: PostGres 9.5 Upsert
Hey--that's pretty slick. I'm not sure when we're going to take a shot at this implementation, but I'll keep that in mind. -Ben On Mon, Feb 1, 2016 at 7:12 AM, <john.par...@plushrugs.com> wrote: > It should be possible to use a "RETURNING" clause to get the new row even > in the instance of a get_or_create. > > I occasionally use an UPDATE ... RETURNING query with Manager.raw to > update a table and get modified instances in one shot. > > On Tuesday, January 12, 2016 at 12:54:03 PM UTC-6, bliy...@rentlytics.com > wrote: >> >> After thinking about it a bit, I think the only function that would >> really benefit from this would be the update_or_create. If you're doing >> get_or_create you still need a second query to get the actual row. >> >> On Friday, January 8, 2016 at 4:13:26 PM UTC-8, bliy...@rentlytics.com >> wrote: >>> >>> Hey Guys, >>> >>> Postgres 9.5 has added the functionality for UPSERT aka update or >>> insert. Any interest in aligning UPSERT on the db layer with the >>> get_or_create or update_or_create functionality in django? Sounds like my >>> company would be interested in doing the work if the PR will get the >>> traction. >>> >>> -Ben >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/swBPqFi-Tdk/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/2b8db682-1b8d-4549-8d8c-f99f3d6b8f90%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/2b8db682-1b8d-4549-8d8c-f99f3d6b8f90%40googlegroups.com?utm_medium=email_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- *Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.* Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com 1132 Howard Street, San Francisco CA 94107 Visit our Website <http://www.rentlytics.com> | Watch our Video <http://youtu.be/Pe_9KE_fj34> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADgLBUM%2B7DOCHLYiOvRh-XXRRWfWVOQUZ%3DrNprQ8f48D_7fm9w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: MOSS Award to Django
> > And, beyond that, there are plenty of non-critical tasks that applications > could easily offload until after a response has been sent - like saving > things into a cache or thumbnailing newly-uploaded images. > http://channels.readthedocs.org/en/latest/concepts.html#concepts I mean this example sounds like celery to me. You don't want an image to maybe have a thumbnail generated. And you have no return value to the client when the thumbnail is generated. -Ben On Tue, Dec 15, 2015 at 3:41 PM, Shai Berger <s...@platonix.com> wrote: > On Wednesday 16 December 2015 01:07:16 Ben Liyanage wrote: > > > > I get that the goal of this is for asynchronous web requests, but if it's > > generalized right it seems like it could cover doing any kind of work > > without the pressure of completing a web transaction in a timely fashion. > > > No, because Channels are designed to be non-reliable (each message is > delivered at most once), and if I understand correctly this is a key point > in > the design. Celery gives you much stronger delivery guarantees, > > Shai. > -- *Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.* Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com 1132 Howard Street, San Francisco CA 94107 Visit our Website <http://www.rentlytics.com> | Watch our Video <http://youtu.be/Pe_9KE_fj34> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADgLBUOb8v0VozfcX%3D7t8_zgGznbqHU%3D57PZpoArP5%3DGC8yxQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: MOSS Award to Django
So a channel must result in a response to a browser? It seems both from the config (routing things into functions, or queues) and the underlying tech (using redis or whatever) sounds very similar to celery. >From the docs: - Interface servers, which communicate between Django and the outside world. This includes a WSGI adapter as well as a separate WebSocket server - we’ll cover this later. - The channel backend, which is a combination of pluggable Python code and a datastore (a database, or Redis) and responsible for transporting messages. - The workers, that listen on all relevant channels and run consumer code when a message is ready. I get that the goal of this is for asynchronous web requests, but if it's generalized right it seems like it could cover doing any kind of work without the pressure of completing a web transaction in a timely fashion. -Ben On Tue, Dec 15, 2015 at 2:09 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hi Ben, > > Celery and channels don’t tackle the same problem. > > Celery is an asynchronous task queue. It is designed perform expensive > work after responding to a HTTP request. At that point there is no possible > communication with the browser. > > Channels is an asynchronous message framework. It enables asynchronous > messaging between the browser and Django, going beyond the current > request-response structure. > > Best regards, > > -- > Aymeric. > > > > On 15 déc. 2015, at 22:35, bliyan...@rentlytics.com wrote: > > Hey, > > Channels sounds a lot like celery (or celery sounds like part of > channels). Is that a fair read? Looking for tighter REST integration > either way. > > Thanks, > -Ben > > On Friday, December 11, 2015 at 10:19:00 AM UTC-8, Andrew Godwin wrote: >> >> Hi everyone, >> >> For those who haven't seen, Mozilla has awarded $150,000 to Django for >> work on Channels and request/response improvements lifted from REST >> Framework. More in the blog post here: >> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/ >> >> I'll be coordinating this effort for the most part, but we're still >> working out who to fund and the roadmap for the project, as well as work >> out how we can pay people for their work on a different scale to the Django >> Fellowship, so it might take a bit of time! >> >> I'll be back on here with some questions for people to discuss/answer >> about the channels design at some point soon, but a lot of the basic design >> is already up at http://channels.readthedocs.org, so take a read over >> that if you're interested. >> >> What I can say is that my intention is to both bake Channels into the >> next major release of Django, as well as hopefully release a pluggable app >> version that will run on 1.8 and 1.9 - I have some plans around how to do >> that effectively, but they involve hitherto unforged paths around Django >> and how we package dependencies, so I can't say we'll get there 100%. >> >> Andrew >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/299ede52-6ae4-46d3-8667-40e7fa6a89a6%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/299ede52-6ae4-46d3-8667-40e7fa6a89a6%40googlegroups.com?utm_medium=email_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/3pTMfHa8SFE/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/D5557CBB-03D8-4DB2-AAFA-B4063E227D8A%40polytechnique.org > <https://groups.google.com/d/msgid/django-developers/D5557CBB-03D8-4DB2-AAFA-B4063E227D8A%40polytechnique.org?utm_medium=email_so
[Feature] On CommandError, sys.exit(1)
Hey, What do you guys think about this feature request? > On CommandError, sys.exit(1) It would be pretty easy to do the sys.exit(1) right here: https://github.com/django/django/blob/df0a446fd4c864c003e4f941b5b7abd6f10c9427/django/core/management/__init__.py#L289 This would allow you to fail an automated build when migrations (or any other management command) failed. Currently I see no way of doing that. Beyond that, I noticed that the sys.exit(1) is not very consistently applied on the makemigrations management command (for example, it is not called when the --merge parameter is supplied). I can do the PR for the CommandError thing (unless anyone sees a reason not to, or that would not work/there is a better place to put it). -- *Ben Liyanage *|* Software Engineer *|* Rentlytics, Inc.* Phone: (410) 336-2464 | Email: bliyan...@rentlytics.com 1132 Howard Street, San Francisco CA 94107 Visit our Website <http://www.rentlytics.com> | Watch our Video <http://youtu.be/Pe_9KE_fj34> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADgLBUOGCwMqV052WgA-o3PPrT5tb2%3DT%3D9vc%2BO5JZRQYZJCC%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
