15 ms·

Django 1.7 Released

• japhyr 12y ago
  I'm looking forward to the Django Dash, and hope to make time to put together a small project using 1.7. I can't wait to try out the integrated migrations. Thank you to everyone involved in getting this release out the door!
• jMyles 12y ago
  It was cool to be at djangocon while this was announced in the hallway track.
  • techdragon 12y ago
    Best part of conferences is those wonderful unplanned moments. How's the mood in the hallways there?
• deleted 12y ago
  [deleted]
• themartorana 12y ago
  I can't say how much I love Django. Back in the day when it was first coming out, I was coming out of the Microsoft/ASP.NET world and was being introduced to the wonder of Rails. But a small project I had contributed some mind-share to had been rebuilt in Django. When I asked which I should learn, Rails or Django, a wise developer friend advised I play with Ruby and Python. Figure out which language spoke to me, and use the best framework available. I chose python, and despite the niceties of Rails, found Django an absolute pleasure. Add in a sprinkle of Johnny-cache, Jinja2, and South (because you could in Django) and it was a powerhouse. I haven't written any Django code in a couple years now - my work is now mostly backend/API code for which Flask was much lighter weight (and Go is mostly replacing), but all my Django sites are still running. Congrats to the team on continuing to push forward a brilliant framework, the best documentation in the business, finally getting DB migrations in the core, and more and more and more. And by the way, thanks - I owe a bit (lot) of my success to everyone who contributed to Django and the larger community. I hope my meager contributions a few years back were at least a bit of repayment on a much larger bill.
  • lumpypua 12y ago
    Any suggestions on packages you're using for your Go toolchain? I'm a django developer that's somewhat fed up with python's slowness. I love django but I'm looking to diversify. I've worked through a bunch of Go tutorials, but I don't have a good feel at all for the go ecosystem.
    • aaron-lebo 12y ago
      I've also done a lot of Django hacking and have the same feelings about Python. You aren't going to find anything as complete as Django in Go. There just hasn't been enough consolidation on a single framework and things are too much in flux. I never found an ORM I liked, but pongo2 [1] is directly modeled after Django's templating language. There's also negroni [2] and its ecosystem. Gorilla [3] is an excellent set of packages as well. It all feels a lot like using a less mature Flask (mainly because Armin Ronacher has put years of work into it). As much as I want a speedup from Python (as well as good concurrency) I'm finding Python is still a lot more expressive and takes less code. Your mileage may vary. I suspect what Go would be really useful for is a JSON API that a Flask app (or something similar) consumes. 1. https://github.com/flosch/pongo2 https://github.com/flosch/pongo2 2. https://github.com/codegangsta/negroni https://github.com/codegangsta/negroni 3. http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/
      • themartorana 12y ago
        These are good, and seconded on the maturity front. I'm a fan of goji and more recently have been using Gin [0]. For databases I'm playing with sqlx [1] and modl [2] from Jason Moiron (because they're based on gorp, and because he wrote Johnny-cache for Django which is amazing and I use on every Django project I work on.) Gin is young, but has great potential and I'm already using it in production (with a keen understanding of its current shortcomings). [0] http://gin-gonic.github.io/gin/ http://gin-gonic.github.io/gin/ [1] https://github.com/jmoiron/sqlx https://github.com/jmoiron/sqlx [2] https://github.com/jmoiron/modl https://github.com/jmoiron/modl
    • victorhooi 12y ago
• misiti3780 12y ago
  Super excited about having migrations built into Django finally! Great work to everyone involved, and thanks for making an amazing product that makes going to work fun
• kyllo 12y ago
  Good news, this means South now comes with Django by default. I use South in every new Django project anyway, because database migration versioning is so necessary.
  • stefantalpalaru 12y ago
    It's a backwards incompatible South successor: https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-from-south https://docs.djangoproject.com/en/1.7/topics/migrations/#upg... The upgrade path is to delete all your old migrations and create a new initial one.
    • huxley 12y ago
      Andrew is providing some additions in South 1.0 to ease the transition a bit, probably not to the degree he had hoped earlier in the process: http://south.readthedocs.org/en/latest/releasenotes/1.0.html http://south.readthedocs.org/en/latest/releasenotes/1.0.html "As part of providing a migration path for authors of third-party apps and libraries for Django, South will now first look for migrations in the south_migrations directory, and then fall back to the migrations directory if this is not found. This is intended to alleviate the namespace clash between South and Django migrations; prior to this, both were looking for a directory called migrations, and so it was impossible to ship a third-party app with support for both South and Django 1.7. The recommendation is that you move your South migrations into the south_migrations directory (existing users will not notice the change if they upgrade South first), and then start a new set of Django 1.7 migrations in a migrations directory (the default)."
      • zentrus 12y ago
        Thank you. This is closer to a much better upgrade path. The official documentation is really not a good way to have non-technical customers move from South to Django 1.7. With the new version of South, you could package both old South (perhaps some of them not yet run) as well as the new migrations. It could be better though. With this approach, they would still have to: 1) ./manage.py migrate 2) pip uninstall south 3) ./manage.py migrate Better yet would be to have either South or Django 1.7 migrations check for the other's existence and run both sets of migrations and not force South to be removed. This would make it a truly seamless transition for the system administrator.
