On May 21, 2013, at 8:04 AM, Tom Evans wrote:
>
> The purpose of using an ORM is to make your application database
> agnostic. You should not find that changing DB engine is overly
> taxing.
Theoretically, yes. The difference between theory and practice is very small in
theory, and not so much in practice. ;-)
Theoretically, the ORM should protect you from differences between databases.
In practice, this doesn't always happen.
There *are* real world differences between running different databases on the
same ORM. Quoting the purpose of an ORM and telling someone they "should not"
have a problem is naive, sorry.
While some of these differences can be avoided, doing so requires the developer
to know that they exist in the first place, thus negating the purpose of using
an ORM. Given the character of the question by the original poster, I suspect
he might have issues with this.
PostgreSQL is very strict by default. SQLite is very forgiving.
You can also run into problems with South migrations working on one and not the
other.
> Not all of these statements are wholly accurate, mysql will re-use
> keys when necessary (but doesn't try to 'back fill' the set of used
> ids), and
The statements don't need to be "wholly accurate". The behavior is different in
practice.
> mysql is also perfectly happy with 0 as a primary key, but
> will replace it with the next auto increment id if the field is an
> auto increment field.
class Moo(models.Model):
name = models.CharField(max_length=50)
moo.json:
[
{
"pk": 0,
"model": "test.moo",
"fields": {
"name": "Test"
}
}
]
Running as MySQL:
anderson$ python manage.py loaddata moo.json
ValueError: Problem installing fixture
'/Users/anderson/src/.../fixtures/moo_genre.json': The database backend does
not accept 0 as a value for AutoField.
Running as Sqlite:
anderson$ python manage.py loaddata moo.json
Installed 1 object(s) from 1 fixture(s)
If your real world dataset includes a row with 0 as the primary key, you need
to be aware of this.
> There is no 'natural ordering' of un-ordered
> results, the order is undefined, and undefined behaviour is undefined.
In theory, yes. However, the naive developer may observe that this ordering is
actually implementation-specific under the hood and write code based on that
fact, and in doing so tie the code to a particular implementation. Yes, you
should always include an order_by if your use case depends on ordering. No, not
everyone realizes that.
> The point is, installing and learning the ins and outs of an RDBMS is
> not necessary to using Django. If you think you are stuck trying to
> install or understand postgres, just ignore it and use sqlite. You can
> always change at a later date.
And my point is that there remain ins and outs of the various database backends
that prevent seamless migration between them.
At some point you will need to install and test on your production database.
Why not do it first and avoid possible incompatibilities between dev and
production down the way?
If you're just learning, that's fine. No need. But as soon as you're on an
actual project, do yourself a favor and develop on the platform you plan on
using in production.
Regards,
-scott
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
