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.
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.
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.
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).
Yeah, the current web frameworks on Golang seem to be quite...chaotic to an outsider. And the landscape is constantly changing.
It's not like Ruby or Python, which seem to have one clear mature do-everything framework, and some more lightweight ones beneath.
Is there such a thing as a Django-equivalent in Golang at this point in time? Or what's the closest analogue? None of them seem to package an ORM together, so not sure what people tend to do here, to reduce boilerplate code in their models.
Part of the issue there is that Golang doesn't have any mature ORM-type packages. The one I've heard the most about is [Gorp](https://github.com/coopernurse/gorp), but none of the current Golang web libraries really sanction anything- but that's part of Go's nature. Go by default doesn't encourage big frameworks. It encourages you to use the rather well-built standard libraries to get most things done, and do the rest of the augmentation yourself.
However, as it's being looked at more and more as a great systems language, people are building bigger, more frameworky systems in it all the time, and as a result it's getting friendlier. It's going to be chaotic no matter what for the next year, but that's how new languages, especially popular ones, are. If you're looking for easy choices, it might be better to wait for now. If you want to get your hands dirty, I guarantee you'll find something you want if you keep looking, or you'll get good enough to run with it yourself.
(Just be sure you know your web basics to do webdev on it, as no one is going to hold your hand in Goland.)
For many years in python there were several contenders for webframeworks. Only after many years did Django eventually dominant.
I've used Django a lot and personally I would prefer smaller lightweight frameworks where its easier to select packages that provide solutions to specific problems. I'm not looking for the next Django. Something the size of Express would be perfect.
I love Django for its docs and sensible defaults to just about everything. I've been reading the Light Weight Django book, now nearing completion at O'Reilly, and Django can be used as lightly as Express. I'd link to source example, but I can't find the code anywhere and the ebook is not on this device...
I don't know if it's lighter than regular Django in terms of speed, but by the measure of how much you need to code you can't do much better. Couple of pain points are declaring settings for middleware and template processors, even when you don't really need them, but other than that it is really basic. This is your URL pattern, this is your view function to call when a request comes for such URL. From there you can do what you want with the request, as long as you convert your response to Django's HttpResponse object (which takes a string).
It looks to have some genuine useful parts from Zope, rethought for today's more RESTful, Javascripted world. My next personal project will probably use it as a base.
Haven't gotten into Django yet; previously worked with Rails and fell into its welcoming embrace and now playing around with PHP5+. But it's exciting to see new releases to powerhouse frameworks, and I hope to really get into to it one day! Thanks for the glowing review. :)
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/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.
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.
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.
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.
Not sure if it solves your problem, but in the dev version of Django you can use the `--keepdb` flag to `manage.py test`. This will preserve your test database after the test run, and only run any new migrations. It gives a real speed boost.
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.
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.
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!
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.
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.
> 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.
Not using proper foreign keys doesn't mean you can't have associations, it just means that the database won't enforce their integrity. (If you wanted that enforcement in rails, the traditional solution was the Foreigner gem[0]).
(My guess is Rails didn't use proper FKs by default because the default development db (SQLite) originally didn't support foreign keys (though it has for a while now, since 3.9.16), and they presumably wanted to minimise the differences in the way they use different databases).
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.
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!
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!
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 is a good way to know, you just need to drop your requirements.txt and it will tell you!
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.
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
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.
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.
"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)."
How good are Django 1.7 migrations at detecting things which have already happened? In particular, can you safely maintain South migrations alongside Django ones, or do you have to force users to switch?
The problem I envisage is that when you add 1.7 support to your app, you move your old migrations into south_migrations and start a clean migrations dir, as the instructions say - but what happens when your next release makes a database change? If you want to support all active versions (1.4, 1.6 and 1.7) you'd have to add a South migration and a 1.7 migration to support both groups of users - but then they no longer have a clean upgrade path from South to 1.7.
From reading the docs, it looks like 1.7 schema migrations may detect the changes have already been made and skip over them, but what will happen when you have data migrations too?
Does 1.7 figure out which operation you're up to by comparing your migrations to the database state, and starting migrations once the two match? What if at some point you return to an older set of model fields - does it match on the earliest or the latest?
I plan on avoiding the issue as long as possible: get my apps as feature complete as possible under South (with instructions for 1.7+ users for creating their own migrations), then bump the version when I switch from South to Django migrations. I'll then try to backport bugfixes to the South version (as long as they don't change the db) until support for Django 1.4 and 1.6 are dropped.
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.
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.
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.