We Keep Coding

how to do migrations dynamically in django?

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...

Django Migrate Change of App Name (active project)

So... I've done a lot of research on this... there are answers, but not complete or appropriate answers. I have an in-use and in-production django "project" in which the "main" application is called "pages" ... for reasonably dumb reasons. My problem is now to add mezzanine ... which has a sub-module mezzanine.pages (seems to be required .... but I'm pretty sure I need it).
mezzanine.pages apparently conflicts with "pages" ...
Now ... my pages contains a slew of non-trivial models including one that extends user (One-to-One ref), and many references to other app's tables (fortunately only outbound, ForeignKey). It also has management/commands and about 20 migrations of it's own history.
I gather I either have to changes pages to mypages or is there another route (seemingly changing mezzanine.pages seems wrong-headed).
for reference, The project is on Django 1.8 right now, so the preferred answer includes migrations.

I've worked on this since I posted it, and the real answer is what I've synthesized from multiple sources (including other stack exchange posts).
So... Everything changed in Django before I started using it. After 1.7, the 'migrations' bit was internalized and posts including the word "South" are about how the world was before 1.7. Further, the complication in my case dealt with the issue of migrations in that the project was already active and had real data in production.
There were some posts including a GITHub chunk of code that talked about migrating tables from one App to another App. This is inherently part of the process, but several posts noted that to do this as a "migration" you needed the Migration.py to be in another App. Maybe even an App created for the purpose.
In-the-end, I decided to approach the problem by changing the label in the Application class of apps.py in the application in question. In my case, I am changing "pages" to "phpages" but the directory name of my app is still pages. This works for me because the mezzanine app's "pages" sub-App is back in the python library and not a conflict in the filesystem. If this is not your situation, you can solve it with another use of label.
So... Step-by-step, my procedure to rename pages to phpages.
Create apps.py in the pages sub-directory. In it put:
class PagesConfig(AppConfig):
name = "pages"
label = "phpages"
verbose_name = "Purple Hat Pages"
Key among these is label which is going to change things.
In __init__.py in the pages sub-directory, put default_app_config = "pages.apps.PagesConfig"
In your settings.py change the INSTALLED_APPS entry for your app to 'pages.apps.PagesConfig', ...
All of your migrations need to be edited in this step. In the dependencies list, you'll need to change 'pages' to 'phpages'. In the ForeignKeys you'll need to also change 'pages.Something' to 'phpages.Something' for every something in every migration file. Find these under pages/mitrations/nnnn_*.py
If you refer to foreign keys in other modules by from pages.models import Something and then use ForeignKey(Something), you're good for this stop. If you use ForeignKey('pages.Something') then you need to change those references to ForeignKey('phpages.Something'). I would assume other like-references are the same.
For the next 4 steps (7, 8, 9 and 10), I built pagestophpages.sql and added it to the pages sub-directory. It's not a standard django thing, but each test copy and each production copy of the database was going to need the same set of steps.
UPDATE django_contecnt_type SET app_label='phpages' WHERE app_label='pages';
UPDATE django_migrations SET app='phpages' WHERE app='pages';
Now... in your database (my is PostgreSQL) there will be a bunch of tables that start with "pages". You need to list all of these. In PostgreSQL, in addition to tables, there will be sequences for each AutoField. For each table construct ALTER TABLE pages_something RENAME TO phpages_something; For each sequence ALTER SEQUENCE pages_something_id_seq RENAME TO phpages_something_id_seq;
You should probably backup the database. You may need to try this a few times. Run your SQL script through your database shell. Note that all other changes can be propagated by source code control (git, svn, etc). This last step must be run on each and every database.
Obviously, you need to change pages and phpages to your stuff. You may have more than one table with one auto field and it may not be named something.
Another thing of note, in terms of process, is that this is probably a hard point in your development where everything needs be in sync. Given that we're playing with editing migrations and changing names, you need a hard stop in development so that everything that's going to be changed (dev box, test box, staging box, production box ... and all of their databases) is at the same revision and schema. YMMV.
This is also solving the problem by using the label field of class Application. I choose this method in deference to changing the directory name because it involved fewer changes. I chose not to change the name field because that did not work for me. YMMV.
I must say that I'm a little disappointed that myapp/pages conflicts with mezzanine.pages. It looks like some of the reasons are due to the pages slug being used in the database table name (and off top of my head, I don't see a good solution there). What I don't see that would make sense is the equivalent to "from mezzanine import pages as mpages" or somesuch. The ability to alias imported apps (not talking about apps in my own file tree). I think this might be possible if I sucked in the app into my own file tree --- but this doesn't seem to be a sanctioned act, either.

Migrating a custom user model onto an existing user model

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!

django structure for multiple modules

I'm very new to django and python as well. I want to try out a project written in django.
Let say the project have 3 modules
User
CRUD
Forgot password
login
Booking
CRUD
Search
Default (basically is for web users to view)
Home page
about us
All these have different business logic for the same entity.
Should I create 3 apps for this? If 3 different apps, then the table name is all different as it will automatic add a prefix for table name.
Any suggestion?

There's really no correct answer to this. In general, the way in which you break down any programming task into 'modules' is very much a matter of personal taste.
My own view on the subject is to start with a single module, and only break it into smaller modules when it becomes 'necessary', e.g. when a single module becomes excessively large.
With respect to the apps, if all the apps share the same database tables, you'll probably find it easier to do everything in a single app. I think using multiple Django apps is only really necessary when you want to share the same app between multiple projects.

I agree in #aya answer and I also supported your structure for multiple modules. In my project, I created 18 apps. Each app perform different rules:
1. accounts
- login
- forgot password
- register
- profile
2. common
//in here all the common function use by different apps
3. front
- home
- testimonial
4. guides
//tutorials
And lots more apps...
I arrange this way so that it will be easy to trace, debug, and find the codes. If your problem is the name of table you can set the class Meta of db_table.

I am relatively new to Django and Python myself too. In practice, try to have your Django apps do one thing and do it well. If you find that an app is becoming more and more complex, it may be worth splitting this out into multiple apps.
I would not worry about the DB tablename as Django handles the DB interaction for you. If you name your apps and models well, your code should be fairly self documenting.
I have recently learnt a lot of "best practices" in how to setup and layout Django projects from the ebook 2 Scoops of Django. I am not affiliated with them in any way, but have just learnt a lot from it.
Also, definitely run through the Django tutorial if you haven't already.
Hope this has helped!

Focus on making your apps reusable. This way you will save significant number of time in your next project. Good article about it is available at the Django's website.
If you have closely integrated modules or depending on each other, then there's no real benefit of having them in separate apps, because you won't ever use them separately. Organizing in separate Python modules will be just fine.
Also do not think about "how will my tables be named" when you consider project organization. Tables can be easily renamed while bad design will make you trouble as the project will grow.

Creating migrations for auth app in django

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" :)