bayerj wrote:
> As soon as I change my database schema, I have several possibilites to
> get my app up again:
> (a) Change the model. Then drop the current db schema, fire up the new
> one. Drawback: I lose my data.
> (b) Change the model and change the schema manually. Drawback: I am
> repeating
This seems very promising to me. Although I personally would be more
comfortable with sql being the root of datastructures, this would be
against django's philosophy.
I'm looking forward to the implementation!
--~--~-~--~~~---~--~~
You received this message becau
On 8/20/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> There's a Google Summer of Code project going on at the moment to
> support model evolution throughout a project's development. I haven't
> played with it, but I've heard it's coming along.
Actually, we've got a new tune: there's a *finished*
On Sun, 2006-08-20 at 09:43 -0700, bayerj wrote:
> As soon as I change my database schema, I have several possibilites to
> get my app up again:
> (a) Change the model. Then drop the current db schema, fire up the new
> one. Drawback: I lose my data.
> (b) Change the model and change the schema ma
On Sun, 2006-08-20 at 09:43 -0700, bayerj wrote:
> (b) Change the model and change the schema manually. Drawback: I am
> repeating myself.
Personally, I prefer this method. Yes, I am repeating myself, but I'm
still saving time by not re-importing or re-entering the data. At first
I didn't like it
Hi Justin,
On 20 Aug 2006, at 18:43, bayerj wrote:
> As soon as I change my database schema, I have several possibilites
> to get my app up again:
> (a) Change the model. Then drop the current db schema, fire up the
> new one. Drawback: I lose my data.
> (b) Change the model and change the sc
6 matches
Mail list logo
