Django

schemamigration COMPULSORY for apps with existing migrations
If you are working on an app with an existing set of pre-defined migrations, you must do the following python manage.py schemamigration YOURAPPNAME --auto python manage.py migrate YOURAPPNAME

otherwise the changes you make to the models will not generate new tables even if you do a python manage.py syncdb

Found this out the hard way while working on [cms_saq]

To make your changes reflected immediately in the development python server and DB, just rename the migrations folder:

mv migrations migrations.disable

reinstate the migrations directory and do an actual schemamigration when you are done modifying and testing your model.

Notes on Django-CMS

 * Great Django-CMS tips/snippets by Ilian Iliev

CMSPage

 * Django-CMS maintains two instances of every page in the DB, one draft, one published.
 * When a page is initially created, 1 (draft) copy is created in the DB
 * When a page is published, another copy (published) is created. The published version will be a copy, while the draft version also exists
 * The implications for this is that you cannot specify each page to be unique in the DB while designing your customer CMS-pages

CMSPlugin

 * The same applies for CMS plugins: it exists as 2 copies in the DB, one draft, one published (if published).
 * Both copies will have the exact same values, differentiated only by the CMS field cmsplugin_ptr_id


 * Other class instances associated with the plugin exists only once in the DB, but are only associated to the published instances.


 * In your CMSPlugin, you have to explicitly define a *copy_relations* method to actually copy the relations from the old plugin to the new plugin


 * Thus the best practice for CMSplugin design is to create relations from the plugin to your custom models, and not use the plugin itself as the raw model.

Django-CMS-SAQ
Example of a badly coded CMSPlugin: [Master Branch of django-cms-saq]


 * This plugin made a grave design mistake by including a unique constraint in the Question(CMSPlugin), specificially, one of its field 'slug' must be unique.
 * This creates a grave problem when the Question(CMSPlugin) gets published, Django-CMS tries but fail to create another copy of the same question plugin with the *same* slug, which violates the unique slug constraint.
 * In other words, the question plugin in cms_saq can never be published!


 * Likewise, the Answers model wrongly requires (questionid, answerslug) to be unique together, i.e., unique_together = ('question', 'slug'), resulting in the same problem when the plugin is published
 * publishing the plugin requires the copying of all answer relations from the old plugin (draft) to the new plugin (published), in which case, the new instance of ('question' and 'slug') answers will no longer be unique, generating another error!

There is a [branch of django-cms-saq] that takes into consideration django-1.5 requirements, including some of my contributions.