+1, documenting in this case seems to be the most appropriate.
Robert Roskam
On Monday, February 13, 2017 at 10:51:59 AM UTC-5, Adam Johnson wrote:
>
> What do you think? Absent a better suggestion, we could document this
>> pitfall so that there's something to point to when related tickets co
Yes, if a ticket goes weeks or months without activity, it's unlikely
someone is working on it, so it's fine to reassign.
On Wednesday, February 15, 2017 at 9:11:01 PM UTC-5, Robert Roskam wrote:
>
> Hey All,
>
> So it's over a year later, and even though there is consensus, this ticket
> (https
Hey All,
So it's over a year later, and even though there is consensus, this ticket
(https://code.djangoproject.com/ticket/15727) appears to have had no
progress.
Would it be OK if someone else were to pick up this ticket and move it
forward?
Robert Roskam
On Sunday, December 6, 2015 at 11:2
Hi all,
Was looking at implementing a custom signing backend via a HSM to sign and
validate my Django sessions without knowing the key.
It seems that the functions signing.loads() and signing.dumps() force you
to use TimestampSigner [1] rather than calling get_cookie_signer(). This
has the int
Hi Raphael,
I've been working on making the optimizer a bit smarter recently and came
to the
same conclusion as you concerning the "left" and "right" optimizations.
This should be possible to solve by allowing `Operation.reduce()` to return
the
full list of operations it replaces by appending `
>
>
> You're essentially speaking about 2 things here, in my opinion:
>
> 1. Adding a new feature for interactive squash
> 2. Improving the MigrationOptimizer
>
> I certainly see a point for 2. Not sure how much for 1. Anyway, your
> reasoning for 2 sounds great! I'd be more than happy if you want
Markus: Now that I've written a command to optimize a single migration
file, I think that it's sufficient for the "squash, edit, optimize"
workflow that I was doing before. It's more about offering people to get
their squashing done well until our optimizer becomes omniscient.
Florian: Having
Thanks Raphael, that's a pretty good write up!
You're essentially speaking about 2 things here, in my opinion:
1. Adding a new feature for interactive squash
2. Improving the MigrationOptimizer
I certainly see a point for 2. Not sure how much for 1. Anyway, your
reasoning for 2 sounds great! I'
What might be interesting to look into when squashing all migrations in one
app would be to assume no migrations would exist. That could then result in
only 2 migrations which could run through the optimizer (as opposed to
let's say 20 migrations with many more operations).
/Markus
On Wednesda
Fwiw I think by default it could/should try to optimize all migrations of
an app, manually specifying the migration name should be optional.
On Wednesday, February 15, 2017 at 2:00:54 PM UTC+1, rap...@makeleaps.com
wrote:
>
> I ended up having some time today, so wrote up a management command fo
Hi Raphael,
It looks like a similar idea was proposed in
https://groups.google.com/d/topic/django-developers/C1L-NhyQYG4/discussion.
I don't think a ticket was ever created, so you can do that.
100% test coverage is required. Why would we accept untested code? ;-)
On Wednesday, February 15, 20
I ended up having some time today, so wrote up a management command for the
first suggestion!
I called it "optizemigration"
>>> ./manage.py optimizemigration appname 0001_squashed
# snipped django startup noise
Optimized from 9 operations to 4 operations
Optimized migration /Users/rtpg/pro
Hello everyone,
I spent a couple hours last night trying to improve the migration
squasher optimizer (migrations were taking almost 15 minutes in CI). I came
up with a couple ideas for anyone interested in improvements:
1- Having an interactive mode for squashing would be interested.
Curr
On Wed, Feb 15, 2017 at 12:21 AM, Adam Johnson wrote:
> Sorry for the terrible pun here, but I'd like to suggest the
> meta-feature... allowing 3rd party apps to add their own options to Meta
> classes. If there was a sensible API for this (or if Django just copied all
> attributes defined in Met
14 matches
Mail list logo
