{"id":279,"date":"2013-04-02T00:12:56","date_gmt":"2013-04-02T06:12:56","guid":{"rendered":"http:\/\/www.crccheck.com\/blog\/?p=279"},"modified":"2015-10-11T22:23:36","modified_gmt":"2015-10-12T04:23:36","slug":"dissecting-elevators-1-database","status":"publish","type":"post","link":"https:\/\/www.crccheck.com\/blog\/dissecting-elevators-1-database\/","title":{"rendered":"Dissecting Elevators part 1: rapid models.py development"},"content":{"rendered":"

Intro<\/em>: This is part one of an eight part series looking at the Elevator Explorer<\/a>, a fun data interactive mostly coded between the hours of 10 PM to 2 AM during the week leading up to April Fools’ Day, 2013. I’m going to be looking at the things I learned, things I wish I could have done, and the reasoning behind my design choices. The code I’ll be referring to will be in this tagged release on github<\/a>.<\/p><\/blockquote>\n

Rapid models.py development<\/h1>\n

Introduction<\/h2>\n

Every minute doing boilerplate at the beginning of a project is a minute you’re not developing. And the beginning of a project is when you really need that momentum to code ideas, not fiddle with settings.\u00c2\u00a0 This post goes into how I do my database boilerplate.<\/p>\n

It is very common to use sqlite in early Django development because it’s so easy to migrate your database after editing your models. All you have to do is delete your old database file and run syncdb<\/code> again. I even made a generic make command to find and delete all .sqlite files then run syncdb<\/code> so I could reuse the same make resetdb<\/code> command in every project. But what if you want to use another database like PostgreSQL? You could port to using dropdb<\/code>\/createdb<\/code>, but you may find it annoying to set up for every new project.\u00c2\u00a0 Luckily, there is a generic way thanks to django-extensions<\/a> and DJ-Database-URL<\/a>, both of which I include on every project. In my settings.py<\/a>, I still use sqlite by default with:<\/p>\n

DATABASES = {'default':dj_database_url.config(default='sqlite:\/\/\/' +\r\n    project_dir('example_project.sqlite'))}\r\n<\/code><\/pre>\n
but in my virtualenv’s postactivate (or in your .env file), I have:<\/p>\n
export DATABASE_URL='postgres:\/\/\/tx_elevators'\r\n<\/code><\/pre>\n
so it actually uses PostgreSQL. And by using django-extensions’s reset_db<\/code> management command, the modifications to the makefile actually end up making things simpler<\/em>:<\/p>\n
# old version:\r\n#   $(foreach db, $(wildcard $(PROJECT)\/*.sqlite),\\\r\n#      rm $(db);)\r\n#\r\n# new version:\r\nresetdb:\r\n    python $(PROJECT)\/manage.py reset_db --router=default --noinput\r\n    python $(PROJECT)\/manage.py syncdb --noinput\r\n<\/code><\/pre>\n
https:\/\/github.com\/texastribune\/tx_elevators\/blob\/2013-april-fools\/Makefile#L22-L24<\/a><\/p><\/blockquote>\n
Just remember to put django-extensions in your installed apps<\/a>. And make sure you’re using a recent version of django-extensions (>= 1.1.0), because there was a bug<\/a> in reset_db<\/code> prior to then.<\/p>\n
Now after every model change, you can still use make resetdb<\/code> to reset the db, no matter what database engine you use. Well… as long as that database engine is either sqlite, MySQL, or PostgreSQL.<\/p>\n
\"anonymous<\/a><\/p>\n
Why not South?<\/h2>\n
South is a pain. Even if you script away the repetitiveness, it is an overly-complicated, blunt instrument designed for established projects, not for rapidly developing pre-alpha projects. And wiping away the database<\/em> is a good thing. It means you can’t accumulate baggage in your data that you’ll never be able to recreate. Another benefit is that bootstrapping development on a new machine is a breeze because you’ve make that process simple and repeatable. And if you do need to do a quick migration, my first choice is django-extensions’s sqldiff<\/code><\/a> command. For example, let’s say I wanted to make the year_installed<\/code> date null-able to indicate bad data, and to make Building.city<\/code> a foreign key to a new City<\/code> model. If I changed my original models.py<\/a> to do that, the output of .\/manage.py sqldiff tx_elevators<\/code> becomes:<\/p>\n
BEGIN;\r\n-- Application: tx_elevators\r\n-- Model: City\r\n-- Table missing: tx_elevators_city\r\n-- Model: Building\r\nALTER TABLE \"tx_elevators_building\"\r\n    DROP COLUMN \"city\";\r\nALTER TABLE \"tx_elevators_building\"\r\n    ADD \"city_id\" integer;\r\nCREATE INDEX \"tx_elevators_building_city_id_idx\"\r\n    ON \"tx_elevators_building\" (\"city_id\");\r\nALTER TABLE \"tx_elevators_building\"\r\n    ALTER \"city\" TYPE integer;\r\nALTER TABLE \"tx_elevators_building\"\r\n    ALTER COLUMN \"city\" SET NOT NULL;\r\n-- Model: Elevator\r\nALTER TABLE \"tx_elevators_elevator\"\r\n    ALTER COLUMN \"year_installed\" DROP NOT NULL;\r\nCOMMIT;\r\n<\/code><\/pre>\n
Which I can pipe into the database. You do<\/em> have to know some SQL, because the SQL it produces is not always right, but it does get you 95% of the way there.<\/p>\n
Afterwards<\/h2>\n
Once you do a release, you should abandon this and switch to using South. You can still use make reset_db<\/code> and blow everything away, but you should at least be providing migrations once your project is stable.<\/p>\n
Next time…<\/h2>\n
I’ll go over how I made importing data a one-liner.<\/p>\n","protected":false},"excerpt":{"rendered":"
Intro: This is part one of an eight part series looking at the Elevator Explorer, a fun data interactive mostly coded between the hours of 10 PM to 2 AM during the week leading up to April Fools’ Day, 2013. I’m going to be looking at the things I learned, things I wish I could…<\/p>\n Read More<\/span> Dissecting Elevators part 1: rapid models.py development<\/span><\/a>","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"Layout":"","footnotes":""},"categories":[50,21,4],"tags":[51,54,48],"class_list":["entry","author-showmewhatyougot","post-279","post","type-post","status-publish","format-standard","category-best-practices","category-case-study","category-technical","tag-django","tag-makefiles","tag-python"],"_links":{"self":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/279","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/comments?post=279"}],"version-history":[{"count":22,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/279\/revisions"}],"predecessor-version":[{"id":751,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/posts\/279\/revisions\/751"}],"wp:attachment":[{"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/media?parent=279"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/categories?post=279"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.crccheck.com\/blog\/wp-json\/wp\/v2\/tags?post=279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}