From b4928633d8f4fb0638acef78142b08abd866d9d9 Mon Sep 17 00:00:00 2001
From: Tom Willemsen
Date: Fri, 18 Jan 2013 23:23:02 +0100
Subject: Delete blog, move project

---
 blog/blog-2012-04-24-1551.org | 44 -------------------------------------------
 1 file changed, 44 deletions(-)
 delete mode 100644 blog/blog-2012-04-24-1551.org

(limited to 'blog/blog-2012-04-24-1551.org')

diff --git a/blog/blog-2012-04-24-1551.org b/blog/blog-2012-04-24-1551.org
deleted file mode 100644
index 3d9c7b2..0000000
--- a/blog/blog-2012-04-24-1551.org
+++ /dev/null
@@ -1,44 +0,0 @@
-#+TITLE: Silly django confusion
-#+DESCRIPTION: Think about this next time...
-
-I'm setting up a testing environment for work, using fixtures to save
-and load test data and I got a little stumped by something I ran into.
-
-I had exported one of the database tables we use to a json file that I
-was going to import into a fresh new database to test with. When I
-imported it everything seemed fine, except when looking at the actual
-page. So this is what I found:
-
-#+BEGIN_SRC sql
-SELECT * FROM app_table;
-    => 3 rows of data
-#+END_SRC
-
-#+BEGIN_SRC python
-from app.models import Table
-
-Table.objects.count()
-    => 3
-
-Table.objects.all()
-    => []
-#+END_SRC
-
-This is weird. So I looked at the ~django.db.connection.queries~
-property and I realized that it was doing a join since the model
-subclasses another:
-
-#+BEGIN_SRC python
-from django.db import models
-
-from app.models import SuperTable
-
-class Table(SuperTable):
-    field1 = models.CharField(max_lenth=200)
-#+END_SRC
-
-Which, of course, means that in order to get the complete ~Table~
-instance, the related ~SuperTable~ instance is also required, but in
-order to do a ~COUNT~ of ~app_table~ it isn't necessary. And that's
-where the inconsistency came from, now that I've also copied the
-contents of ~SuperTable~ everything is fine again.
-- 
cgit v1.2.3-54-g00ecf