First time here? Check out the FAQ!

Revision history  [back]

Thread model is there to separate data relevant to the thread as a whole and that of posts. The separation is not always clean - for example votes are duplicated on thread and post.

Thread contains title and tags and post does not, there are some other fields that are only present in the Thread.

All posts used for Q&A have a relation to Thread via a foreign key. Posts of type != either one of 'question', 'answer' or 'comment' may have nulled relation to thread.

Post actually already contains a relation to post - called "parent" - this one is used to associate comments with their parent posts. If you want to add another - it will be necessary to give a unique "related_name".

Another piece is PostRevision, which confusingly does store revision info on tags and titles.

This modeling would be simpler with just Post and PostRevision, but in that case Post would have to carry lot's of fields that would not be used most of the time.

Another consideration for the data modeling is performance: as we have it now - we can load all posts for one thread with one query - by the thread_id and then sort them out into question, answers and comments. Originally we had models Question, Answer and Comment and you can imagine how many more queries were necessary to load data for the question detail page.

Thread model is there to separate data relevant to the thread as a whole and that of posts. The separation is not always clean - for example votes are duplicated on thread and post.

Thread contains title and tags and post does not, there are some other fields that are only present in the Thread.

All posts used for Q&A have a relation to Thread via a foreign key. Posts of type != either one of 'question', 'answer' or 'comment' may have nulled relation to thread.

Post actually already contains a relation to post - called "parent" - this one is used to associate comments with their parent posts. If you want to add another - it will be necessary to give a unique "related_name".

Another piece is PostRevision, which confusingly does store revision info on tags and titles.

This modeling would be simpler with just Post and PostRevision, but in that case Post would have to carry lot's of fields that would not be used most of the time.

Another consideration for the data modeling is performance: as we have it now - we can load all posts for one thread with one query - by the thread_id and then sort them out into question, answers and comments. . Originally we had models Question, Answer and Comment and you can imagine how many more queries were necessary to load data for the question detail page.

Thread model is there to separate data relevant to the thread as a whole and that of posts. The separation is not always clean - for example votes are duplicated on thread and post.

Thread contains title and tags and post does not, there are some other fields that are only present in the Thread.

All posts used for Q&A have a relation to Thread via a foreign key. Posts of type != either one of 'question', 'answer' or 'comment' may have nulled relation to thread.key.

Post actually already contains a relation to post - called "parent" - this one is used to associate comments with their parent posts. If you want to add another - it will be necessary to give a unique "related_name".

Another piece is PostRevision, which confusingly does store revision info on tags and titles.

This modeling would be simpler with just Post and PostRevision, but in that case Post would have to carry lot's of fields that would not be used most of the time.

Another consideration for the data modeling is performance: as we have it now - we can load all posts for one thread with one query - by the thread_id. Originally we had models Question, Answer and Comment and you can imagine how many more queries were necessary to load data for the question detail page.