• tbarbugli 12y ago
  cool, now we only need to wait another 5 years and we will see celery integrated in Django :)
  • collyw 12y ago
    Celery is an overcomplicated mess with too many moving parts in my experience. Django on the other hand works well and doesn't overcomplicate things.
    • deleted 12y ago
      [deleted]
  • amirmansour 12y ago
    Migrations are something almost every app is going to need, and the same can't be said for a distributed task queue. So it wouldn't make sense to add Celery to the Django core.
• icn2 12y ago
  I haven't followed django for a while. Could someone explain a bit more about django' model association part. Is it currently comparable to rails's model associations? Looking at these two pages http://guides.rubyonrails.org/association_basics.html http://guides.rubyonrails.org/association_basics.html https://docs.djangoproject.com/en/dev/ref/models/relations/ https://docs.djangoproject.com/en/dev/ref/models/relations/ It seems there are a bit more on rails model associations.
  • ubernostrum 12y ago
    You want this page: https://docs.djangoproject.com/en/1.7/ref/models/fields/#module-django.db.models.fields.related https://docs.djangoproject.com/en/1.7/ref/models/fields/#mod... In general: Django's ForeignKey is equivalent to Rails' belongs_to. Django's OneToOneField is equivalent to Rails' has_one. Django's ManyToManyField is equivalent to Rails' has_and_belongs_to_many. Also, in Django one generally only declares the relationship from one "side", unlike Rails where the relationship is declared on both "sides" (i.e., in Django one simply sets up a ForeignKey on A pointing to B, rather than placing relationship identifiers on both A and B). The equivalent of ":through" is also available. Django has GenericForeignKey as an equivalent to Rails' polymorphic associations.
    • jsmeaton 12y ago
      Just to clarify a little: > Also, in Django one generally only declares the relationship from one "side", unlike Rails where the relationship is declared on both "sides" (i.e., in Django one simply sets up a ForeignKey on A pointing to B, rather than placing relationship identifiers on both A and B). That's because django will automatically add the reverse of the relation to B, so that you can access A through B. You can disable that functionality optionally though.
  • manojlds 12y ago
    Isn't Rails getting real foreign keys only in yet to release 4.2?
    • 12y ago
• shijie 12y ago
  Very much looking forward to using 1.7! Question for all: Would now be a good time to move to Python 3.x? Our current Django installations are all running 2.7, and we are thinking about switching just for better unicode support alone. I'd love to hear some of your thoughts on this.
  • Walkman 12y ago
    If your database backend is not MySQL, then I would say yes. For MySQL you need to think about which database adapter you choose. You can search for earlier topics in HN about the topic, but the state of Python 3 is not bad at all!
  • mstrcnvs 12y ago
    Django fully supports Python 3 from version 1.5. If you can use it or not depends more on the other packages you might have installed like DB adapters, image processing, etc. https://caniusepython3.com https://caniusepython3.com is a good way to know, you just need to drop your requirements.txt and it will tell you!
    • jsmeaton 12y ago
      Further, if you find a dependency that isn't supported, you should check the projects site to see if support is on the road map. You could also try contributing the python 3 upgrade to that package. I recently began a new site based on django 1.7 (RC) and python 3.3, and only a single package I needed wasn't available. Someone had already opened a PR for py3 support though, so some gentle prodding got it merged within a week.
  • techdragon 12y ago
    As others are mentioning, there are places you can check general python3 support. But more specifically, if you want to check your django python3 support, you should have a good browse around http://www.djangopackages.com http://www.djangopackages.com
  • yuvadam 12y ago
    I recently started a new Django 1.7 (beta/RC until now) + Py3 project, and it's going great. All the major dependencies work flawlessly on Py3. I did have some problems with some minor API wrapper libraries, but those can easily be patched or other written to support the needed functionality. Regarding a full-on migration, I haven't done that yet on any of my larger existing projects. As with any migration I'd be careful to weigh the cost/benefit of such a move. But, at least from my experience in this field, Py3 is definitely ready for prime time. Use it!
• rectangletangle 12y ago
  Nice, cleaning up the whole model-manager and queryset redundancy makes it much more DRY.
  • erichurkman 12y ago
    I'm definitely looking forward to deleting a fair amount of boilerplate code that made this work in < 1.7.
    • rectangletangle 12y ago
      Same, Django's whole queryset API is really nice, but it's even nicer to compose it with application specific methods. It's nice to be able to centralize most queries to a single place in the code base, it's easier to test, write, and read, and modify.
