django-south

Does Django's south (migration tool) work for innodb?

允我心安 提交于 2019-11-30 09:57:02
$ py manage.py migrate turkey Running migrations for turkey: - Migrating forwards to 0001_initial. > turkey:0001_initial ! Error found during real run of migration! Aborting. ! Since you have a database that does not support running ! schema-altering statements in transactions, we have had ! to leave it in an interim state between migrations. ! You *might* be able to recover with: = DROP TABLE `turkey_demorecs` CASCADE; [] ! The South developers regret this has happened, and would ! like to gently persuade you to consider a slightly ! easier-to-deal-with DBMS. ! NOTE: The error which caused

Modify Django AutoField start value

北慕城南 提交于 2019-11-30 09:33:18
问题 I have and existing database, which I have migrated with SQLAlchemy to a new PostgreSQL database. I moved all primary keys with the same values as before. Now I have tables filled with data, but the associated sequences starts from 1. I have pk values stored 1 to 2000. Now, when I try to save something with Django, I have the duplicate key value violates unique constraint regarding to the Primary Key. How can I modify the sequence start values or escape this situation? My current solution is:

Move Django model from one app to another [duplicate]

☆樱花仙子☆ 提交于 2019-11-30 08:37:07
问题 This question already has answers here : How do I migrate a model out of one django app and into a new one? (7 answers) Closed 5 years ago . I made the stupid mistake of creating too many models in the same Django app, now I want to split it into 3 distinct ones. Problem is: there's already data in production in two customers' sites, so I need to carefully plan any schema/data migration to be done (I'm using django-south). I'm unsure on how to proceed, any advice would be greatly appreciated.

How to call a static methods on a django model class during a south migration

五迷三道 提交于 2019-11-30 06:03:45
I'm writing a data migration in south to fix some denormalized data I screwed up in earlier code. The way to figure out the right value for the incorrect field is to call a static method on the django model class. The code looks like this: class Account(models.Model): name = models.CharField() @staticmethod def lookup_by_name(name): # There's actually more to it than this return Account.objects.get(name=name) class Record(models.Model): account_name = models.CharField() acct = models.ForeignKey('Account') ... class Migration(DataMigration): def forwards(self, orm): # Fixing Records with the

Migrating data from “Many-To-Many” to “Many-To-Many Through” in django

≯℡__Kan透↙ 提交于 2019-11-30 04:50:43
I've got a model class Category(models.Model): title = models.CharField(...) entry = models.ManyToManyField(Entry,null=True,blank=True, related_name='category_entries', ) That I wish to refactor to have additional data with each relationship: class Category(models.Model): title = models.CharField(...) entry = models.ManyToManyField(Entry,null=True,blank=True, related_name='category_entries', through='CategoryEntry', ) But south deletes the existing table. How can I preserve the existing m-t-m relationships? Create your intermediate model without any extra fields, for now. Give it a unique

Adding a “through” table to django field and migrating with South?

蓝咒 提交于 2019-11-30 01:20:41
问题 Seems like this should be "easy" or at least documented somewhere, I just cant find it. Lets say I have a model: class A(models.Model): users = models.ManyToMany('auth.User', blank=True) Now I want to migrate to have a through table to add fields to the ManyToMany relation... class AUsers(models.Model): user = models.ForeignKey('auth.User') a = models.ForeignKey('A') new_field = models.BooleanField() class A(models.Model): users = models.ManyToMany('auth.User', blank=True, through='AUsers')

migrating django-model field-name change without losing data

回眸只為那壹抹淺笑 提交于 2019-11-29 23:54:58
I have a django project with a database table that already contains data. I'd like to change the field name without losing any of the data in that column. My original plan was to simply change the model field name in a way that would not actually alter the name of the db table (using the db_column column parameter): The original model: class Foo(models.Model): orig_name = models.CharField(max_length=50) The new model: class Foo(models.Model): name = models.CharField(max_length=50, db_column='orig_name') But, running South's schemamigration --auto produces a migration script that deletes the

South data migration 'instance' error when using south freeze orm

我与影子孤独终老i 提交于 2019-11-29 22:16:01
问题 I have a south datamigration that is trying to create new objects based on data found in other models. When trying to create a new object for the given 'destination' model I keep getting: Cannot assign "<ContentType: ContentType object>": "Publishing.content_type" must be a "ContentType" instance. It seems that there is something wrong with the 'instance' when accessed via the South freeze ORM, e.g.: ContentType = orm['contenttypes.ContentType'] content_type_kwargs = { 'model': ContentModel.

Django not creating db tables for models (neither with syncdb nor South)

别等时光非礼了梦想. 提交于 2019-11-29 15:02:44
I have a Django project on a Centos VPS. I created some models and debugged them so they validate and give no errors. I have them in a "models" folder in my myapp and have added each model to the init file in this directory, for example: from category import Category I added the app to settings.py INSTALLED_APPS and ran: Python manage.py syncdb It appeared to work fine and added all tables apart from the ones for my app. I then installed South and added that to INSTALLED_APPS and, tried syncdb again and ran: Python manage.py schemamigration myapp --initial It generated the file correctly but

Does Django's south (migration tool) work for innodb?

瘦欲@ 提交于 2019-11-29 14:57:12
问题 $ py manage.py migrate turkey Running migrations for turkey: - Migrating forwards to 0001_initial. > turkey:0001_initial ! Error found during real run of migration! Aborting. ! Since you have a database that does not support running ! schema-altering statements in transactions, we have had ! to leave it in an interim state between migrations. ! You *might* be able to recover with: = DROP TABLE `turkey_demorecs` CASCADE; [] ! The South developers regret this has happened, and would ! like to