On 8/30/07, Graham Carlyle <[EMAIL PROTECTED]> wrote:
>
> I haven't found a lot of information on how people typically do schema
> migrations for Django after reading the docs/scanning the wiki/googling.
> However the manual route seems to be a preferred option...
At the moment, yes. The purpose
On Thu, 2007-08-30 at 07:27 +0800, Russell Keith-Magee wrote:
> 1) If you have a non-trivial amount of data in your production
> database, the space and time required to deserialize, store and
> reserialize the contents of the databse could be problematic.
Fortunately I have a small amount of dat
On 8/29/07, Graham Carlyle <[EMAIL PROTECTED]> wrote:
>
> I was hoping something similar would be tenable for the production phase
> as well... just dumping the data and then re-loading after recreating
> the database, with some possible data munging if the schema has changed
> in an incompatible
On Wed, 2007-08-29 at 21:12 +0800, Russell Keith-Magee wrote:
> There are 2 options for workarounds:
> 1) use SQL ALTER statements rather than resetting the table. This
> requires writing manual SQL statements to modify the existing tables
> 2) Drop the entire database and start again from scratch
On 8/29/07, Graham Carlyle <[EMAIL PROTECTED]> wrote:
>
> So should models in different application's never have foreign key
> dependencies and so i should bring them back to one application? or does
> anyone know if there is another way around this problem?
Models can and should have foreign key
I recently decided to split out a django application from another one as
it seemed to nicely separate a related bunch of views & models.
However a model in the split-out application needs a foreign key to a
model in the original application. This seems to cause ./manage reset to
now fail.
I thi
6 matches
Mail list logo
