So I have a website that was using the built in django user model with some extensions. For various reasons, I wanted to instead use a custom user model. I have it built and runs beautifully on my local machine.
Now, I have integrated it into the development version of my website, but I am having some problems. When I try to add a new field, the migrations won't work, because it tries to create a brand new initial table with the same names, which won't work. Using South for my migrations.
To combat that, I tried to rename all the tables, and then run the migrations, but that won't work because of foreign key issues. I tried to work around that, but ran into more problems when I tried to rename foreign keys.
If you would like more insight into the problem, please ask.
I feel as though there has gotta be an easier way to go about this. I would love any insight. Thanks!
Related
Is there any way that we can create an create an input field dynamically in the form without doing manually work, like first create the particular field in model and then run makemigartions command and then run migrate command.
I have tried using formset but that is not what i am looking for.
refer to vtiger demo
username - admin
password - admin
when you open this link there is a option ADD CUSTOM FIELD. i want to do same with my django. Hope i am able to explain you what i wants to do. I am searching for this since 3 days and cannot able to implement that.
You DO NOT (I repeat: "you DO NOT") want to "dynamically add fields" to a model (that is, to your database schema). You want your database schema to be stable, known, and totally under version control. If you don't get why, just ask yourself how your code could use a field that it's not even aware of (and that's only one of the oh so many reasons not to do such a thing).
"Features" like the one you mention are built using a fixed schema that is used to describe a "meta schema", where each "custom field" is actually a record in a "custom_fields" table, and then you usually have yet another table to store the matching values. This doesn't come without a lot of code complexity and a huge impact on performances both at the code AND database level.
If this is a project requirement, you now at least have a first idea of how this is to be done. But if your point is just to avoid having to write code and run migrations, then well, you really want to think twice about it...
I have a django app which consists of 17 models. Now I have realized that these models should be in 3 different apps(not in the original app). So now I would like to migrate these models out of the original app to these 3 different apps. How do I do that?
There exists foreign key, generic foreign key and ManyToMany relationships among the models. I also have data in the database(MySql), so I would like the data to be preserved during migration.
I have installed south for migrations, but don't know how to use it for solving this issue. I have gone through this similar question but could not find an answer that would solve my problem. Would be thankful for any help !
In my opinion, you have two ways of completing this task as stated below:
Move the models and add Meta.db_table to refer the existing sql table as needed as #kroolik suggested
Perform a three steps migration
The former is easier while the later could be better as tables would be named as you expect.
First of all, you mention you already has south installed. The first step would be to create the initial migration for the existing app. Take a look to the south tutorial. Then you must apply that migration, but as you already has the tables in db it would fail unless you include --fake flag.
After that you need to create the three apps you mention, and their models. Also create and apply (this time without fake flag) the initial migration for them.
Next step is write a datamigration. You must write it manually, although you can create the skeleton with datamigration. You must write "by hand" the migration.
Now you are almost done, the only remaining thing is remove the original tables. You can just remove those models, and create an "auto" schemamigration.
Don't forget to apply the migrations with migrate command. Also as #Bibhas mention a copy of database and/or a dump of it is a pretty good idea.
I need to add a couple fields to Group model in django contrib.auth app using:
field_name = models.CharField(...)
field_name.contribute_to_class(Group, 'field_name')
My issue is while creating the migrations with South, since they are created in the "migrations" directory inside the auth app and, since the system is already in production, I'm not allowed to alter the current django installation in the server in order to migrate auth.
Does anyone know how to create and load such migrations?
Thanks in advance for your help.
Django doesn't make it particularly easy to modify the standard models. I wouldn't recommend that you sublass Group, because it's quite annoying to get built-in functionality to reference the new model instead.
The usual thing to do here is to create a GroupProfile model that has a Group as a unique foreign key. It might not be elegant, but it won't have the huge maintenance overhead that comes with forking Django's source code.
Also: if you can't modify the Django code on the server, you aren't going to be able to do this with raw SQL hackery or a clever migration. South isn't going to be the problem -- the problem is that the Django ORM is going to notice that there are fields present in the SQL table that aren't specified in the code, which will cause it to throw an exception.
Since you use a hack to patch up the model, I think you should write a migration manually. Try copying another migration and changing add_column and models first, if it fails - there is always an option named "raw sql" :)
I've ported my GAE project to django-nonrel, and now I would like to have link from my object to Django User object:
class Opinion(google.appengine.ext.db.Model):
...
author = db.ReferenceProperty(django.contrib.auth.User)
Unfortunately, that's not possible, since you only can link GAE models this way.
Question - what's the best way to solve this? Is it possible or should I work it around somehow?
I don't want to migrate my old GAE model since I already have a bunch of data there.
My initial googling and searching brought me nothing good:
On django-nonrel list I read:
You cannot use appengine model into django-nonrel. You need alter all
your models to django proper. That is, use original
django-registration app not the appengine-patch provided registration.
Another question, exactly like mine, was left unanswered.
... and I've found another place where people recommend switching to Django models.
I guess that's that then, there is no way of doing what I need, one needs to migrate.
I have a live Django site that already has registered users. I am trying to update the site with a new version that is different from the original site -similar idea but different models.
How can I keep the current users on the new site?
I have heard South may be a good solution, but the old site doesn't have it installed. Is it possible to use South in this case?
Thanks for the help!
yes http://south.aeracode.org/docs/convertinganapp.html#converting-an-app
+1 to South, but...
We need more information! Are you doing radical changes to your Models, or just adding or removing fields here or there?
South can handle some pretty radical migrations, but you'll have to write some custom migration code. Personally, I use South if I'm adding a new field, but not for this kind of more radical stuff.
If it's a big Schema change, completely re-organizing your site, then I'd just write your own script to read the old objects, and create the new ones. Make a copy of your production database (via pg_dump, mysqldump, etc.) and load it on to your local machine, where you can test and debug the custom conversion script. Make sure your "old models" and "new models" have different names, and keep everything in your settings.py so that you can always read & write everything.
Write & test the migration script, and after that works, you can create another changelist to delete all the old objects, and then remove their corresponding source code if you want.