On 2006-12-24, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On 12/24/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>> What's the quality of the Schema Evolution code from last summer?
>
> Not done.
>
>> Is it
>> at all usable?
> No.
>
>> Is it fixable?
> Yes.
>
> Anyway, you seem enthusiastic.
> Here
Thanks, Ned.
That seems like a very effective way to do things. It also seems
fairly complicated (I have no idea where I would even start with
creating an evolution function, or getting the app to check for it on
startup). How much work did it take you to set up the infrastructure
to do someth
This seems a lot like what was supposed to happen in the SoC solution
(at least according to what was posted on the Wiki).
Derek seemed to do a very good job with the analysis and writing of
functional specs, but I think Victor Ng's approach is slightly
different.
Honestly, I haven't had time t
This is the method I've used in a few projects, and am now using with
Django in Tabblo:
1) You add a sequentially-increasing number called the schema number to
your code. Any time the models change in a way that changes the db
schema, this number is incremented.
2) A table is added to the d
On 12/24/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
What's the quality of the Schema Evolution code from last summer?
Not done.
Is it
at all usable?
No.
Is it fixable?
Yes.
Is anyone else worried that Google won't
be so keen to give Django coders they've spent thousands of dollars on
On Sun, 2006-12-24 at 11:38 +0530, Kenneth Gonsalves wrote:
On 24-Dec-06, at 8:50 AM, ringemup wrote:
> Yeah, I'm good with syncdb when adding a model, it's when I
> add/remove/change a field that problems occur.
>
> Sqlreset sounds convenient... how do you deal, though, with
> re-inputting d
On 24-Dec-06, at 9:01 AM, Aaron Jacobs wrote:
2. if you are not worried about data loss run sqlreset - or better,
drop the database, create it and run syncdb
3. if you alter a model, run sqlall, examine the out put to see what
statements django wants and put them in manually
These two are fi
On 24-Dec-06, at 8:50 AM, ringemup wrote:
Yeah, I'm good with syncdb when adding a model, it's when I
add/remove/change a field that problems occur.
Sqlreset sounds convenient... how do you deal, though, with
re-inputting data for testing once you modify a model?
ready made scripts - run o
On 12/23/06, ringemup <[EMAIL PROTECTED]> wrote:
Yeah, I'm good with syncdb when adding a model, it's when I
add/remove/change a field that problems occur.
Sqlreset sounds convenient... how do you deal, though, with
re-inputting data for testing once you modify a model?
This is becoming a F
On 12/23/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
2. if you are not worried about data loss run sqlreset - or better,
drop the database, create it and run syncdb
3. if you alter a model, run sqlall, examine the out put to see what
statements django wants and put them in manually
These
Yeah, I'm good with syncdb when adding a model, it's when I
add/remove/change a field that problems occur.
Sqlreset sounds convenient... how do you deal, though, with
re-inputting data for testing once you modify a model?
--~--~-~--~~~---~--~~
You received this
On 21-Dec-06, at 2:14 AM, ringemup wrote:
In the meantime, I'm interested in picking up some ideas: how do you
deal with changing database structures as you develop a Django app?
1. if you just add a new model - run syncdb and it automatically gets
added
2. if you are not worried about da
Hello all --
I'm aware that there are long-term plans to provide for schema
evolution in Django (much like RoR's "Migrations".
In the meantime, I'm interested in picking up some ideas: how do you
deal with changing database structures as you develop a Django app?
--~--~-~--~~
13 matches
Mail list logo
