I'm in the initial phase of development, and the models are changing around quite a lot.
I have to keep dropping the old tables and then performing a "syncdb"
While I appreciate the reason why syncdb does not alter the old tables,
Is it possible (or is there any other alternative) to drop the old tables automatically and then run syncdb?
They way I typically do this is at the database level. If, for example, you were using postgres, and just wanted to blow away the whole DB to start fresh, you could do:
dropdb -U postgres "dbname"
createdb -U postgres -O "db_user" "db_name"
For long projects I'm working on, I use a fabfile for automating tasks like the above, as well as grabbing the latest database from my production server, and overwriting my local development db.
Also, related is database "migration", which becomes a requirement when you change code after it's been running in production a while. A lot of people / apps use South, but I prefer Nashvegas for my sites.
With Nashvegas, I would create a 0001_add_field_blah.sql file which contained my raw SQL commands for altering the db. eg:
ALTER TABLE myapp_model RENAME COLUMN first_name TO given_name;
I use python manage.py reset <app>. I don't think there's a way to do it project-wide though.
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.
All I did was add a field to a model, and now I get an error that says this column does not exist.
In an attempt to rebuild the database I used -flush (i dont care about losing the data), thinking this would rebuild the database, but I still get the same error.
I was told by someone else to use South because I'm running Django 1.6.
I followed the tutorial and literally the first time I ran syncdb, I got the following (probably unrelated) error:
dist-packages/easy-thumbnails/
raise Improperly_Configured(SOUTH_ERROR_MESSAGE)
django.core.exceptions.ImproperlyConfigured:
For South Support, customize the SOUTH_MIGRATION_MODULES setting like so:
South_Migration_Module = {
'easy_thumbnails': 'easy_thumbnails.south_migrations',
}
Ultimately all I want to do is have my db reflect my models. Back when I was working on this project in my dev environment I would literally just drag my sqlite file to the trash and then run syncdb, but I cannot do that now because I'm using postgres.
So my question is how can I accomplish this seemingly simple task? Whether that means addressing the South error, or just not using South altogether (which I would prefer), I would appreciated any help.
You can manually open up a db shell (>>> python manage.py dbshell) and drop the table with DROP TABLE <table_name>;. In order for syncdb to recreate a table with the new field, it is not enough to empty the table.
To solve the error, just do exactly what it says: add the SOUTH_MIGRATION_MODULES setting to your settings.
With that said, I'd definitely advice you to use south. It eases making changes to your models, and it allows you to preserve test data in your development environment that you'd otherwise have to recreate. That's all nice, but when your project goes live, it is absolutely mandatory that your data is preserved when making a change to your models. South is the best tool for that.
South has been such an integral part of pretty much any Django project, that Django has worked together with the developers of South to include it as a core feature from Django 1.7 onwards.
Can any one explain the use of sqlclear ?.I have read the docs
The way you would use this type of command is when you are doing initial prototyping of an application. During this phase, before any releases have been done, you're pretty free to iterate over the data model. manage.py gives you the ability to automatically create the data model from the python model with no additional steps, so the sqlclear command gives you the ability to generate (and run if you want) sql that resets the database to the state it was in before you installed the app.
As a developer, it's always nice to have a repeatable process to create a clean development environment. As another developer suggested, you can pipe the output of this directly into mysql:
python manage.py sqlclear <<YOURAPPNAME>> | mysql --user=<<YOURDBUSERNAME>> --password=<<YOURDBPASSWORD>> <<DBNAME>>
This is just one possible reason to use this command.
I suppose the idea is, along with the other sql.. commands, to be able to easily add, edit, delete, or recreate the tables that Django puts in by default when you do a syncdb. This could help with database migration, removing an app from a shared database, or whenever you need to do anything else to the database but can't just drop the entire database and start over.
Although I'm open to other points : ), This was always my impression.
I pipe the output from sqlclean to mysql to clean (or reset using sqlreset) the database
python manage.py <<appname>> sqlclean | mysql <<databasename>>
Regards,
Raggi
So I backed up my geodjango postgis database using pg_dump before performing some calculations which I've managed to mess up. I've created a new database using
createdb -T template0 -O proj proj_backup
psql proj_backup < proj_backup.pg
This seemed to work fine (though there were a few errors during the import), and connecting to the database using psql all my tables are there and appear to have the correct numbers of rows etc.
However, changing my settings.py to connect to my newly imported backup db (proj_backup in my example), gives me the following errors:
DatabaseError: relation "appname_model" does not exist
Any ideas? I'm guessing I did the dump wrong, or that I haven't maintained the ForeignKeys somehow. Thanks very much.
Update
So I figured out my first mistake: I had two similarly named backup databases and connected to the wrong one. Connecting to the correct one seems to have fixed everything. However, it's still quite strange that it didn't recognize the tables in the other backup database, which definitely did exist. Running syncdb on the incorrect database ends up duplicating those tables (if I remember correctly, there were duplicate table names when I listed them all from within psql). Unfortunately, the way I discovered my mistake was by dropping the bad table to recreate it, and so in order to reproduce this error I'll probably have to use time machine. Still very strange, I'll give that a shot when I can get physical access to my work machine.
So is your appname_model table there or is it a view? Was it in public or another named schema?
If the table is there, then chances are you have it in a schema that is not in your database search path. Check the search_path of your old database. It might have included something other than the default, or your default search schema is set in postgresql.conf and is non-standard.
In my Django app, I just ran
$ python manage.py sqlall
and I see a lot of SQL statements that look like this, when describing FK relationships:
ALTER TABLE `app1_model1` ADD CONSTRAINT model2_id_refs_id_728de91f FOREIGN KEY (`model2_id`) REFERENCES `app1_model2` (`id`);
Where does "7218de91f" come from? I would like to know because I'd like to manually write SQL statements to accompany models changes in the app so that my db's can be kept up to date.
Why not use a migration app to write all your SQL for you. It's definitely the smart way to go. Check out South -- part of it will be merged into Django core soon