miniblog.

← Back to all posts
Aug 22, 2013 at 12:36
Choose Django app and model names carefully. Changing them is pain: apps: https://gist.github.com/jamesmfriedman/6168003 models: http://t.co/j2XGY6QSjJ
Renaming a Django app that has migrations already sucks. This Is a way I found to do it that preserves your old migration history and keeps your contenttypes in order. The trick is, this migration cannot be in the app you are migrating, so stick it in your "core" app or another app you have installed. Just plug in your own old and new app names.
Renaming a Django app that has migrations already sucks. This Is a way I found to do it that preserves your old migration history and keeps your contenttypes in order. The trick is, this migration cannot be in the app you are migrating, so stick it in your "core" app or another app you have installed. Just plug in your own old and new app names.
Renaming a Django app that has migrations already sucks. This Is a way I found to do it that preserves your old migration history and keeps your contenttypes in order. The trick is, this migration ...

Related Posts

Jul 13, 2025 at 15:27
13
One nice feature of cargo that I wasn't previously aware of: you don't need to do anything after updating your Cargo.toml. In npm, you need to remember to `npm i` after changing package.json. It's not declarative and the state can get out of sync.
Jun 25, 2025 at 23:39
22
I'm changing method definition syntax in my language: // old fun (this: Int) inc(): Int { this + 1 } // new method inc(this: Int): Int { this + 1 } The original syntax was inspired by Go, but the new syntax is more grep-friendly and perhaps more readable. Not sure about the verbosity though. Thoughts?
Apr 24, 2023 at 07:16
Every time I implement an interpreter with recursion, I regret it. As soon as I want TCO, or userland control of stack limits, or resumable exceptions, I need my own stack. This is awkward because it's an upfront design decision. Changing the stack model is a big refactoring.