Consider I have a DB with some initial data loaded using data migrations. Since the initial loading, the data has been further changed by users of the app via the website. Of course, these changes are not recorded in additional data migrations since they happen in realtime. So the data migrations are somewhat redundant since they don't capture all the changes made by the users.
Now, I want to deploy the app onto a new server and DB. So I take a dump of the current database, then log onto the new server and use the dump to initialize the new DB. What I'm confused about is: if I then run the aforementioned data migrations on the new DB, they will add redundant outdated data, no?
More generally, my confusion lies in how to make data migrations and db dumps work together when deploying an existing web app onto a new server+DB. Is there a better way to think about this?
The dump will include the tables used by migrations to keep track of where the database is in terms of running your migrations. Your new database is going to be at the same place (in terms of migrations) as your current database.
Simply put, if you run
python manage.py migrate
On the new server hooked up to the new databased after you "restore" the data, it'll say there isn't anything to run.
Related
currently I am using PostgreSQL database in my project but I also want to use SQLite for localhost, so I want to run migrate command but there are errors because in SQLite array field is not used so I want to convert array field to JSONfield and makemigrations but in migrations old migrations also present. S I want to write custom logic in migrations. So, it use old migrations when database is PostgreSQL and new migrations when it is sqlite3.
I don't want create new migrations and migration table every time I switch databases.
SQLite is more of a flat file system. I think the original idea is that you can store a small amount of data on a device and update the main database, or fetch info from a database, when the device is 'idle' as a background process. I know there may be some people putting this comment down but essentially SQLite is 'Light' and a flat file. Those considerations should be taken into account. btw I see that there is MYSQL for Andriod but I have not tried it out.
I migrated a database that was manipulated via SQL to use Django's migration module: https://docs.djangoproject.com/en/3.0/topics/migrations/.
Initially I thought of using migrations only for changes in the model such as changes in columns or new tables, performing deletes, inserts and updates through SQL, as they are constant and writing a migration for each case would be a little impractical.
Could using the migration module without using data migrations cause me some kind of problem or inconsistency in the future?
You can think about data migration if you made a change that required also a manual fix on the data.
Maybe you decided to normalize something in the database, e.g. to split a name column to the first name and the last name. If you have only one instance of the application with one database and you are the only developer then you will also not write a data migration, but if you want to change it on a live production site with 24 x 7 hours traffic or you cooperate with other developers then you probably prepare a data migration for their databases or you will thoroughly test the migration on a copy of live data that the update will work on the production site correctly without issues and with minimal shutdown. If you don't write a data migration and you had no problem immediately then it is OK and will be not worse then a possible ill-conceived data migration.
I have two different databases in django. Initially, I had a table called cdr in my secondary database. I decided to get rid of the second database and just add the cdr table to the first database.
I deleted references (all of them, I think) to the secondary database in the settings file and throughout my app. I deleted all of the migration files and ran make migrations fresh.
The table that used to be in the secondary database is not created when I run migrate even though it doesn't exist on my postgres database.
I simply cannot for the life of me understand why the makemigrations function will create the migration file for the table when I add it back in to the model definition and I have verified that it is in the migration file. When I run migrate, it tells me there are no migrations to apply.
Why is this so. I have confirmed that I have managed=True. I have confirmed that the model is not on my postgres database by logging into the first database and running \dt.
Why does Django still think that this table still exists such that it is telling me no migrations to apply even though it shows a create command in the migrations file? I even dropped the secondary database to make sure it wasn't somehow being referenced.
I suspect code isn't needed to explain this to me but I will post if needed. I figure I am missing something simple here.
Why does Django still think that this database still exists such that
it is telling me no migrations to apply even though it shows a create
command in the migrations file
Because django maintains a table called django_migrations in your database which lists all the migrations that have been applied. Since you are almost starting afresh, clear out this table and then run the migrations.
If this still doesn't work and still assuming that you are still on a fresh start, it's a simple matter to drop all the tables (or even the database and do the migration again). OTH that you have data you want to save, you need to look at the --fake and --fake-initial options to migrate
I'm pretty new to Django and it's deployment on Heroku.
I've got a Postgres database up and running on the app server. My app requirements need me to add a new column to my existing database which has a sizable amount of data in it, which I can't lose.
Looking around, I found a solution described by Mike Ball here.
I have the following queries though:
What exactly is South? (I read the docs but didn't get a clear idea)
Will it help me save and move my existing data from my current database?
As a complete newbie, is the above link an easy way to move the data?
Also, in general, if you could hook me up with a good guide for general DBMS concepts, I'd be very grateful.
Thanks!
What exactly is South? (I read the docs but didn't get a clear idea)
south migrates your database schema as it changes in time. the schema has to start with a django models.py file. If you use 'manage.py syncdb ...' to create your database then you can probably use south.
Will it help me save and move my existing data from my current database?
As long as you used syncdb to create your database using a models.py file in django, then south can change that database and add the new column. basically, south records the changes you make to the models.py file in migration files, then you can apply those migration files to your database which update it non-destructively.
As a complete newbie, is the above link an easy way to move the data?
south doesn't move your data. it allows you to add the new columns to your existing database without destroying the database. to move your data you will need to backup the data to a file, then copy the file to another machine, then restore the backup. That's not what south does.
I'm now making unit-tests for already existing code. I faced the next problem:
After running syncdb for creating test database, Django automatically fills several tables like django_content_type or auth_permissions.
Then, imagine I need to run a complex test, like check the users registration, that will need a lof ot data tables and connections between them.
If I'll try to use my whole existing database for making fixtures (that would be rather convinient for me) - I will receive the error like here. This happens because, Django has already filled tables like django_content_type.
The next possible way is to use django dumpdata --exclude option for already filled with syncdb tables. But this doesn't work well also, because if I take User and User Group objects from my db and User Permissions table, that was automatically created by syncdb, I can receive errors, because the primary keys, connecting them are now pointing wrong. This is better described here in part 'fixture hell', but the solution shown there doensn't look good)
The next possible scheme I see is next:
I'm running my tests; Django creates test database, makes syncdb and creates all those tables.
In my test setup I'm dropping this database, creating the new blank database.
Load data dump from existing database also in test setup
That's how the problem was solved:
After the syncdb has created the test database, in setUp part of the tests I use os.system to access shell from my code. Then I'm just loading the dump of the database, which I want to use for tests.
So this works like this: syncdb fills contenttype and some other tables with data. Then in setUp part of tests loading the sql dump clears all the previously created data and i get a nice database.
May be not the best solution, but it works=)
My approach would be to first use South to make DB migrations easy (which doesn't help at all, but is nice), and then use a module of model creation methods.
When you run
$ manage.py test my_proj
Django with South installed with create the Test DB, and run all your migrations to give you a completely updated test db.
To write tests, first create a python module calle, test_model_factory.py In here create functions that create your objects.
def mk_user():
User.objects.create(...)
Then in your tests you can import your test_model_factory module, and create objects for each test.
def test_something(self):
test_user = test_model_factory.mk_user()
self.assert(test_user ...)