Get all django remaining migrations
It will return list of all remaining migrations
- migration
- migrations
Snippet List
Testing for pending migrations in Django
DB migration support has been added in Django 1.7+, superseding South. More specifically, it's possible to automatically generate migrations steps when one or more changes in the application models are detected. Definitely a nice feature! I've written a small generic unit-test that one should be able to drop into the tests directory of any Django project and that checks there's no pending migrations, ie. if the models are correctly in sync with the migrations declared in the application. Handy to check nobody has forgotten to git add the migration file or that an innocent looking change in models.py doesn't need a migration step generated. Enjoy!
- testing
- unittest
- database
- migration
Loading initial data per model at table creation (useful with migrations)
A very simple way of automatically loading data on model creation. As I am using South I wanted an automatic way of loading initial data only when a new model is create during a migration. Django provides almost everything out of the box by providing the *post_syncdb* signal (triggered also by South migrate command) and the *loaddata* command. The code will simply look for a an existing fixture named `<model>_initial.*` and invoke the *loaddata* command to try to load it Note: beware *post_syncdb* signal is deprecated since version 1.7: it has been replaced by *post_migrate*.
- loaddata
- migration
- south
South unran migration check
Middleware that checks if you ran all South migrations. If not, it will throw an exception. Make sure to only use this middleware in development!
- middleware
- migration
- south
Proper fixtures loading in south data migrations
South documentation [contains a description](http://south.readthedocs.org/en/0.7.6/fixtures.html#fixtures-from-migrations) of the way you can load fixtures inside the data-migrations. def forwards(self, orm): from django.core.management import call_command call_command("loaddata", "my_fixture.json") It seems pretty clear and easy, but in fact it does not work the way you expect from south migrations, because the fixture loading does not engage the **orm** object. So, it allows **loaddata** management command to use standard models loading mechanism, and it would provide the most recent version of the models, obviously, which may not correspond to the schema of the fixture`s data. To be ensured that migration will use appropriate version of the models for fixture loading you could use code like follows: class Migration(DataMigration): def forwards(self, orm): load_fixture('my_fixture.json', orm) class Migration(DataMigration): def forwards(self, orm): with southern_models(orm): call_command("loaddata", "my_fixture.json")
- fixtures
- migration
- fixture
- south
- datamigration
Drupal password hasher for migration
This BasePasswordHasher allows the easy migration of passwords from Drupal to Django 1.4. Drupal stores its passwords using a SHA512 hash, but with some iterations and postprocessing. This snippet allows you to migrate the username and passwords over seamlessly- the only necessary change is truncating the first character of each password hash (since Django 1.4 stores each password as algorithm$hash). Note that this snippet *requires* Django 1.4, but there is no option for that snippet in the list. Provided as a github gist [here](https://gist.github.com/2344345).
- migration
- password
- hash
- drupal
Dynamically maintain local_constants.py from South migration
Allows you to dynamically maintain a local_constants.py file from a migration tool like South. Example of usage: set_constant('/home/projects/sample/local_constants.py', 'STAMP_MW_ID', 42, 'Set from sample.0007_add_constants.py') More more information, see [Allows you to dynamically maintain a local_constants.py file from a migration tool like South. Example of usage: set_constant('/home/projects/sample/local_constants.py', 'STAMP_MW_ID', 42, 'Set from sample.0007_add_constants.py') More more information, see [http://menendez.com/blog/maintain-contants-through-south-data-migration/](http://menendez.com/blog/maintain-contants-through-south-data-migration/).
- migration
- data
- south
Command to dump data as a python script
This creates a fixture in the form of a python script. Handles: 1. `ForeignKey` and `ManyToManyField`s (using python variables, not IDs) 2. Self-referencing `ForeignKey` (and M2M) fields 3. Sub-classed models 4. `ContentType` fields 5. Recursive references 6. `AutoField`s are excluded 7. Parent models are only included when no other child model links to it There are a few benefits to this: 1. edit script to create 1,000s of generated entries using `for` loops, python modules etc. 2. little drama with model evolution: foreign keys handled naturally without IDs, new and removed columns are ignored The [runscript command by poelzi](http://code.djangoproject.com/ticket/6243), complements this command very nicely! e.g. $ ./manage.py dumpscript appname > scripts/testdata.py $ ./manage.py reset appname $ ./manage.py runscript testdata
- dump
- manage.py
- serialization
- fixtures
- migration
- data
- schema-evolution
- management
- commands
- command
Simple Plone Migration
This is a very simple script to do a **simple** migration from plone content to django. ATNewsItems and PloneArticles are imported into the django model *Article* (with Foreignkey to the django models *File* and *Image*). ATDocuments are imported into the django model *Page*. **Usage** 1. Make sure that the Python version running Zope can import django 2. The django database should be writeable from within the Zope environment 3. Set the shell variable *DJANGO_MODULE_SETTING* to the settings file of the django project you want to import your Plone content to 4. Start the Zope server in the debug modus: $ bin/zopectl debug Then import the python module above, and pass the site you want to migrate to the start function: import simple_migration mysite = app.mysite simple_migration.start(mysite) Found 1253 objects Saved Test Document Type: ATNewsItem ... Hope it helps someone. Used for the migration of **Plone-2.5.3** content in a **Python-2.4.4** environment.
- migration
- import
- plone
Database migration and dump/load script
I once needed to convert a Django project from PostgreSQL to SQLite. At that time I was either unaware of manage.py dumpdata/loaddata or it they didn't yet exist. I asked for advice on the #django IRC channel where ubernostrum came up with this plan: simple process: 1) Select everything. 2) Pickle it. 3) Save to file. 4) Read file. 5) Unpickle. 6) Save to db. :) Or something like that. First I thought it was funny, but then started to think about it and it made perfect sense. And so dbpickle.py was born. I've used this script also for migrating schema changes to production databases. For migration you can write plugins to hook on dbpickle.py's object retrieval and saving. This way you can add/remove/rename fields of objects on the fly when loading a dumped database. It's also possible to populate new fields with default values or even values computed based on the object's other properties. A good way to use this is to create a database migration plugin for each schema change and use it with dbpickle.py to migrate the project. See also [original blog posting](http://akaihola.blogspot.com/2006/11/database-conversion-django-style.html) and [my usenet posting](http://groups.google.com/group/django-users/browse_thread/thread/6a4e9781d08ae815/c5c063a288483e07#c5c063a288483e07) wondering about the feasibility of this functionality with manage.py dumpdata/loaddata. See [trac site](http://trac.ambitone.com/ambidjangolib/browser/trunk/dbpickle/dbpickle.py) for version history.
- dump
- database
- migration
- load
- pickle
10 snippets posted so far.