6 ms·
Solid list! For most of those bullets I definitely had the 'Oh wow, should have done this sooner' moments. I'd add: - use South (right away!) - Class Based Vi
by famousactress 14y ago
Solid list! For most of those bullets I definitely had the 'Oh wow, should have done this sooner' moments. I'd add:
- use South (right away!)
- Class Based Views
- (not django specific) use virtualenvs!
- apendleton 14y agoThe article recommends using MongoDB as a primary data store, so South wouldn't be applicable (and that's specifically addressed).
- conesus 14y agoActually, I use South to manage data migrations (as opposed to schema migrations) in MongoDB. That way I can ensure that I've run the same data migrations on all of my dev and prod databases. Just a `./manage.py migrate` and every developer is caught up.
- mrtron 14y agoAm I the only one left who finds south more trouble than it is worth?
- misiti3780 14y agoi think it is the best solution out there right now ... someone had a kickstarter recently to replace it, but I can't seem to find that info via google right now ...
- briancurtin 14y agoI believe you're thinking of Andrew Godwin's schema migration kickstarter: http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django http://www.kickstarter.com/projects/andrewgodwin/schema-migr...
- misiti3780 14y agoyep - that is what i was looking for - thanks
- akarambir 14y agoAndrew Godwin had that Kickstarter and he is the creator of South. Here is the link http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django http://www.kickstarter.com/projects/andrewgodwin/schema-migr...
- akarambir 14y agoWhen I started using South, I was much in awe and loved its ease. But as time passed migrations became completed and south soon came to its knees.
- scaryclam 14y agoI find that generally, when this happens it's due to a bad / non-existant migration policy (it's just as important as your branching strategy to keep migrations solid). Migrations should be able to rebuild an entire database from scratch. If it can't then the migrations have been screwed up.
- dbla 14y agoI'm working on a tool for better schema migrations as well. Currently it only supports MySQL but more RDBMS's coming soon: http://devjoist.com http://devjoist.com
- jsmeaton 14y agoGood luck, but you may want to reconsider. Andrew Godwin (author of South and Django contributor) is building a new version directly into Django core. http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django http://www.kickstarter.com/projects/andrewgodwin/schema-migr...
- famousactress 14y agoThe only one? No, I'm sure not. In the vast minority? I'd suspect so :) South is pretty obtuse to learn and definitely has it's warts and issues, which Andrew seems well aware of and wants to fix so check out the kickstarter link below! That said, our project has over three hundred tables, a couple thousand migrations, and I've been very happy with it compared to the systems I've rolled myself in the past. I'm certainly unaware of an alternative that holds a candle to it, assuming Django's ORM.
- pico303 14y agoI came to Django & South after using ActiveRecord and Rails migrations for years, and it drove me nuts. Not trying to cause a big argument, but why the big push in the Python community to model database tables via object properties/fields? I seem to recall SqlAlchemy does something similar.
- wmil 14y agoFrom 'The Zen of Python' - Explicit is better than implicit. Automatically generating properties after querying the database is seen as unpythonic. PyLint and some IDEs/editors will not be happy if you try.
- regularfry 14y agoDataMapper 1 does the same. It does make sense if you're worried about changes to your database schema spontaneously breaking previously working code.
- pico303 14y agoNo, I get that part. I'm talking more about building a database from models. It seems like these tools are designed to build the database scheme from the object models, which to me is just as bad as building the objects from the schema. Ideally, we should use the declarative style of Django models and SqlAlchemy on the object, along with the scheme generation tools of Rails migrations.
- tocomment 14y agoI totally agree with you. I just export the SQL and see what tables need to change.
- metaphorm 14y agoSouth can be troublesome, but what's your alternative? never make changes to your schema? do it painstakingly by hand from the psql command line? just suck it up and use South, warts and all. its still really good, even though its not perfect.
- mattdeboard 14y ago...what's your alternative? Write SQL and interact with your RDBMS directly?
- metaphorm 14y agothat is not a viable practice over the long run. the entire point of using a migrations tool is so you can migrate the schema and the data forwards and backwards automatically and consistently every time. attempting to do that with raw SQL scripts is a disaster waiting to happen. its so bad that the entire idea of a migration tool was invented to solve this problem. so I ask again: what's your alternative (given that avoiding raw SQL scripts is the problem you're trying to solve)?
- mattdeboard 14y agoI'm getting sucked into an argument I don't really care about because I actually like South and use it in production for some things. But I mean idempotent SQL takes care of the vast majority of all this stuff you mentioned. Write your SQL properly and it doesn't matter whether or not it's been applied before.
- mh- 14y agoI don't know about postgres offhand, but there aren't idempotent solutions to some DDL operations in mysql. (alter table add column, off the top of my head)
- mattdeboard 14y agoYeah in Postgres you can check for the existence of a column in a table. If it exists/doesn't exist you can drop/add the column. Obviously "ALTER TABLE x ADD COLUMN y" isn't idempotent, but the whole SQL statement around it can be idempotent.
- tomlu 14y agoMaybe if you're working on your own. If you're in a team (where each member has her own local DB) and multiple environments for testing, staging, preproduction etc. I'd say you're going to want some sort of scripted migration.
- kingrolo 14y agoMy workflow is to only add south to the project when required. To begin with I use a bash script which trashes and rebuilds the DB each time I wish to. Data which needs to survive this gets dumped to fixtures (using another bash script).
- archivator 14y agoAre class based views really any good for anything outside of CRUD? I've found the documentation (and, more importantly, rationale) lacking. Generally, when I try and use them, I spend more time figuring out how to customise than when I write "normal" views.
- famousactress 14y agoI should be specific. I never use the built in Django views. I'm sure they're great but I don't like that much magic and I moved to class based views later in a project.. those seems easier in a clean-room build. I do, however use class based views that I've built myself. We extend them and add mixins and I much prefer all of this to the decorator soup that is the alternative.
- archivator 14y agoAh, fair enough, that makes more sense. Last time I tried to use the built-in ones, I just scrapped the project after two days and redid it with functions. It's not magic if it doesn't work!
- jscn 14y agoThere's definitely a learning curve, but CBVs will give you much DRYer views. Being able to use mixins is a godsend.
- tomlu 14y agoI don't know about class based views - each time I've tried to use them they've started out nice and convenient then slowly turned into an over-engineered mess as my requirements got more complicated. I think I prefer the control and simplicity of function-based views even if there's a bit more duplication.