I kind of wish it were default for primary keys, since the number of times I got burned by having databases I couldn't easily merge (which UUIDs help a lot with) way exceeds the number of times I had performance/memory issues caused by actually using UUIDs.
Databases aren't my field, but I would expect this to hurt performance by decreasing locality of keys.
This, of course, assumes that temporally-adjacent additions are related, but this seems like a common case for large data sets since they often arise from a series of measurements or transactions.
I created this account to make this reply because I imagine that someone here is expert enough to set me straight if I'm mistaken.
Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.
When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.
Please help me understand this better. So HStoreField is not exactly Json field type of postgres but rather a subset of it, i.e just string->string mapping without any nesting. You cant even have key->array mapping?
Basically yes. hstore and json have entirely separate interfaces in Postgres, but the storage properties of hstore are a subset of json as you say. json/jsonb is generally more powerful, and will supplant hstore in a lot of new projects.
However hstore has been a part of Postgres since version 8.2 released in 2006, and I think was around as a third-party project before that, so it's used by a lot of projects.
It's also easier to manipulate hstore values then json values within the database. hstore's simplicity allows operators for combining and subtracting hstore values[0] which json doesn't have. Due to its restrictions, an hstore can also be converted to and from a record type (think database row). JSON fields on the other hand will generally be populated by your app and then only queried by the database.
It humors and saddens me that Django is a web framework with an ORM bolted on. SQLAlchemy has had a postgres driver that supports HSTORE and JSON/JSONB for ages.
Likewise, Django has had third-party hstore and jsonb fields for ages, but I take your point. SQLAlchemy is beautiful.
The Django ORM has taken great strides lately. Another big improvement in 1.8 is the expansion of database expressions – you can now combine arbitrary database functions and columns as you can in SQLAlchemy. This is a big step towards a cleaner, logically consistent API, and makes extensibility (like that offered in the new contrib.postgres) much easier.
Django's ORM also does things that SQLAlchemy's doesn't. Even at its highest level SQLAlchemy requires explicit joins AFAIK.
That said the Django team is aware of SQLAlchemy's arguable superiority and there have been numerous proposals to integrate it somehow. The most likely plan would be to use SQLAlchemy core to replace the low-level SQL generation. That way you could take a Django queryset and get its SQLAlchemy representation, then continue building from there.
SQLAlchemy is awesome, but it's an order of magnitude more complex to setup and configure than the Django ORM. With Django you get the integration with migrations, a system to spin up and tear down test databases, less boilerplate code required during model configuration (like not needing to specify the name of the database table), etc...
From the quick searching I've done, I think that Django predates SQLAlchemy by nearly a year (July 2005 and May 2006 respectively).
Alchemy has a lot more power behind it, but the Django ORM is (arguably) easier to use for the majority of web use cases.
I had a hand in opening up the Django ORM with the introduction/formalisation of Query Expressions (https://docs.djangoproject.com/en/1.8/releases/1.8/#query-ex...), and others are doing significant work in cleaning up the ORM internals so that more complex features can be layered on in core and by users.
Why does it sadden you? It seems like the majority of use-cases for database interaction (at least with the relational ones, likes PostgreSQL or MySQL) occur in web frameworks. The coupling makes a lot of sense to me, especially given the opinionated nature of programming in Python.
Really like that they added a way to store time intervals as python timedelta objects. Previously i think the best approach was to store a number of seconds as an integer and then calculate the number of minutes, hours etc.. yourself.
I recently switched a project back to Django after some time playing with Rails.
One of the biggest attractions of Rails is the asset pipeline, but splitting the project and building the front-end with Ember-CLI takes away that advantage, leaving Django far ahead (IMO) with its cleaner ORM, less magical module importing, and Python's indented syntax.
I'd love to hear about your experiences with building APIs for single-page-apps between Rails and Django. Were you using rails-api or just straight-up Rails? Is there an equivalent API-focused "flavor" of Django, or if not, to what extent did you find it easy to choose not to use server-rendering functionality? I've used Django for more standard apps, and Rails for both, but I'm curious about the pros and cons of using Django for this sort of thing, because I have no experience with it.
Django REST Framework is the the most popular way to build APIs with Django. Lot of neat features out of the box such as throttling and permissions make it easy to build API endpoints.
I'm still new to building APIs with Django. Last time I was immersed in Django, I was focused on server-side rendering.
I forgot to mention, part of the reason I went to Rails is its built-in support for building JSON APIs (at the time there was no clear winner among the Django API frameworks).
But now Django Rest Framework has matured quite well. By deriving everything from the model layer, it can help keep your API code nice and DRY.
I'm genuinely curious, have you tried one of the asset-pipeline apps for django? I found django-pipeline actually not that bad, even though I have been recently leaning towards using front-end tools (gulp/browserify) anyway.
I have not. For the front-end I'm using Ember, and Ember-CLI takes care of Emblem templates, Sass, and CoffeeScript, plus breaking code up into ES6 modules. Eventually they plan to require using it in order to get all of the features of Ember.
I was using Jammit (ruby) for assets but recently switch the django-pipeline and it is working well. For front end apps, I use Grunt.js because I am to lazy to upgrade to something new
On the other hand, Django was a new framework, once. If you want to create a web framework for Go that is equivalent to Django, you have to start somewhere.
Damn Django is pretty hard at sunsetting old versions. If they are going to release a new one in October and only supply security upgrades to things that are two versions behind, does that means you have to upgrade your system in less than a year?
And Django 1.4 was released on the 23rd of March 2012, so if you stick with the LTS releases you very rarely have to upgrade. I have to say though, I wouldn't want to upgrade a 1.4 app to 1.8 - lots of big changes have happened between those two releases.
The reason for the LTS versions is in large part for enterprises that are stuck on older versions of Python because of RedHat support contracts and the like.
Django can move ahead and drop support for (honestly very outdated) Python versions like 2.5 and 2.6 so that newer Django releases can take advantage of additional features and nicer syntax in newer Python versions.
And companies stuck on python 2.6 because that's what's bundled in whatever version of RHEL can still get security patches to Django.
It's unreasonable to expect the (volunteer) django maintainers to indefinitely support every version of python or every version of Django.
And if you have no choice of upgrading to Django 1.5 yet, I'm sure you'd rather continue to get security patches until you can upgrade to 1.8.
Agree. The LTS releases are great, but for anything you expect to be working with on an ongoing basis I think it's worth the yearly pain of upgrading rather than a huge headache every three years.
It is just that I imagine most IT projects have a timespan in decades so ideally you want something like Java that can still run your old stuff and where upgrading means putting out a new runtime.
You either see (call) a bet or you raise it, you don't see and raise, as it's confusing. There's a name for this confusing, inappropriate behavior in a poker game: string bet [0], and it's simply not allowed at most tables.
- official Jinja2 support, and a generic template interface
- native postgres fields
- uuid field
and it is an LTS. Time to get upgrading.