 Hello everyone. Can everyone hear me? Is this alright? I'm used to screaming so make sure the mic's working. So, hi. I'm Andrew Pinkham. I'm a half-French, half-American freelance consultant from Austin, Texas. I teach Django Incorporate and Startup Settings, but perhaps most importantly, as Miles just told you, I'm the author of Django Unleashed, which is currently available in pre-release on Safari Books and is set to be in print form at the beginning of 2015. And the book is all about, is currently written in Django 1.7, and so I've been working in Django 1.7 in alpha and beta since January of this year. So, I've been fiddling with it. I wouldn't say I would know as much as say Andrew Godwin with the talk this morning, but I've gotten to dabble. And so this leads us into the following talk. There are basically two things that I'm going to really try and talk about. The first is Django releases. Django comes with all these numbers. What do they mean? What are they useful for? So we're going to look at the meaning of the numbers associated with each Django release, how each release is sort of created, and how they're related, and how this helps you figure out how you should go about upgrading around Django. Then we're going to look at Django 1.7 itself, and what we're going to do is we're going to build a project in 1.6 and 1.7 exactly the same way to try and look at the differences in a very practical manner. Now, here's the thing. If you're a migration or a Django enchanter or else the old man from scene 34, this talk is not for you, right? This is supposed to be a very beginner talk about upgrading and all of that. And so if you are any of those things, you're going to be horribly, horribly bored, right? So with that said, what I do, I like to put a whole bunch of material for my talks up online, so you can go to this right now. The slides are already accessible. I have a long draft of an article with all of this content almost ready to go. It should be there within the next week, week and a half. What that means is that if you don't want to listen to me right here right now or else on YouTube, you can go to this link and you can actually read the article in a nice, relaxed setting, because I'm going to do a little bit of a whirlwind tour here, right? So let's get started with Django versions, right? So every Django version has three numbers. That would be a major number, a minor number and a micro number. Let's get this out of the way right away. It is not semantically versioned, right? There is a very strict set of rules for semantic versioning. Django does not follow them at all. Django has its own very explicit system. Notably, micro numbers are incremented for a release for bug fixes or security releases. Minor numbers are incremented for the addition or removal of features, and we'll see exactly how that works out. And then major number, in the documentation it says that major numbers are incremented for large backwards incompatible changes. The thing is that in practice what we're seeing is that Django 2.0 is actually just going to be the version after Django 1.9. So at this point they're just sort of associated with minor versions. So not a whole lot of meaning there to be pretty blunt about it. So the thing to remember is that colloquially, colloquially, there we are, a Django version refers to a different minor number. So when you hear someone say it's a different Django version, it's 1.7 versus 1.6, right? But 1 is the major number, 7 is the minor number, and 0 is the micro number. There are also pre-release. There's an entire pre-release system, alpha, beta, typically pretty self-explanatory. Release candidates, not everyone is super clear on, a release candidate is just a release that is almost ready for production. The API calls and features may not be modified at this time, and you are limited to bug and security fixes. So at that point it's almost like you're already in micro-release process. To separate the version numbers and releases from pre-releases, what the Django Source Foundation will do is they will add a letter and a number at the end. So for instance, 1.70a1 denotes the first alpha release. You don't need the 0, they'll remove it. So 1.7 beta1 is the first beta release, and this is the second release candidate. So what does that all mean? We now know what the numbers are, and how does that help you? Well, Django has two officially supported versions at all time. That means that there are two versions that you should be working with at the very least, right? That's what you want in production on your website. Deprecation happens in two versions. Now what this means is that the release guide is really saying who shall be the number thou shalt count, and the number of the counting shall be two, right? It's kind of important in the Django release. The deprecation specifically, anything that is deprecated in 1.3 will still be accessible but with a warning in 1.4 but is totally removed in 1.5. So for 1.7, anything that was said to be deprecated in 1.5 still worked in 1.6 but is now gone, right? So it is worth paying attention to two versions back. The two versions that are running, so it was released yesterday. Nice to be able to change my slides at the last minute. Support prior to version 1.7 was 1.66 and 1.59, and you'll notice I'm not using the micro numbers. Those patches, you should always be on the latest patch. There is no reason not to upgrade to the latest patch. So 1.6.6, 1.5.9, but with the arrival of 1.7, we saw a bump in all of the available versions. So 1.7 brought the arrival of 1.6.7 and 1.5.9, except that 1.5 is no longer supported, right? You don't actually want to be running in 1.5 anymore. It's not going to get security releases. It's not going to get any releases. It's considered done. It's over. There's a catch, right? There are two versions, but there's also the long-term support. Django, the project, allows itself to tag certain releases and certain versions for long-term support and what that means is that they will support it for some length of time. LTS for 1.4 is set to go to March of 2015. There is some back-and-forth over whether the support ends there or they continue to support it, so not really sure, but my recommendation would be you really want to be thinking about 1.7 or 1.6, but we'll come back to that in just a moment. Now that we understand what the versions are, what the version numbers mean, we can talk about the previous Django versions. This will help inform us about 1.7 and the upgrade process, right? So the obvious thing is that while we're talking about 1.7 and 1.6 is currently supported, so we want to know a little bit about those, but 1.5 is going to affect the deprecation process in 1.7, and so that's still important, and 1.4, of course, is actually supported because of LTS. So let's start with Django 1.4. Django 1.4 started off with time zone support, right? That was the big new thing. It saw a couple additions to the ORM, such as prefetch-related, kind of a big deal, but also some really basic stuff like cookie-based session handling. That only came in 1.4, and auth security passwords prior to this were stored all in SHA-1 and this was when we saw the public key derivation function 2 come in as well as Bcrypt. That's huge for security. That's a major upgrade. And then, of course, functional browser testing and a new structure for your folder, and so 1.4 was pretty massive. It's also why it's for LTS. 1.4 is arguably, I'm not sure everyone would agree with me on this, but is arguably modern Django, right? It's sort of the beginning, yeah, I'm getting a couple of shakes. It's nice. Okay. Which is why, so this was March of 2012 and so in February of 2013 we had Django 1.5. Django 1.5 felt like a much smaller upgrade, right? So Python 2.5 was dropped, so you had to be in 2.6 or 2.7 and there was experimental support for Python 3. You could try it. It wasn't recommended. It was more like hey, test this out, give it a go. We saw the custom Django user and the function-based views that had been deprecated in 1.3 were completely removed in favor of the generic class-based views which currently exist, and which I'm actually a huge fan of despite anything else. So it felt kind of small, but you really want to pay attention to that Python 3 support. That's actually a huge deal and was a lot of work. Now the thing about 1.5 is that the upgrade was nonetheless still really tricky and the reason is that there were mandatory settings in deployment and they weren't always obvious, right? It wasn't always obvious when you went to deploy what was going on when it aired like crazy. Because you needed use time zone, allowed host, you need to make sure you have a secret key, otherwise it went nuts. And this is actually kind of important because this, I think you'd have to ask Russell, but I think this may in fact be the reason they actually have what is originally the validate command and what has become the check command in 1.7. So pay attention to those settings. We'll come back to it. Which then led to 1.6. And 1.6 was huge, right? So still 2.6, but Python 3 support was now totally official and we had transactions completely redone spearheaded by Emory Gaugustin. And so transactions hadn't been changed since version 0.9 and suddenly you could auto-commit database changes. There was the concept of atomicity via decorators and then there was fine-grained rollback between save points if your database supported it and persistent database connections. Finally, settings got super easy. If you were a beginner in Django and you showed up in 1.6, your life was incredibly simple compared to all the previous versions. There was a baster in settings which was lovely. The SQL light database was now a default. Admin was turned on by default and so was clickjacking. So that was super, super cool. This is where, on the other hand, we also see the validate command. This was to try and help with figuring out basic setting differences. What was wrong? It was a nice step. It gets us to where we want to be in 1.7. The only trick was that with the upgrade here, if you've done funny things with transactions, you were in trouble. But the other thing is that we see the beginning of a trend where Django begins to remove a lot from the contributed library. This is where comments marked down and local flavor really get taken out. That leaves us with Django 1.7. For those who missed it, this was what Russell wrote on the Django web blog right before selling us t-shirts, which he's wearing today, by the way. If you can catch Russell, that is, in fact, the t-shirt he sold us all. It's kind of a big deal. These are some of the features. We're going to focus mainly on those top three because that's what we've got time for. This was released, of course, yesterday. This is going to be a World War Tour. I want to try and take, I've heard some people who are just a little bit afraid of the migrations. There's nothing to be afraid of. They're fantastic. You want these. Get excited. Now, I haven't put the Python version on here. That's on purpose. Django 1.7 requires Python 2.7. It's going to be maybe the most difficult part of the new requirements for this version. Of course, Python 3 is still supported. Thank goodness. If I could really get this to be the one thing you take away, Python 2.6 is no more. It has ceased to be. It's expired and gone to meet its maker, but rest of life, it rests in peace. This is an ex-Python. Don't use it. No, really, just, I want you to take this as, like, word of God for me here, right? If I could get one thing, please, please, and really consider upgrading to Python 3. It's going to be really important pretty quickly. With that said, let's jump directly into building a project in Django 1.6 and Django 1.7. So we're going to build a project called Camelot. We're going to build an app called Roundtable. And we're going to build a night model. And what we're going to do to demonstrate the three key new features is that we're going to take our nights. We're going to create a really, really basic model. And then we're going to be betrayed by Lancelot. So we've been asked by King Arthur to build this up and to get the information out there. It's good publicity. So, again, these are the three things we're really going to focus on. And the rest is really, really cool. You should take a look, but this is what we're looking at right now. Now, the reason for that is because this is a total rabbit hole. There is so much here. And it's really, really cool. But this is what we're going to end up like if we spend too much time here. So this is a whirlwind. And I'm going to show a lot, a lot, a lot of code. The code is actually not what's important in the coming slides. I've put it there in all its glorious details so you can download my slides. You can go through the article. The article actually has more code. So you can actually go through it more slowly. What's much more important is sort of the philosophy and the workflow that you're going to see me go along. So that's the focus. And the code, you know, come back to it. But let's have a first pass at it. So let's start by creating a project. You guys have all done this. And so the first difference is that in Django 1.6 you had Django admin. And there is now a nice alias so that you can just do Django admin without the .py. The structure of the folder looks almost exactly the same. The only difference is that in settings there is a session authentication middleware which will invalidate existing settings in the event a user changes to their password which is super cool. And there is also in the URLs one small change. There is a line missing. It's admin.autodiscover. It's gone. Now admin is still enabled by default but this is major foreshadowing for the new app framework. So come back to it. Now at this point in our 1.6 framework it's Django 1.6 project. We normally the best practice would to run syncDB right now. So just as a heads up when you're doing this in 1.6 if you're following along run syncDB now. I'll say it again. At this point you can create the app in both Django 1.6 and 1.7 and it's exactly the same with the exception that in 1.7 you automatically get the migrations package. It's in bold. Now we can go about creating a night app. So there's a little trick here which is that this would be fine. It's a night model. Not night model. And it's very straightforward. We have a name and then we have the string representation for Python 3. This is Python 3. The problem is that doing this in south we're doing it with south 1.0 which actually introduced a regression so that you can't actually currently run in Python 3. So our Django 1.6 is going to run in Python 2 and our Django 1.7 is going to run in Python 3 and so we have to do a little bit of shenanigans to get it to be running in both. The future import Unicode literals makes sure that everything runs in Unicode. Native strings are now Unicode and then we have a decorator which is super cool because the string representation in Python 3 is stir but in Python 2 it's Unicode. That decorator ensures that it works in both. About the bug in south 1.0 there is already a bug fix for it. It's just simply not released and this seemed like fun. So now that we have a project, we have an app and we have a model, we can go directly into migrations. So the history of migrations you heard a lot about this morning just to recap Andrew Godwin created south in 2008. It quickly became the de facto tool for schema and data migrations and in 2012 Andrew began asking around about the API for south 2 or else migrations in Django. He kick started in March of 2013 and he had initially set a goal. He was very modest about this this morning. He initially set a goal for 2500 pounds which was met in just over an hour. The stretch goals which had a maximum of 7000 followed like several days later and they continued to 7952 pounds which at the time in dollars was 27,397. That's a lot of money for this and it's actually a really good thing to happen because migrations are cool. What is a migration? So I'm sure there's some people in here who maybe have avoided south, you have little projects, you haven't had to use it and the way to think about migrations if you haven't seen them before is version control for your database schema. It's not a perfect analogy. You know there's all sorts of problems with that analogy especially because you're putting your version control in a version control, oh that's going to get ugly. But the bottom line is that it helps it so that you don't have to make manual changes on your database when you make changes to your models right? Super helpful and the workflow here is that you are going to make a change in your model, you are then going to create a migrations file some way we'll see and then you are going to migrate or alter your database using the instructions in your migration file. So we sort of did all of that in 1.6 and 1.7 so now we are going to focus on just 1.6 right? So again we created a project, we added south to settings.py, we then called syncdb and then we created the app right? So we already have a database at this point but everything else should be fairly straightforward. So at which point we call schema migration initial we tell it just the first one and it goes ahead and says oh hey yeah let me just go and look at your models and create a migration file. That migration file looks like this right? There is a class and there are four things to it. We are really only interested in those first three. The forwards method, the backwards method and the models which are referred to as frozen models. So the forwards method is just what gets called when you tell it to change your database right? You can see it's just creating a new night table there is no magic here. The backwards is the opposite right? It's totally symmetric to forwards and so it just deletes the night model. So the weird one so that's fairly straightforward. The weird one is models right? It's referred to as the frozen model and it's not immediately apparent what it does because it's just kind of sitting there and we'll come back to it. Once we have our migrations we can just say hey please apply this and it goes ahead and does just that. You'll notice that last line installed zero objects from zero fixtures. Well that's super helpful. You know we'd gotten King Arthur who'd said well it'd be really nice if they could download this from the Git repo and immediately know who all the nights are. Well so we can use this initial data system with fixtures to go about ahead doing that. So we are going to pop into the Django shell. We're going to create a whole bunch of nights. We make sure that they're there and then to make sure that everyone has them we're just going to use the dump data function. We're going to slam it down into a JSON file and we call it initial data. Django already knows to look for that and so if we roll back our database and the reason we can do that again is because of backwards right it's just going to delete it and then roll it forward you can see that it's installed those seven objects which means that if we include that with our project everyone will have the list of nights that's great King Arthur's happy until Lancelot. Damn it Lancelot. Okay so King Arthur shows up and he goes well I need a new field and I need you to deal with Lancelot in the database and so you go short no problem. So you add the field and then you say hey I want you to automatically figure out what I've changed in my models and south goes yeah no problem and what it's doing is that because it can't rely on the content in the database right it doesn't actually know what's in there can't trust what's in there what it does is it looks at what's in the models and it looks at the frozen models and it does a difference between the two to figure out what's new and so now you know the purpose of the frozen model. So it will use this to automatically generate this. Now I intentionally left an error over here which I forgot to mention when I brought it up the Boolean field should have a default as of 1.6 you need to have a default equals false only leaving it out right so fast forward. So when we call round table auto south tells us that it doesn't know how to fill it in but it doesn't tell us it's a problem right. So what I've done is I've simply said oh well by default no one's a trader right false at which point we can not migrate the round table and you think everything's going to work just fine and you're wrong right what happens is Django pukes data at you to be grass about it. It's just going to start really really complaining and what's happened is you've tried to load the JSON and it doesn't know what to do with the trader field right the initial data doesn't have it and so Django just freaks out which is good that's what you want it to happen any sort of implicit behavior there could be really really dangerous but that means that our initial data problem the initial data system is a problem when used in tandem with migrations so let's step back we're going to get rid of the first migration file that we just created we're going to delete the trader field and we're going to deal with this problem first let's roll back the database that's that first command we're going to move the initial data so Django doesn't look for it automatically I'm going to give it a funny name we'll see why in a moment and then we're going to reapply that first migration so that we have the structure of the night model in our database but not any data in there right and you can see that at the bottom it says installed zero objects from zero fixtures at this point we want something like the initial data system but we don't want the initial data system so we're going to go ahead and create a data migration and the data migration is simply a migration frozen model in all except that the forwards and the backwards are not implemented right you are expected to write these functions and this is where it gets really cool right because you can rely on the fixture system right not the initial data system you can rely on the fixture system and just call it directly and say hey I want you to use that JSON file that we still have and that's in fact why I named it that so that you can help figure it out the thing is this is pretty silly right you've got two files basically to generate data in your database and you can do it all in one now you can see that that doesn't look quite the way it should and you'll notice that there's an ORM before the night the thing when doing a migration is that you don't know if the models in your database are what you want right so South will create the historical model and we'll put that in the ORM so that you can then use that to actively and correctly give it what it expects so that's why there's an ORM and that's a big thing about the new migrations as well which we'll see just in a moment so now we roll back the database again we bring it all the way back up we see our initial schema is now applied and we see that our initial data is also initial data the data generation process is also applied and so we have everything that we want now we also want to program our backwards because we're good developers and we want this to be symmetric right and so that's very easy we use ORM and night again and we just say well delete everything in the database everything we just added just remove it fantastic what this means of course is that we can actually roll back right we were in 002 and we're now going to 001 and at this point you know if we go into the shell and we ask for all the nights they've been removed right so this is this is really cool because you can move backwards and forwards in the migrations either adding data or removing data and this is the safe way to do it. At this point now that we have the data we want in our database correctly without any reliance on the initial data system we can go back and add our trade room field still wrong on purpose we get exactly the same output as last time when we try and automatically generate it so we're going to again say it's false everything is default false and then we migrate and everything works just great right and that's what you want right so at this point we have the new trader field in there but the problem is that if you go into your shell and you ask if Lancelot is a trader which is really the original point here it says false and that I'm happy with that so you go ahead and you create another data migration you then fill in forwards yet again where you simply say you know or M Knight find Lancelot set him to trader and you remember to save and the backwards right again because we want this to be as symmetric as possible the only difference is that we're now setting it to false so if we migrate all the way up with our fourth migration Lancelot is now a trader and Arthur's happy now let's do it all again so I'm sure you guys are excited so again in 1.7 we didn't need any of those beginning shenanigans right you just start the project you get into the project you create an app and then you can immediately go straight to programming your models you don't need to worry about think DB it's far away from your mind so this is exactly the same model as we had before but just with the name right the trader is gone we're at the very beginning of this project and we can go ahead and instead of schema migrations we're going to call make migrations the outputs really really pretty you can't see it on this screen because I couldn't get the the color coding to work but in my bash terminal it's it's color coded it's gorgeous so at which point it will create this guy this is totally different right there were four things in the last data in the last migration for south and in this one there are only two dependencies is at this point an empty list right so if you heard Andrew Galtwin talks you know what's coming on that front but what we really care about are operations and the operations currently looks like this and you can see what it's doing is it's creating a model right it knows that it's going to create this in the database you'll notice there's no backwards right operations is strictly forwards what's super cool about the new migrations is that they figure out automatically what the symmetric opposite is I don't think that's probably the right mathematical term there sorry now with that migration automatically figured out we can call migrate at which point it will migrate everything that we need including on the second to last line our round table app at which point it should come as no surprise that initial data no longer works right it's been deprecated in Django 1.7 because it doesn't play well with migrations and so at that point we are forced to use data migrations right and that's super easy except instead of asking for data migrations we're simply going to ask for an empty migration file so we go ahead and do that and that name is horrible that is so unhelpful so I don't know if this is standard practice because I don't think it's been around long enough for there to be a standard practice but I've been renaming these because that's the time and date that's supposed to be created and that's not interesting it doesn't tell me anything so I'm renaming it to add night data at which point we need to fill this in so as Andrew mentioned this morning there is a really helpful command called run python which takes essentially two things the forwards method and the backwards method so it's very similar to south right it's what do we do going forward and what do we do going backwards and so here what we're going to do forward is add night data and when we go backwards we're going to remove the night data the second one is actually optional you need to put in a reverse code keyword and then just like with south we could rely on the fixtures right the initial data system is gone but the fixtures aren't right fixtures still work just fine if you want them and need them and there's still projects that are going to make really good use of them like classy class-based views makes it has a really good example for how to use fixtures so we could do this but again this is pretty silly because you now have two files for one thing and so I advocate with absolutely no basis the act of doing this now this is slightly different apps.getModelRoundTableNight it's the new app loader but we're not getting it from Django directly you'll notice it's being passed into add night data which gets an apps and a schema editor so Andrew talk this morning about the schema editor it's basically what does the actual database altering manipulation but the apps is the historical model right it is not what is currently in your models it's what the new data migration or the new migration system expects there to be in the model and that's actually really important so when you do this you want to make sure that you're pulling from apps otherwise things are going to go completely bananas so we then go ahead and create everything as we would expect and again once again because we're dedicated to being symmetric and good programmers we go ahead and do remove night data and again you can see me using the new app loader and just deleting all of them and we get to relive Lancelot's betrayal at this point so we add the trader field and you'll notice again I'm intentionally making an error now here's the thing before we look at migrations let's step to the side we avoided manage.py validate but let's run check ooh it knows there's a problem it warns us there's a problem and in fact it will tell you where in the docs to look to figure out how to fix that that's really cool but what if you forget to run check well Django's got you covered because when you run make migrations it'll run check for you and it'll yell at you right giving you all of the same information which I've really removed from the slide so you can see the rest of that it outputs which is as saying exactly like south what do you want me to fill in right so it's going to warn you but it's then also going to say hey we can keep going forward and you could you could just say oh well you know the default is false and just kind of keep going if you hadn't listened to check so far it's going to keep yelling at you right when you migrate it's going to say hey you really really really don't want to be doing this so the bottom line is that Django will let you shoot yourself in the foot don't right don't shoot yourself in the foot when Django check warns you that there's a problem there's a problem so do pay attention to the output of these commands right don't just gloss over them because they're now incredibly helpful right so of course we're going to pretend that we didn't have make migrations and then we're going to add the default false we will then go and run make migrations we will get a correct make migration and we will then migrate that and we end up with the same problem as before where yes we now have a trader field in our database but Lancelot is still not labeled as a trader so we once again make an empty migration file instead of data migration and we can rename it I think again not clear on that and we can then invoke run python as the operator and we will program set Lancelot status to go forwards and unset Lancelot status to go backwards so the set Lancelot whoops that should read set Lancelot trader and unset Lancelot trader so that's set Lancelot trader and again we're using the new app loader and we set it to true and the unset is exactly the same thing with the app loader and all of that except that we set it to false at which point we can migrate this new data migration at which point Lancelot is now a filthy dirty trader wow okay that was a lot of content real quick where am I going with this right what's the point let's review what we just saw right the three big features so the first were migrations right this is the big thing it's what to take away and hopefully you're a little less frightened right it's there to help you it's super easy and so you want to like really take some time oh do I not have an hour oh okay whoopsies okay there we go so the initial data system is deprecated right that should come as no surprise given our last example the features still work though however right the two are related but not the same and the frozen model is gone this slide is shamelessly stolen from Andrew Godwin because he used it in his last four or five presentations and it shows you why the frozen ORM is gone right it takes up a lot of space and one of the big features of Django 1.7's migrations is that you're supposed to be able to edit them right those files were very small and we went directly into them and we had no problem building around right because they're very straightforward so the historical model right uses the app loader to build it directly in memory and keep it there and that helps see the utility of the dependencies right every migration has a set of dependencies which then uses the app loader to build this historical model for which it gets to act on there's an important caveat which is that when you are using these the methods you define on your actual models will not get used so you have to be very careful so if you've overwritten save and you try and use it in the historical models in a data migration it will not work it's just going to call the default there's also currently a bug in 1.7 or I don't know if I call it a bug it's a problem where if you have tons and tons and tons of models it's going to out it's just going to take absolutely forever there's currently a bug that being there's a it's on the tracker and they're looking at 1.7.1 to try and fix that problem but the key takeaway migrations in 1.7 have exactly the same workflow as the migration as south migrations right you change a model you create a migration file and you apply the migration and and that's really cool because if you've used them before in south there's no real overhead here right so about south in 1.7 south does not work in 1.7 right if you're in 1.6 you're using south migrations if you're in 1.7 you're using native migrations you can't sort of over swap the two or overlap the two rather if you're going to upgrade from south the instructions are in the docs and they're kind of hysterical because it says bring it up to the latest migration create a new native migration delete south you can just get rid of them so because it's not to use south it knows the difference and so does south as a version 1.0 but just in case you want to keep them around there are two settings both for Django and for south so that you can help avoid any sort of namespace conflicts if you need it you probably won't now if you don't want migrations at all I don't know why you wouldn't want migrations at all don't follow this advice at all right like don't get rid of them but you can and then you know I'm not sure why you would do this that leaves us with the app loader so prior to 1.7 it was called the app cache and Andrew Godwin on his blog referred to it as the Borg because it shares a state across every single instance of it it's totally incompatible with migrations because migrations needs those historical models to act on right so it was one of the first things to go given migrations was going to come up and it led to the new app registry basically this has been coming for since 2007 it's been worked on by a ton of people but basically I am under the impression that migrations is what finally pushed it over the edge when in May of 2013 Andrew Godwin began to change it so that migrations would work Emery Augustin in December of 2013 picked it up took all of the work that had been done reduced it to seven items and then focused on three it's on the developer the Google developer mailing list it's a good read I really recommend it finally there was the systems check the system check I really think I have no basis for this then it has to do with the 1.5 upgrade where we had problems with use TZ allowed host and secret key this is going to seriously help anyone do any upgrade avoid any kind of pitfall all of that the work for 1.7 was done by Christopher Madrella and overseen by Russell Keith McGee and basically they took the validate check which was a little confusing and analytic and turn brought it out into a whole bunch of different pieces what that means is that you can now actually use the check right this is from the documentation you can actually invoke it directly so that you're performing checks on your own stuff please do there are a couple other changes I just want to talk about there's the query set you can now set as a manager so you only have to define the query set rather than overloading both the query set and the manager and there's a pre-fetch object to help with pre-fetch related there's a talk tomorrow at 10.30 a.m. in ballroom 1 with Christopher Adams about learning to optimize Django with pre-fetch related I think it's unfair to expect any sort of coverage about the new pre-fetch object but it'll really help you get to the place where you might understand the object better I really would like to tell you that preparing to upgrade involves nothing I'd be lying the process however is fairly straightforward you look at your dependencies and you figure out what you need to upgrade well if you're on 2.6 you don't want to be on 2.6 anymore you want to go straight to 2.7 third-party apps are they still supported are they still working for you are they helpful are you on the latest version is there a version for the next one you then take the release notes for the version you're upgrading to and you just go through it it's a tedious process but it is the safest way to go about this because you hit everything right at which point you run your test suite if you don't have a test suite please buy Harry Percival's book it's a really good read no it's a fantastic read and it'll be super helpful please have a test suite it will be so helpful now again this is a tedious process but it's not the worst thing right everyone says it's the worst thing but please take the time to do it and in fact schedule it right one of the big things is that you really need to think about this this is now you know there is a release schedule you should expect this to happen upgrade early upgrade often if you have a lot of little upgrades to do it's way better than having to do 1.1 all the way to 1.7 you should not be running 1.1 right at the very least you should be at 1.4 and you can start upgrading at the release candidate right once the release candidate out they're saying it's mostly good enough and that way you can actually help the Django project by providing bug fixes if it isn't working for you the final thing is that I think people look at this wrong right they say oh we have to like schedule all this time to get upgraded no you have to invest 2 weeks a month to get hundreds of hours of really good work from hundreds of other developers and people really need to start looking at it like that it's a major investment yes but the return on it is enormous and it's getting a little scary so this is what so this is how long the each version was the principle version right so 1.6 had 1.7 made the May 15th release date would have only been around for 190 days and you can see that that curve is pretty terrifying now they didn't make that right this is what the actual was and that's a little bit more reasonable but you can still see a trend where they're trying to have shorter releases so it's going to be increasingly important that you stay up to date right so let's review some practical knowledge Django 1.7 means the death of 1.5 get off 1.5 it's not on LTS support it's gone and if you're on 1.4 and saying oh well we can sort of stick around well remember that it might be over in March of 2015 that's not all that long right they might decide to extend it but there's no guarantee so really consider an upgrade up to 1.6 now why not 1.7 1.7 depending on what you need might have a few kinks to work out which might which look like they're all going to be sorted out in 1.7.1 if you can get to 1.7 please do right but if you have an enormous project with the models that are completely nuts take it slow right finally so we've talked about iterating through each version so that you can do the release process this will help with gotchas one of them is that the passwords the password URLs in 1.5 or base 36 when you go to 1.6 it's base 64 but 1.6 knows this it catches it so if you do 1.5 directly to 1.7 you're going to catch it and that's going to be a problem so you do want to really take your time going through each version sing DB is dead long live migrate initial data fixtures are dead long live data migrations and remember that when you're dealing with all this the fields need deconstruct it's also important to look ahead to the future I realize I'm straining on time here I'm sorry there is a deprecation release document on the Django website it will tell you things like oh you're all configurations are going to change in 1.8 there will be no patterns it's just going to be a list of calls to URL you will need to use direct imports knowing that can help get your code right before it's even released so it's a really good idea to look at that I'd like to thank the developers who documented all of their changes and wrote a fantastic email Russell wrote a fantastic set of emails about the changes he documented all of his stuff on his blog it's been a joy to read and I really hope that the talk about the dps like the python enhancement proposals but for Django come along because that documentation I think would be even better questions do we have time