4 ms·
Conversely, at one point I wanted to start using Postgres' JSONB features, but was running my production app on a MySQL backend. Switching was as simple as: 1
by silviogutierrez 10y ago
Conversely, at one point I wanted to start using Postgres' JSONB features, but was running my production app on a MySQL backend.
Switching was as simple as:
1. Export all data to fixtures.
2. Change settings.py to use the Postgres drive.
3. Load all data into fixtures.
Granted, I was sticking to core Django ORM calls, so I wasn't hard coding any SQL anywhere. And the null ordering does change a little, but the tests caught that.
So I was definitely glad that worked out. And have been super happy with postgres.
- bayonetz 10y ago>sticking to core Django ORM calls I think that's what made it easy. That's the trade off when you try to build a generic DB access to support the trivial DBMS swap like the article take about -- you end up writing a lowest common denominator of functionality common to all your anticipated DBMSs. I assume Django's ORM let's one do DBMS specific stuff but you happened to not make use of that. I agree with the article, 9/10, don't try writing wrappers just to support the "easy future swap out". Write them if they make the specific technology more palatable to work with. An example I'm my life: Rails' ActiveRecord is just a joy to work with but we would be hurting plenty if we tried to swap out to a different DBMS.