Re: Migrations, commands and syncdb

Yes, the large number of weird things people need custom SQL for is why I want to push for migrations much more overall - especially for cases like post_syncdb (should be replaced by data migrations) and the arbitrary initial SQL file support (should be replaced by custom migrations). I don't

Re: Migrations, commands and syncdb

I have generally not kept my migrations so they always work from scratch for similar reasons Luke said - Data migrations are often dependent on the data in the site - this is particularly relevant to content-driven (CMSy) sites where I may need to move a load of page about as a data migration

Re: Migrations, commands and syncdb

On 05/31/2013 02:08 PM, Andrew Godwin wrote: One problem with this is that you have to be careful to write migrations that will always work from scratch. This is best practice, but I have on occasion used data migrations that were for specific problems, and may have

Re: Migrations, commands and syncdb

> > One problem with this is that you have to be careful to write migrations > that will always work from scratch. This is best practice, but I have on > occasion used data migrations that were for specific problems, and may > have depended on specific data in the database. I've also used them for

Re: Migrations, commands and syncdb

On 30/05/13 20:55, Andrew Godwin wrote: > The way South works, and the way this will work (for new installs as > well as tests) is that if migrations are present for an app, it will > always create new databases by running through them from the very first > migration to the latest one. One

Re: Migrations, commands and syncdb

On Fri, May 31, 2013 at 2:03 AM, Andrew Godwin wrote: > Hi everyone, > > I'm starting to plan out the commands for the new migrations stuff in > Django, and I've hit something of an impasse trying to decide which option > to go for. > > Short background: South modified

Re: Migrations, commands and syncdb

I haven't used South as much as I should have (instead I have painful > manual scripts to do migrations). The biggest pain point about > database schemas for me is easily test database setup. That is, sync > from scratch. I do the following currently: > 1. load schema + a little bit of data from

Re: Migrations, commands and syncdb

On 30 touko, 21:03, Andrew Godwin wrote: > I prefer option 3, but getting rid of syncdb might be controversial, so I > want to ask for people's opinions. syncdb would continue to exist for at > least 3 versions if not forever; it would just be an alias to run "migrate" > in

Re: Migrations, commands and syncdb

Hi all, On Thursday 30 May 2013, Andrew Godwin wrote: > > The proposals are: > > 1. Change syncdb so that it both does the old behaviour (adds models for > unmigrated apps), and additionally runs any outstanding migrations. There > would be a separate "migrate" command for more complex

Re: Migrations, commands and syncdb

On 30.05.2013, at 20:03, Andrew Godwin wrote: > Hi everyone, > > I'm starting to plan out the commands for the new migrations stuff in Django, > and I've hit something of an impasse trying to decide which option to go for. > > Short background: South modified syncdb to

Re: Migrations, commands and syncdb

On 05/30/2013 12:03 PM, Andrew Godwin wrote: > The proposals are: > > 1. Change syncdb so that it both does the old behaviour (adds models > for unmigrated apps), and additionally runs any outstanding migrations. > There would be a separate "migrate" command for more complex operations, > such

Re: Migrations, commands and syncdb

I'm broadly +1 on deprecating syncbd, it's possibly the most inaccurately named thing in all of Django (hint: it doesn't sync anything). Alex On Thu, May 30, 2013 at 11:03 AM, Andrew Godwin wrote: > Hi everyone, > > I'm starting to plan out the commands for the new