• smegel 12y ago
  Now if Hue would get off Django 1.2(?)...
• VuongN 12y ago
  I have to say that I've been a big Django user and have been using 1.7.x for a bit in my own development. There are a couple of "oddities" for me that perhaps folks will encounter: 1. If you do heavy TDD, you might not like that fact that you can't skip migrations the same way you previously could with SOUTH_TESTS_MIGRATE = False. There's a thread going on (https://groups.google.com/forum/#!topic/django-developers/PWPj3etj3-U https://groups.google.com/forum/#!topic/django-developers/PW...). It appears that with syncdb going away, there isn't an option available. I really hope there's a way to retain syncdb for unittest because I don't need to test database migration every time I run my quick unittests. 2. I think 'makemigrations' is a bit inconsistent at the moment. Sometimes it creates more than 1 initial files, sometimes it creates just 1 (if you run 'makemigrations app-name' instead of 'makemigrations') There are a couple of other general Django issues, but those are the things I encountered while working with 1.7.x.
  • jsmeaton 12y ago
    1. I think I'd like to see something like `./manage.py migrate --fresh`, which would forget about existing migrations, create a set in memory, and apply them. Pretty much emulating syncdb on a fresh database. Then the test runner could use that behaviour optionally (otherwise, RunPython statements may be missed that are required). 2. It may create more than 1 migration file if there are specific ordered dependencies afaik.
    • VuongN 12y ago
      Using its best guess with dependency, it creates the appropriate migration file(s) favoring more files over potential conflicts. I think that's fine. The problem is consistency. However you choose to run the makemigrations, it should at least result in the same amount of files. It can't be more or less conflict if nothing is changed.
    • ProblemFactory 12y ago
      Does migration squashing do what you are looking for: https://docs.djangoproject.com/en/dev/topics/migrations/#squashing-migrations https://docs.djangoproject.com/en/dev/topics/migrations/#squ... ? After squashing and migrating all existing databases, you can delete the old migrations files. The squashed migration becomes the new fresh migration that should usually contain just "CREATE TABLE" statements to be run on an empty database.
• zentrus 12y ago
  Awesome that migrations are now in Django core. I do see some pitfalls regarding Historical Models though. The problem is that application code usually changes over time. Consider a deployment that hasn't been migrated in a long time. When migrations are eventually run, the older migrations might assume application code behaved a certain way. This is why you should never use your regular application models in migrations. Both South and Django 1.7 migrations copy "shallow" versions of your models (no custom methods, save methods, etc), which helps to encourage developers to keep the migration isolated from application models that might change. The problem with Django 1.7 though is that these shallow versions retain any inheritance they had at the time the migration was written. So if that class goes away in the future, I presume the migration will break. Worse yet, if the base class behavior changes, the migration run later in time might behave differently than you intended. For this reason, custom methods even from inheritance should not be saved in the historical model. Only the fields should be saved off from the base classes, and then merged into one class (remove any inherited classes). Any other app code needed for the migration should be directly copied into the migration itself.
  • andrewingram 12y ago
    I'm assuming that most of the pitfalls I wrote about a couple of years ago are still applicable today, with either South or Django's own migrations: http://andrewingram.net/2012/dec/common-pitfalls-django-south/ http://andrewingram.net/2012/dec/common-pitfalls-django-sout...
    • zentrus 12y ago
      That's a good set of pitfalls to watch out for. Mainly, I just find it odd that in Django 1.7, they are using frozen models to mitigate some of these problems, but don't remove or freeze the base classes, therefore leaving the same problem. I'm sure the migrations system will get better over time.
• nospecinterests 12y ago
  I am soo happy about this release I think my neighbors dog just went wee on their floor!
• jorgeer 12y ago
  Hallelujah!
• chhantyal 12y ago
  Time to start new project with it. I am thinking about Python 3 now :)
  • AndresRoot 12y ago
    Me too :)
• ldng 12y ago
  Exciting release ! Could have been 2.0 to me with new migration system and specially with the App loading revamp. Is it me or AppConfig.ready() looks like a great place to put signals setup ?
  • teilo 12y ago
    .ready() is where you put pretty much all app setup. There was never a good place to do this before. The app refactor is the single biggest improvement to Django in years. Bigger than CBVs, IMO.
• Demiurge 12y ago
  I really wish Django default doc site would default to latest production version in urls. I have to keep changing dev to 1.6 and now 1.7
  • mstrcnvs 12y ago
    You have a good point. This would also prevent beginners from reading dev docs and accidentally trying to use features that are not yet available. I've seen this a lot.
  • jsmeaton 12y ago
    If you open a bug in Trac the core team may be open to changing the default behaviour. https://code.djangoproject.com/ https://code.djangoproject.com/
• AndresRoot 12y ago
  Starting a new project with Django 1.7 and Python 3 :D