Re: slow migrations

Reporting back on some additional findings for what it's worth. SmileyChris dumped and recreated the project in question's migrations, manually ordering them to minimize dependencies. It was not a major reduction in total migrations: 82 to 58 (mostly third-party migrations and initials), but the

Re: Vote on Jira as bugtracker

I'm not a lawyer, but I care about licensing. The MIT License would allow you to relicense it, but you must keep the original copyrights in tact. (From license: Redistribution and use in source and binary forms, *with or without modification*, are permitted...) It does have a list of "buts" too.

Re: re-thinking middleware

Sent from my iPhone > On Jan 7, 2016, at 20:50, Carl Meyer wrote: > > Hi all, > > Back at the Django Under the Hood sprints in November, Florian and I > started batting around some ideas for fixing some of the problems with > the existing middleware abstraction. Florian put

re-thinking middleware

Hi all, Back at the Django Under the Hood sprints in November, Florian and I started batting around some ideas for fixing some of the problems with the existing middleware abstraction. Florian put together an initial pull request with a POC for some of those ideas. I've now updated the proposal

Re: Vote on Jira as bugtracker

Hi Andrey, On 01/07/2016 04:23 PM, Andrey Antukh wrote: > On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner > The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive > license that does not impide take the source and re-license it under > other license. > > taiga.io

Re: Vote on Jira as bugtracker

HI Florian On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner wrote: > Hi Yamila, > > On Thursday, January 7, 2016 at 2:22:21 PM UTC+1, Yamila Moreno wrote: >> >> I just wanted to let you know that me or anyone in our team would be glad >> to answer any question about the

Re: Vote on Jira as bugtracker

Weighing in on Jira specifically - I’ve had to use it on a number of projects, and I’ve never had a good experience with it. That might be because the Jira instances were badly configured - bit if that’s the case, it suggests to me that there’s a deeper problem with Jira being too complex for it’s

Re: Vote on Jira as bugtracker

I used Jira at my previous company. It is a great tool, but it is _extremely_ heavyweight. Unless you need to high level of customisation of workflows and integrations it can provide, and have someone intimately familiar with it and/or have the nearly-full-time job of learning and fiddling

Re: [Feature Request] Orderable ArrayAgg and StringAgg in contrib.postgres.aggregates

Seems reasonable enough to me. Expressions already support generating an ORDER BY clause by calling .asc() or .desc() on them. That'd allow your proposed API to support: Model.objects.aggregate(ArrayAgg(some_field, order_by=F('some_field').asc() )) Or any other expression. Consider that any

Re: Vote on Jira as bugtracker

Hi Yamila, On Thursday, January 7, 2016 at 2:22:21 PM UTC+1, Yamila Moreno wrote: > > I just wanted to let you know that me or anyone in our team would be glad > to answer any question about the product, saas or installation, migrating > issues or anything related. No strings attached, of

Re: slow migrations

On 01/07/2016 03:03 PM, Aymeric Augustin wrote: > As far as I understand, the CPU cost comes from generating a full set of > model classes for each step of the migration history. That’s consistent > with the profile sent by Florian. > > I usually end up throwing away the migration history and

Re: slow migrations

Yes, it's basically a fundamental design flaw of having the migrations represented this way - it makes autodetection and code generation very accurate, but at the expense of calculation time. There is some optimisation work that can be done to try and avoid building intermediate states, but it's a

Re: slow migrations

As far as I understand, the CPU cost comes from generating a full set of model classes for each step of the migration history. That’s consistent with the profile sent by Florian. I usually end up throwing away the migration history and regenerating a new set of migrations when I get to that

Re: slow migrations

Also, is there any chance that I can get access to this project to profile a little bit more and identify some hotspots? On Thursday, January 7, 2016 at 9:10:26 PM UTC+1, Florian Apolloner wrote: > > Just looking at the topmost three entries: > *_expire_cache* spends 18 second in delattr, can

Re: slow migrations

As far as I know, no one is actively working on this area at the moment. There is at least one open issue: https://code.djangoproject.com/ticket/22608 You can look through all open migrations tickets too:

Re: Vote on Jira as bugtracker

Hi, > Are you already familiar with Trac and the way we use it? > I'm familiar with trac (we were using it some year ago), and I'm a bit familiar with django workflow because I attended a couple of sprints. Anyway, I'm not an expert in trac. > > Key things are: > > * integration with

Re: Vote on Jira as bugtracker

On Thu, Jan 7, 2016, Yamila Moreno wrote: >I'm Yamila, part of Taiga Team and Kaleidos (the company that develops >Taiga.io). We're very happy to be as a "completely hypothetical" candidate >for a new bugtracker. Taiga (a Django and open source project) being used >by

Re: Vote on Jira as bugtracker

Hi there, I'm Yamila, part of Taiga Team and Kaleidos (the company that develops Taiga.io). We're very happy to be as a "completely hypothetical" candidate for a new bugtracker. Taiga (a Django and open source project) being used by django-dev would be huge :) I just wanted to let you know