The problem with --update is that if overwrites the most recent migration,
then it might be used to modify a committed and distributed migration,
which is a Bad Thing. The flag would probably be useful to people with my
use case, if they trust themselves to use the flag with care and remember
t
OK, it turns out that the "safe update migrations script" too simple to
even qualify as a "script":
git clean myapp/migrations -f && python manage.py makemigrations
Perhaps the solution is to document this on the testing page as a solution
to the "accumulation of many small migrations during de
That script would be bad if you'd run any of those migrations against your
development db (yes it should be "throwaway" or rebuildable but...)
Personally, I'm strongly in favour of Shai's suggestion and also in favour
of --update, mainly as I like being able to capture (most) migrations has
logica
> That script would be bad if you'd run any of those migrations against your
> development db (yes it should be "throwaway" or rebuildable but...)
>
I'd think the same could be said of --update? As I understand it, --update
is the equivalent of deleting the most recent migration and recreating
South's `--update` also rolled the previous migration back, changed it and
then reapplied it to the current database.
M
On 28 March 2014 10:48, Bernie Sumption wrote:
>
> That script would be bad if you'd run any of those migrations against your
>> development db (yes it should be "throwaway"
>
> South's `--update` also rolled the previous migration back, changed it and
> then reapplied it to the current database.
>
OK, in that case I can very much see how it's useful for people who develop
against a persistent database. That's probably most people.
Anyway, the result of this threa
Yes, --update is very risky if you run it on migrations that are already
committed and pushed, but the main reason I left it out of 1.7 was
complexity (because makemigrations is now much more intelligent, updating
and adding a foreignkey into a migration might introduce a new dependency
or force a
I know Django will be sprinting at PyCon, and I thought I might like to
participate. I haven't done conference sprints before, so I'm curious,
what's the process? If I have a particular ticket that I'm interested in,
do I just work on that bug at the sprint? Or will there be a proposed list
of
Hello,
I'm not sure this thread is going anywhere and I don't care either way.
If you've been reading up to this point...
... either you have too much spare time. Rather than rehashing this debate,
may I suggest triaging some tickets? That would really help!
https://docs.djangoproject.com/en/dev
Hello,
There's no particular process. Just show up, pick a ticket you're interested
in, assign it to yourself, and figure out a resolution. Rinse, repeat ;-)
I would simply advise to setup a development environment in advance. Check out
the source and make sure you can run the tests. That's all
So is that a "no" to the docs patch proposal?
Cal
On Fri, Mar 28, 2014 at 8:52 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> I'm not sure this thread is going anywhere and I don't care either way.
> If you've been reading up to this point...
>
> ... either you h
On 28 mars 2014, at 22:28, Cal Leeming [Simplicity Media Ltd]
wrote:
> So is that a "no" to the docs patch proposal?
It isn't. Like I said, I really don't care. If someone wants to commit
something, that's fine.
--
Aymeric.
--
You received this message because you are subscribed to the Goo
Okay great, I'll send a docs patch in next week (assuming no one shows any
disagreement), and hopefully that'll be the end of it!
Thanks to all for your feedback.
Cal
On Fri, Mar 28, 2014 at 10:04 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 28 mars 2014, at 22:28, Ca
13 matches
Mail list logo
