I am working on an app at Django 1.9
I created altered one field from User model (max_length to 120 from 40).
I know the migration has not run and i can see that it is skipped obviously.
I can't seem to understand why this is happening.
I made sure that the dependencies are in place as well.
Things i tried:
1- Verified that the database does not say it as run(django_migrations table):
See there is no 0021_alter_user_lms_user_id
2- i check if django is able to see migration file:
I am very surprised with this outcome.
I cannot purge my migrations nor the database because this is a deployed app with data.
Any help is appreciated
Note: I checked all related questions i could find before posting this question.
I fixed it myself and hoping this helps others experiencing same or similar issue with Django.
It seems like Django does not just check whether a migration has run by file name but also it pays attention on the order of the file by the leading numbers in filenames(At least in my experience).
History of steps:
git branch a: creates migrations for 0021_alter_user_lms_user_id and has not been merged into master yet.
git branch b: created migration for 0022_toolconsumer_is_vericite_enabled (thinking i should follow the order and manually prefix file name with 0022_)
Now at this point i merge git branch b into master and run migrations.
So now when i merge git branch a into master and want to run migrations, django sees file but since 0022_ is supposingly after 0021_, skips the file instead actually checking whether it is applied to db.
Fix: I basically renamed file name from 0021_alter_user_lms_user_id to 0023_alter_user_lms_user_id(don't forget to update dependencies ) and ran ./manage.py migrate and worked with no issues. See the image.
Hope this helps somebody.
I am working with some other developers on a website (using Django) and as it is a new site and the database schema is constantly changing. We are using South for schema migration but are running into the issue where each of us have our own branch checked out and are working on our own separate part of the project. When the code is merged back in very often there have been multiple migrations generated for the same model (there might be three migrations with id 003 for model A).
It seems like South is pretty good about managing conflicts when they relate to different models:
http://south.readthedocs.org/en/latest/tutorial/part5.html#team-workflow
But when dealing with the same model it gets a little messy manually creating the merged migration.
I was wondering if there was any better way of doing this or a better tool than South.
One idea I have is for no one to check in the migration files and just check in the model changes directly to git. That way every person would just run their own migrations and won't have to worry about conflicts. Not sure if that is a good practice...
I am curious how other people are managing these situations.
Thanks:)
From the South documentation:
Make sure your team know who is working on what, so they don’t write migrations that affect the same parts of the DB at the same time.
So that's the thing you shouldn't do: don't create migrations that affect the same model unless you're sure you're able to merge them later into the main development trunk. A tool can't figure out what the right database schema needs to be when two developers modify the same field of a model.
In that case you'll need to manually fix migrations and get the model fields in order. This could mean migrating back and constructing a new migration before merging the branch with the trunk.
I want to create the admin for some tables of an existing MySQL dabatase. I want to use Django since it is just one line of code - admin.site.register(TableName) - so I save a lot of time coding the admin from scratch. I looked here for the inspectdb option of Django https://docs.djangoproject.com/en/1.5/howto/legacy-databases/ but only in the development version https://docs.djangoproject.com/en/dev/howto/legacy-databases/ says something about managing the inspected model. I want to know if it is possible and if somebody tried to work with an existing database before but not for read only, I want to manage and edit these database from my Django application.
If you're not using the development version, don't read the docs for that version. All they say is that - new in that version only - models created via inspectdb will by default be marked as managed = False, which means that they can't be modified. But the docs go on to describe exactly how you can modify them, simply by changing that setting.
But of course, you should be using the latest stable version, 1.5, which doesn't do that anyway. You can add and edit items in models from a legacy db to your heart's content.
I've recently begun using South for migrations in my Django project. All was going well until recently when I ran into a peculiar issue.
I have two apps in my project, say, App-A and App-B. A model in App-A has a foreign key to a model in App-B. When I've been trying to build my system, I ran syndb which created all the auth_ and the south_ tables. Then I ran migrate which threw up errors. When it tried creating the model from App-A, which referenced a model from App-B, the model App-B wasn't migrated/created as yet and therefore the error.
In order to resolve this, I had to manually migrate App-B first and then App-A. Am i doing something wrong here? How is South supposed to know the migration order across apps?
Thanks.
This explained it https://south.readthedocs.io/en/latest/dependencies.html.
Migrations for apps are nice ‘n all, but when you start writing a
large project, with a lot of apps, you realise you have foreign key
relationships between apps and working out what order migrations would
need to be applied in for each app is just painful.
Luckily, we also had this problem, so South has a dependency system.
Inside a migration, you can declare that it depends on having another
app having run a certain migration first; for example, if my app
“forum” depends on the “accounts” app having created its user profile
table, we can do:
# forum/migrations/0002_post.py class Migration:
depends_on = (
("accounts", "0003_add_user_profile"),
)
def forwards(self):
Then, if you try and migrate to or beyond 0002_post in the forum app, it will first make sure accounts is migrated at least
up to 0003_add_user_profile, and if not will migrate it for you.
Dependencies also work in reverse; South knows not to undo that
0003_add_user_profile migration until it has undone the 0002_post
migration.
You can have multiple dependencies, and all sorts of wacky structures;
there are, however, two rules:
No circular dependencies (two or more migrations depending on each
other) No upwards dependencies in the same app (so you can’t make
0002_post in the forum app depend on 0003_room in the same app, either
directly or through a dependency chain.
South migrates apps in the order they appear in the INSTALLED_APPS tuple in settings.py. So just make sure App-B comes before App-A in your settings.py, and it should work :)
I'm a beginner to Python and Django.
When starting a new project what do you do first before diving into the code?
For example, one could take the following steps:
Configure the settings.py file first
Configure models.py to lay out data structure
Create template files
Define the views/pages
Syncdb
etc
So my question is, what is a good workflow to get through the required steps for a Django application? This also serves as a checklist of things to do. In the definitive guide to Django, the author talks about approaching top down or bottom up. Can anyone expand further on this and perhaps share their process?
Thanks.
Follow the Agile approach. Finish one small case, from the start to the end. From the models to the tests to user experience. Then build on it. Iterate.
Thats the right way to software development.
To do it efficiently, you need: (don't bother right away, you will need it.)
Automated schema migration, automated build system, auto updating and deployment. - None of these, django has got anything to do with. Use pip, fabric, hudson, twill and south appropriately.
Take care not to over burden yourself with all these right away, particularly since you say, you are beginning.
the required steps for a Django application?
There are two required steps.
Write the settings. Write the urls.py
The rest of the steps are optional.
This also serves as a checklist of things to do.
Bad policy. You don't need a checklist of Django features. You need a collection of use cases or user stories which you must implement.
For some reason, you've omitted the two most important and valuable features of Django. Configure the default admin interface and write unit tests. The default admin interface is very high value. Unit testing is absolutely central.
You do it like this.
Gather use cases.
Prioritize the use cases.
Define the actors. The classes of actors becomes groups in the security model.
Define enough "applications" to satisfy the first release of use cases. Define the url structure. Cool URL's don't change.
Build the first use case: models (including security), admin, urls, tests, forms, views and templates. Note that these are the file names (models.py, admin.py, ...) except for templates. Also note that forms and admin should be defined in separate modules even though this isn't required. Also note that templates will be split between a generic templates directory for top-level stuff and application-specific templates.
Build the second use case: models (including security), admin, urls, tests, forms, views and templates.
...
n. Package for release. Tweak up the settings. Configure database and mod-wsgi
I personally can't make a template without writing the views (unless it's a photoshop draft) but in general that's the way I go after I have a plan.
What's extremely important for me is that I don't dive head-first into the code, and that I spend time mocking up the model structure based on the "screens" or "pages" that the user will see.
Once I have a user experience defined, I make sure the backend is robust enough to handle that experience. If I don't visualize the user experience, details get left out that are certainly accomplishable in the shell but not ideal for the website, default django admin, etc.
There are always tradeoffs between agile development and a huge spec: I think there's an important balance. Agile is good: there's no point planning every detail before writing your first line of code, as your needs will change by the time you get to the end. You don't know how your users will really use the site.
On the other hand, without a plan, you can end up with a messy foundation that affects all future code.
An educated guess is a good start. Don't think or assume too much, but definitely have a clear idea how your users will interact with your site for stage 1.
Always try to remember about a DRY rule. For example, why to write RequestContext every new view is defined, where you can simply write a function once, which will add it for you. Good description is here in another topic.
Try to keep a code written one way. Each time you upgrade a schema of your view, edit it in all already written views. That will help keep your code clear and save a lot time for you in future.
Generally good rule, and how do I write my applications is the rule of small steps. Start with writing a settings and urls, then add one model and one view. When it works, modify - add another models or another views. You won't even notice, when your project becomes bigger and bigger.
And the last useful rule for clarity of all the source. Keep files in folders. If you have two subsites based one one (for example "accounts" and "blogs") create two directories names the same. Remeber to put init.py file in each directory. It's really easy to forget. With this practice it's easy to write models and views dedicated to each category. By the way it's a good practice to keep urls like in a tree structure. Main urls.py should contain only links like this one:
(r'^accounts/', include('your_main_name.accounts.urls')),
and of course all media, static, css and so on. In accounts directory urls keep:
urlpatterns = patterns('your_main_name.accounts.views',
url(r'^$', 'index', name='index'),
)
with all views subdirectories.
Last one - keep code clear with actuall django version. Remeber, that the 3.0 release is comming soon.
Hope this will help.
I find that my process varies depending on a lot of variables, mainly whether I know something will work or if I'm experimenting and also whether I'm developing on my production server or in a development environment.
For example, I often do my development directly on the deployment server (most of my work is for intranet projects so there isn't any security risk, etc). But when I do this I really need to make sure the settings and urls are setup first and that gunicorn and nginx are configured.
If I know something should work, or am setting up a generic base set of code, sometimes I'll do all that coding for views and models before I even get enough setup to even run the development server. But when experimenting with new code I find it's good to be able to test every step of the way, so in that case you need your servers running.
In general I do settings, models, syncdb, views, urls, templates, collectstatic, graphics/aesthetics
In general I leave my base.html very plain until the everything else is working, then I add css/js etc.
I guess my point here is that there isn't really a wrong answer for how you do it, and there isn't even only one best practice (as far as I'm concerned). When you do more work, you'll find what you are comfortable with and it'll even vary from project to project.
Good luck, hopefully you learn to love django!
here is something I do in general,
configure basic settings
configure root url.py
configure settings, url.py for static (media) files
create model
sync db
write views (use simple template, if needed)
once you are done with back end implementation
think about UI
prepare styles, scripts
start working on template implementation