Django 1.7 Released
djangoproject.com
djangoproject.com
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.
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.
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
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/
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.
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.)
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 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).
For something a bit different, I recommend taking a look into Morepath: http://morepath.readthedocs.org/en/latest/
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.
I ask because I hit a few weak spots in the docs and a maintainer that wasn't really interested in understanding my pull requests last year.
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.
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.
Note that it's possible to squash a long series of migrations to just one "CREATE TABLE" version: https://docs.djangoproject.com/en/dev/topics/migrations/#squ...
After squashing, the new all-in-one migration should be used for tests, and should be more or less identical to syncdb.
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.
http://andrewingram.net/2012/dec/common-pitfalls-django-sout...
Thank you to everyone involved in getting this release out the door!
It seems there are a bit more on rails model associations.
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.
> 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.
(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).
Is it me or AppConfig.ready() looks like a great place to put signals setup ?
The app refactor is the single biggest improvement to Django in years. Bigger than CBVs, IMO.
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.
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!
Great work to everyone involved, and thanks for making an amazing product that makes going to work fun
The upgrade path is to delete all your old migrations and create a new initial one.
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)."
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.
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.