Re: Best practice for databases and distributed development with Django
I'm surprised to see this suggestion of storing a SQLite db in version control. Don't you quickly run into problems where two developers each write new data to the database, and then cannot merge their changes? Or do you have a read-only database? --Ned. http://nedbatchelder.com/blog Brian Luft wrote: > Simon's method is a good way to go. In general its a good idea to use > some sort of scheme for managing all of the changes that occur to the > base schema in revision control. This way you can pull down a tagged > copy of your source tree, run the CREATE DATABASE script, and run the > alter script(s) associated with that revision so that you can create > the appropriate schema for any point in time. This is a discussion > unto itself, but hopefully you get the idea. > > Another "less hassle" alternative you might consider is to use a > sqlite database. Create the database file in your project root. Then > in your settings file do something like: > > DATABASE_NAME = os.path.join(os.path.dirname(__file__), 'data', > 'our_database.db') > > Now you will be keeping your entire database in a file that will be > managed by revision control. One potential disadvantage is that > you'll be working with the same exact data (at least from the moment > you do an "update" and receive a new version of the sqlite database > file). But if you're in the early stages of development, this > presents an easy way for other developers to receive any changes you > make to the schema without having to worry about applying SQL scripts > and dealing with any possible data transformations. I wouldn't call > this a "best practice" per se - more of a "simple" practice you can > take advantage of until your schema stabilizes. At that point in time > just do the "manage dumpdata/loaddata" dance to get your data out of > sqlite and into your DB of choice. > > -Brian > > On Apr 2, 9:04 pm, Simon Oberhammer <[EMAIL PROTECTED]> > wrote: > >>> that developer has to inform all others of the changes so they all >>> make the change manually on their own local database. >>> >> you could have a mysql-changes.sql file in your app directories. it >> holds the ALTER, DROP, etc. statements. put it under SVN. when you get >> a new rev with the comment "db changed blabla", look at the diff to >> see what changes need to get applied to the DB. >> > > > > -- Ned Batchelder, http://nedbatchelder.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for databases and distributed development with Django
andy baxter wrote: > > Not sure if it's quite an answer to your question, but I've been dealing > with a similar problem which is how to keep the test data I've added to > the system between (mostly minor) changes to the database. The approach > I've taken is as follows: > > - before making any changes use 'mysqldump -c -n -t databasename -p > > dumpfile.sql' to dump the data only from the database, with column names > included. > - then clear the database using ./manage.py sqlclear > - then change the model in models.py > - then recreate the database structure using ./manage.py syncdb > - then re-import the data using 'mysql -p -f databasename < > dumpfile.sql' (try first without -f to check for errors). > > This seems to work pretty well for minor changes - e.g. making a field > allow nulls, or adding a new non-relational field. > > andy. > > Since writing the above, I've realised manage.py has a dumpdata command, which would probably be better for doing this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for databases and distributed development with Django
Julien wrote: > Hi, > > We're using SVN between several developers to work on the same project > and it's working quite well. But it's not as simple concerning the > database. > > Each of us has a local database to muck around with, and if one of us > makes a change in the models that implies modifying the database > manually (e.g. renaming a field, changing the type or the field, etc.) > that developer has to inform all others of the changes so they all > make the change manually on their own local database. > > Having a common database would avoid that, but that's not ideal since > an online database would be slower to access, and it could quickly go > out of control if many people add records or change the database > structure at the same time. > > So, I just wanted to get some advice from you as to what is the best > approach to go? > Not sure if it's quite an answer to your question, but I've been dealing with a similar problem which is how to keep the test data I've added to the system between (mostly minor) changes to the database. The approach I've taken is as follows: - before making any changes use 'mysqldump -c -n -t databasename -p > dumpfile.sql' to dump the data only from the database, with column names included. - then clear the database using ./manage.py sqlclear - then change the model in models.py - then recreate the database structure using ./manage.py syncdb - then re-import the data using 'mysql -p -f databasename < dumpfile.sql' (try first without -f to check for errors). This seems to work pretty well for minor changes - e.g. making a field allow nulls, or adding a new non-relational field. andy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for databases and distributed development with Django
On Thu, Apr 3, 2008 at 4:27 AM, Ronny Haryanto <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 3, 2008 at 7:36 AM, Julien <[EMAIL PROTECTED]> wrote: > > We're using SVN between several developers to work on the same project > > and it's working quite well. But it's not as simple concerning the > > database. > > > > Each of us has a local database to muck around with, and if one of us > > makes a change in the models that implies modifying the database > > manually (e.g. renaming a field, changing the type or the field, etc.) > > that developer has to inform all others of the changes so they all > > make the change manually on their own local database. > > > > Having a common database would avoid that, but that's not ideal since > > an online database would be slower to access, and it could quickly go > > out of control if many people add records or change the database > > structure at the same time. > > > > So, I just wanted to get some advice from you as to what is the best > > approach to go? You might want to checkout the django-evolution application. http://code.google.com/p/django-evolution/ -christos --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for databases and distributed development with Django
On Thu, Apr 3, 2008 at 7:36 AM, Julien <[EMAIL PROTECTED]> wrote: > We're using SVN between several developers to work on the same project > and it's working quite well. But it's not as simple concerning the > database. > > Each of us has a local database to muck around with, and if one of us > makes a change in the models that implies modifying the database > manually (e.g. renaming a field, changing the type or the field, etc.) > that developer has to inform all others of the changes so they all > make the change manually on their own local database. > > Having a common database would avoid that, but that's not ideal since > an online database would be slower to access, and it could quickly go > out of control if many people add records or change the database > structure at the same time. > > So, I just wanted to get some advice from you as to what is the best > approach to go? For our last project (not Django, unfortunately), we created a directory that holds SQL changes files. The files were named "from-1234.sql" where 1234 is the current svn revision when the file was created. Everytime we made a change to the database model, we modified the main sql file (equivalent to models.py in django), then we also created an SQL change file containing all the changes (alter, drop, etc.), then we ran the SQL change file to actually modify the database instead of modifying the database directly. Other developers would need to pay attention for additions in the SQL changes directory and update their database accordingly whenever there's a new file there. Ronny --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for databases and distributed development with Django
Simon's method is a good way to go. In general its a good idea to use some sort of scheme for managing all of the changes that occur to the base schema in revision control. This way you can pull down a tagged copy of your source tree, run the CREATE DATABASE script, and run the alter script(s) associated with that revision so that you can create the appropriate schema for any point in time. This is a discussion unto itself, but hopefully you get the idea. Another "less hassle" alternative you might consider is to use a sqlite database. Create the database file in your project root. Then in your settings file do something like: DATABASE_NAME = os.path.join(os.path.dirname(__file__), 'data', 'our_database.db') Now you will be keeping your entire database in a file that will be managed by revision control. One potential disadvantage is that you'll be working with the same exact data (at least from the moment you do an "update" and receive a new version of the sqlite database file). But if you're in the early stages of development, this presents an easy way for other developers to receive any changes you make to the schema without having to worry about applying SQL scripts and dealing with any possible data transformations. I wouldn't call this a "best practice" per se - more of a "simple" practice you can take advantage of until your schema stabilizes. At that point in time just do the "manage dumpdata/loaddata" dance to get your data out of sqlite and into your DB of choice. -Brian On Apr 2, 9:04 pm, Simon Oberhammer <[EMAIL PROTECTED]> wrote: > > that developer has to inform all others of the changes so they all > > make the change manually on their own local database. > > you could have a mysql-changes.sql file in your app directories. it > holds the ALTER, DROP, etc. statements. put it under SVN. when you get > a new rev with the comment "db changed blabla", look at the diff to > see what changes need to get applied to the DB. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best practice for databases and distributed development with Django
> that developer has to inform all others of the changes so they all > make the change manually on their own local database. you could have a mysql-changes.sql file in your app directories. it holds the ALTER, DROP, etc. statements. put it under SVN. when you get a new rev with the comment "db changed blabla", look at the diff to see what changes need to get applied to the DB. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
