Somebody mentioned in #django the other day that they have multiple databases with the same schema... Well *lucky me* so do I!!
This is one way to work with this issue. I've also included migrate_table_structure just in case the schema doesn't exist in the new database yet.
As per the multiple-db-support branch, write all of your databases into the OTHER_DATABASES in settings.py. You can now copy models from your various models.py files and use them in different databases at the same time.
This can also be used to migrate databases from one dialect to the other without having to translate your data into an interim format (e.g. csv, XML). You can just do:
qs = MyModel.objects.filter(**filters)
NewModel = duplicate_model_and_rels(MyModel, 'new_db')
#Assuming that the schema is already in new_db:
for mod in qs:
new = NewModel()
new.__dict__ = mod.__dict__
new.save()
I tried this using some hacks with SQLAlchemy, and the above approach is a huge amount quicker! I've used this to copy some stuff from an oracle db, into a sqlite db so i could carry on working later and transferred about 20,000 in 5 mins or so.
GOTCHAS
========
This only works against my copy of multi-db as I've made a couple of changes. My copy is substantially the same as my patch attached to ticket 4747 though, so it might work to a point (especially the data migration aspect). If it doesn't work hit me up and I'll send you my patch against trunk.
I'm not too crazy about the code in copy_field, it works fine, but looks ugly... If anyone knows of a better way to achieve the same, please let me know.
Make sure we don't create an infinite loop with a self-referencing foreign key.
Many times I have needed category models that reference themselves, providing a flexible way to make children categories, grandchildren categories, etc. If you chain the slugs (or even ids) there's a chance you could end up with an infinite loop.
Assumes a required, unique slug field ('slug') and an optional self-referencing foreign key
('parent'). All_data doesn't give you the object's ID, so we will find it via the unique slug.
If either is not present we pass -- if there's no parent chosen it's not a problem, and if there
is no slug present the submission will fail on that validation instead. It is worth noting that
if the user changes the slug field on submission AND picks a bad parent it will not be caught.
Infinite loop cases:
1. A references A
2. A tries to reference B, which is currently referencing A