andrewgodwin

Hi Greg,

There's no books or anything, alas, nor is there a very good corpus of material on this field - there's a few good talks out there, but I've not seen a great deal of written material.

Perhaps I need to write a book as well? Not sure I need another Kickstarter, though!

I already have written code for this several times in the past for the basic constraint types, but not the where clauses - I'll check it out. Thanks!

You're more than welcome, thanks for contributing! It's companies like yours that help such a good ecosystem exist.

You won't need to tell other machines that there's a new migration set - they'll just realise and migrate appropriately (new machines on the new initial, old ones on the left-over old ones until they're all done and you can remove them).

The Django Software Foundation and I considered it, but Kickstarter is really well-designed for making new projects and is a trusted brand for payments. Building our own would have taken both time and having to get a merchant account working, which is not a good use of resources, really.

So the situation here is indeed interesting - I understand your concern. I've asked all the other core contributors to Django their opinions on this and there's been resounding support from them, so that's not a concern.

I also have a day a week free for this, so there's no concern of this robbing income - that day a week was previously used for learning to fly, and now I'm done with that it needs to have something that pays in order to keep me going. If the choice for that is freelance or open source work, and they pay closely, you can bet I'm going for the open source work.

If it gets that high, I'll likely give some back to the DSF, yes, or put it towards other core feature projects. Or perhaps just have the next DjangoCon sponsored by "Schema Migrations".

I know. So happy.

Part of this is coming up with a new spec for Django field types to allow this stuff to work better, so that'll hopefully do what you want.

Thanks a lot - your contribution is much appreciated! I hope this helps set a trend.

Exactly, the value here is in linking it directly to the models and apps paradigm of Django. South already does this, and people love it, so it seems reasonable to continue down that path and make it even better.

South is actually based on ActiveRecord's migrations a little bit (or rather, it was 4 years ago) but the key difference is autodetection of changes - Rails models are essentially declared via migrations, while Django ones are created in a separate models.py file, so there's a need to detect when changes are made.

I try to address the key points in the Kickstarter, but essentially South is too fragile (it relies on exactly linear histories) and too verbose (bakes the entire ORM state into every migration) - the main point is to fix those.

It's also worth pointing out that this IS the built-in schema migration that's going in in 1.6 or 1.7.

Worth mentioning that if someone wants to ask me (I'm running this) questions about this I'll be checking here!

That's how I thought it'd work, just curious. Looking forward to reading up how it works - I hope it's not too fragile.

Interesting - I was trying to get this concept to work a few years ago after I got a live SVN/Mercurial translator working, but it was very hard due to all the differences they note in this post.

One thing they don't mention is "octopus merges" - Git allows a merge to have more than two parents, while Mercurial does not. I'm sure there are other tiny edge cases, too; I wonder how they handle those?

Perhaps more to the point, I'm concerned that this means you're stuck using the lowest common denominator of both systems - for example, no hg bigfiles stuff.

I'm curious to see how this compares to MRI/Rubinius/JRuby once it's feature-complete; the PyPy vs. CPython benchmarks these days are pretty convincing.

This is a very interesting point (re: the guilt especially) - sometimes I'm almost dissuaded from releasing code because in the end it might have a net negative impact on my life.

There's even stories of people hunting down email addresses from git/SVN commit data and emailing about problems years later to people who only ever released the code as a "hey, this is interesting" attempt.

I'm not sure what the solution is - responsibility is important in any healthy open-source project, but sometimes I just want to release code as a way to potentially let someone else do a bit less coding, not as some well-maintained library attempt.

However, in the reverse way, the migrations defining the models (as in Rails) often leads to mismatches as well. There's no easy solution to this problem, alas.

When model-based migrations work, they work really well, and help reinforce code schema/database schema being entirely in sync.

Backwards migrations are really only designed for quick testing in development - you really shouldn't be running them in production unless you just made a major screwup.

It's entirely possible to shoot yourself in the foot, but that's also what makes South versatile enough. Hell, there's a good reason that I recommend raw SQL in migrations as a solution sometimes - you'll still get the record-keeping and dependency stuff, so it's not like you're throwing it all away.

There is, hopefully in a couple of releases' time. There are some posts I made to the mailing list about it a while ago - I can't look them up quickly though - and a talk I did at DjangoCon this year.

Unfortunately the permissions thing is really, really tough to fix - and not using Django permissions myself nor in any work projects, one that's rarely high on my priorities, alas.

For Git stuff, just make sure you're aware of who is writing migrations where and know what to do when you get a conflict. Making sure you have lots of smaller apps rather than one giant one really helps.

(Author of South here) Nice article - good set of common pitfalls, too. The multiple people one is especially tricky for people when they first encounter it, it seems.

I'm hoping I can resolve some of these issues (like the permissions thing) when we start moving parts of the code into Django proper.

Nice to see this appear here! Probably worth pointing out that we spent a few weeks preparing for this move - it's not something you can pull together in a few days (unless you're very laissez-faire about your data).

This article seems particularly biased against Intel - it gets down to what are almost character attacks at points.

I'd love to see a more level-headed analysis of the Ultrabook space. There's over a hundred different ones now (which may in itself be a problem), and some have replaceable RAM/hard drives, some have full-height Ethernet, and it's at least made the OEMs think about decent industrial design (and in the case of Asus and Lenovo, I think that's worked).

It's not some massive panacea, but I for one welcome the new boon of lighter, thinner and better-built laptops.

Yep, that was me - thanks!

Ah, that's at least some good news. It was a little inspired by the diagrams at Green Park of the lifts there, so accessibility might be a good idea.

I'd appreciate any FOI advice - might be best if you contact me directly? Email is on my page at aeracode.org/about/

I fixed that just after you posted the comment, I think.

Yes, there's a reason I only did one - it would be a bit of a monoculture if I'd done ten or so. It's the same for a lot of the outlying stations on the other lines too.

I know - sorry about that. The JS is a bit hacked together! I want to get some decent linkable URLs for stations too at some point.

EDIT: Added it in, back button works as you'd expect now.