Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
alright sorry about the delay the next talk is by Andrew Godwin he's one of the core Python developers and he's going to be talking about designing Django's migrations please give him a hand hello everyone Oh fell out hello everyone I'm Andrew
as you've just been introduced and this clicker is stopped working here we go and so as previously mentioned I'm a django core developer but I'm also the author of South the popular Django migrations library I'm thank you and I've been
doing this for what now feels like an age was actually only seven years and South is seven years old I think in September of this year and so throughout all of those many years I've always thought migrations they're pretty good they've proven themselves
useful South has been very very popular more popular than I would ever have imagined to start out with and you know it's fantastic I've had people come to me saying then they know they're writing antigens in PHP but they still use Django and south
of migrations with no it's just that good a solution so that's kind of reassuring for me but sort of underlying this whole thing for last seven years for me is when that South is it was good it was good for its time it had a couple of bad design decisions
initially done Anna this is seven years ago I was a much more novice programmer back then and that's understandable but as the years have gone by as we've got feedback for community for my users I've realized that actually there are some core underlying
problems in South not only is it sort of got these slight idiosyncrasies its design but it also is it lives next Django it's sort of a third party library it's not integrated well into cause it should be there's a module called South taught hacks
that is there purely to be that integration into Django it's called hacks for a reason it's very obvious like no sign that this is the bad part of the code it's full of horrible changes to install the apps the settings at runtime it fills with
the RM and the app cache and that's just not good and so about two or three years ago me and some other cool developers started formulating an initial plan for this the idea was that we take south and we take the sort of abstraction backends part of it
the bit that takes your database and turns it into a nice easy layer that you can use and take that and put that into Django itself a sort of a schema abstraction back-end kind of thing and at the same time we put in there some RM hooks that would get rid
of that hacks module and South things like be able to change your models at runtime being able to sort of load and unload versions of models into the RM without having to fiddle with all the settings this all seemed fine I sort of aside that the same time
the plan was that we would have south to and south to would be this sort of rerun of South with a different format better user interface but using this underlying Django library now that was a sort of good start the idea but when you look at it overall South
is one of those libraries that is one of the very few things in Django everyone seems to use it's almost a unanimous thing that everyone prefers even migrations and one of Jango's be problems historically is that it for a new user especially it can
be very hard to decide what library to use for BOTS like you know if we're going for API is to use rest framework to use piston usual have many other ones and so on for every other kind of thing and so there is some value to having a blessed option or
a preferred options this stuff and in fact we went one further the revised plan was that what we would have is migrations built into Django itself you know it's such a fundamental part of the way you write web applications and for new users you need to
bring them and introduce them to it early on and so it is felt that actually it makes a lot of sense as a core part of Django it's a very underlying crucial part of the way we build up web applications and so that's all well and good but the same time
these are still logically separate items I've kept that separation between the schema abstraction back end and the migration sort of front end user interface built into Django itself so even when 1.7 is released and you start using this you'll be using
to abstractions talking to each other and that means that if you want to write your own version of a migrations library if you want to change the database at run time for some kind of mad crazy reason or you have other reasons to sort of change in alter the
schema that back end is there for you already it's with a good API it's well defined and you can step down and use it straight away and I cover both of those in second but I first want to cover the key thing here that I am not moving south into Django
I am adding migrations into Django this is a complete rewrite of the South code they are somewhat similar in sort of ideas and logic but a lot of the code has been rewritten the migration file formats very different the user interface and commands are very
different and so it is not the South you know directly but it bears a lot of sort of external similarities to it especially the way it organizes and runs migrations the kind that's that schemer editor interface the schemer editor is this part of the database
backends that abstracts the schema operations over databases in the same way the ORM abstracts things like select update and delete over databases the schema editor ball abstract things like create table drop table create index drop index and things like that
[ ... ]
Nota: se han omitido las otras 2.855 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.