Was there any thought about having migration tied to production or
development? It would be cool to have schema evolution in development
mode work like Rails but then lock it off in production mode, or just
have a flag set to True or False. Any Comments or Ideas??
On Wed, Mar 25, 2009 at 10:28 AM, dononyx <don.guern...@gmail.com> wrote:
> Was there any thought about having migration tied to production or
> development? It would be cool to have schema evolution in development
> mode work like Rails but then lock it off in production mode, or just
> have a flag set to True or False. Any Comments or Ideas??
There's been a lot of discussion of schema evolution in the past, and it
will probably make it's way into Django eventually. However, for now I
suggest you look at the various external projects, as your comment seems out
of place onsidering Django doesn't have it's own schema evolution built in.
Alex
-- "I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
> On Wed, Mar 25, 2009 at 10:28 AM, dononyx <don.guern...@gmail.com> wrote:
>> Was there any thought about having migration tied to production or
>> development? It would be cool to have schema evolution in development
>> mode work like Rails but then lock it off in production mode, or just
>> have a flag set to True or False. Any Comments or Ideas??
> There's been a lot of discussion of schema evolution in the past, and it
> will probably make it's way into Django eventually. However, for now I
> suggest you look at the various external projects, as your comment seems out
> of place onsidering Django doesn't have it's own schema evolution built in.
> Alex
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." --Voltaire
> "The people's good is the highest law."--Cicero
I know everyone is fed up with discussions about schema evolution and
multi db support but when it comes to schema evolution I think it's
time to have a discussion about it again.
I think we all can agree that picking a schema evolution app for a
django project isnt one of those things everybody wants to do when
they begin developing with django. And if im not mistaken, it has been
said on conferences and google talks that django is about not making
the developer to do decisions like "which auth framework or template
engine do i need" when they start out. I think schema evolution is one
of those pieces aswell. Of course one shouldnt have to use a django
shipped one.
My suggestion...
I've seen more and more people involved in django core development
either as core developer or submitting patches recommending south
( http://south.aeracode.org/ ) on twitter and people talking about it
on irc. My suggestion is simply to just through south in. Of course I
can see developers of other schema evolution frameworks could become
disappointed with this but Ill think it's in their interrest aswell
getting something shipped with django, and they can help contribute to
make it fit their needs aswell which would make the "default choice"
even better for more people. And if it totaly doesnt fit their needs,
they already have their own stuff to continue with.
I hope the core developers can make a decision that doent include
stepping on a sore toe and I hope they are not afraid and have what it
takes to pick something already built and branded, there's no need to
build a schema evolutotion framework for django.contrib form scratch.
Of course the 1.1 release is to soon for something like this but give
it some thought and a decision could be made before the summer for the
1.2.
On Thu, Apr 16, 2009 at 4:15 PM, Andreas <andrii...@gmail.com> wrote:
> I know everyone is fed up with discussions about schema evolution and > multi db support but when it comes to schema evolution I think it's > time to have a discussion about it again.
Now isn't the right time for that discussion - we're in the final stages of delivering v1.1, so the core developers are concentrating on squashing bugs, not new features.
However, I agree that schema evolution is something that should be "in the box"; we just need to make sure that what we put in the box really will solve the problem.
I'd like to think this could happen in the v1.2 timeframe, but I know my life will be a bit hectic over the next 6-9 months, so I'm not really in a position to make promises in this regard. Rest assured that this is on the radar - it's just a matter of when someone can fit it into their schedule.
Just to through in my 2c (since I'm acutally in the US). I'd second
South as being the most complete and flexible migration project. I've
used it on almost every Django project I've done. I'd love to see it
rolled in such that every dev working on evolution could focus on one
platform.
On Apr 16, 3:15 am, Andreas <andrii...@gmail.com> wrote:
> I know everyone is fed up with discussions about schema evolution and
> multi db support but when it comes to schema evolution I think it's
> time to have a discussion about it again.
> I think we all can agree that picking a schema evolution app for a
> django project isnt one of those things everybody wants to do when
> they begin developing with django. And if im not mistaken, it has been
> said on conferences and google talks that django is about not making
> the developer to do decisions like "which auth framework or template
> engine do i need" when they start out. I think schema evolution is one
> of those pieces aswell. Of course one shouldnt have to use a django
> shipped one.
> My suggestion...
> I've seen more and more people involved in django core development
> either as core developer or submitting patches recommending south
> (http://south.aeracode.org/) on twitter and people talking about it
> on irc. My suggestion is simply to just through south in. Of course I
> can see developers of other schema evolution frameworks could become
> disappointed with this but Ill think it's in their interrest aswell
> getting something shipped with django, and they can help contribute to
> make it fit their needs aswell which would make the "default choice"
> even better for more people. And if it totaly doesnt fit their needs,
> they already have their own stuff to continue with.
> I hope the core developers can make a decision that doent include
> stepping on a sore toe and I hope they are not afraid and have what it
> takes to pick something already built and branded, there's no need to
> build a schema evolutotion framework for django.contrib form scratch.
> Of course the 1.1 release is to soon for something like this but give
> it some thought and a decision could be made before the summer for the
> 1.2.
> My 5 swedish ören because I dont have any cents.
On Fri, 2009-04-17 at 07:01 -0700, JL wrote: > Just to through in my 2c (since I'm acutally in the US). I'd second > South as being the most complete and flexible migration project.
Have you written up your comparison of South with the other major options anywhere that we can need? Perhaps doing the same migration work with each framework to see the work involved?
> Just to through in my 2c (since I'm acutally in the US). I'd second
> South as being the most complete and flexible migration project. I've
> used it on almost every Django project I've done. I'd love to see it
> rolled in such that every dev working on evolution could focus on one
> platform.
> On Apr 16, 3:15 am, Andreas <andrii...@gmail.com> wrote:
> > I know everyone is fed up with discussions about schema evolution and
> > multi db support but when it comes to schema evolution I think it's
> > time to have a discussion about it again.
> > I think we all can agree that picking a schema evolution app for a
> > django project isnt one of those things everybody wants to do when
> > they begin developing with django. And if im not mistaken, it has been
> > said on conferences and google talks that django is about not making
> > the developer to do decisions like "which auth framework or template
> > engine do i need" when they start out. I think schema evolution is one
> > of those pieces aswell. Of course one shouldnt have to use a django
> > shipped one.
> > My suggestion...
> > I've seen more and more people involved in django core development
> > either as core developer or submitting patches recommending south
> > (http://south.aeracode.org/) on twitter and people talking about it
> > on irc. My suggestion is simply to just through south in. Of course I
> > can see developers of other schema evolution frameworks could become
> > disappointed with this but Ill think it's in their interrest aswell
> > getting something shipped with django, and they can help contribute to
> > make it fit their needs aswell which would make the "default choice"
> > even better for more people. And if it totaly doesnt fit their needs,
> > they already have their own stuff to continue with.
> > I hope the core developers can make a decision that doent include
> > stepping on a sore toe and I hope they are not afraid and have what it
> > takes to pick something already built and branded, there's no need to
> > build a schema evolutotion framework for django.contrib form scratch.
> > Of course the 1.1 release is to soon for something like this but give
> > it some thought and a decision could be made before the summer for the
> > 1.2.
> > My 5 swedish ören because I dont have any cents.
> On Apr 18, 12:01 am, JL <jonloy...@gmail.com> wrote:
> > Just to through in my 2c (since I'm acutally in the US). I'd second
> > South as being the most complete and flexible migration project. I've
> > used it on almost every Django project I've done. I'd love to see it
> > rolled in such that every dev working on evolution could focus on one
> > platform.
> > On Apr 16, 3:15 am, Andreas <andrii...@gmail.com> wrote:
> > > I know everyone is fed up with discussions about schema evolution and
> > > multi db support but when it comes to schema evolution I think it's
> > > time to have a discussion about it again.
> > > I think we all can agree that picking a schema evolution app for a
> > > django project isnt one of those things everybody wants to do when
> > > they begin developing with django. And if im not mistaken, it has been
> > > said on conferences and google talks that django is about not making
> > > the developer to do decisions like "which auth framework or template
> > > engine do i need" when they start out. I think schema evolution is one
> > > of those pieces aswell. Of course one shouldnt have to use a django
> > > shipped one.
> > > My suggestion...
> > > I've seen more and more people involved in django core development
> > > either as core developer or submitting patches recommending south
> > > (http://south.aeracode.org/) on twitter and people talking about it
> > > on irc. My suggestion is simply to just through south in. Of course I
> > > can see developers of other schema evolution frameworks could become
> > > disappointed with this but Ill think it's in their interrest aswell
> > > getting something shipped with django, and they can help contribute to
> > > make it fit their needs aswell which would make the "default choice"
> > > even better for more people. And if it totaly doesnt fit their needs,
> > > they already have their own stuff to continue with.
> > > I hope the core developers can make a decision that doent include
> > > stepping on a sore toe and I hope they are not afraid and have what it
> > > takes to pick something already built and branded, there's no need to
> > > build a schema evolutotion framework for django.contrib form scratch.
> > > Of course the 1.1 release is to soon for something like this but give
> > > it some thought and a decision could be made before the summer for the
> > > 1.2.
> > > My 5 swedish ören because I dont have any cents.
As Russ said, this is a terrible time for this discussion. Further even if
50 people come here and say that they like South that's not a convincing
reason to include it. 50 users is a tiny minority of Django developers, so
we need to look at real technical reasons, not what people like, since we
can probably get 100 people who like any given migration system.
Alex
-- "I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero
> As Russ said, this is a terrible time for this discussion. Further > even if 50 people come here and say that they like South that's not a > convincing reason to include it. 50 users is a tiny minority of > Django developers, so we need to look at real technical reasons, not > what people like, since we can probably get 100 people who like any > given migration system.
I agree with this completely; the core devs I've spoken to don't yet want to roll in a migration solution, and I'm 100% behind that, as I still think there's no clear winner. http://code.djangoproject.com/wiki/SchemaEvolution lists six active migration solutions, and there's obviously a reason there's more than one; Django has always been about swappable components, and rolling one solution in might easily make people think that's the only choice. (In addition, it would slow down development progress into a 6 month release cycle, and that's something I personally think South in particular wouldn't benefit from at the moment)
That said, I would like to see some mention of schema evolution in the Django docs at some point; it's a very common problem, and we could easily come up with a neutral page to point people at all their options, rather than leaving them to find that wiki page on their own.
My point wasnt to pick a solution, in this case South and just throw
it into django.
What I mean is, there is no winner nor any loser. I was more looking
for taking it,
and changing it in a way making most the core devs happy, and
hopefully a majority
of the community happy. Just to fork any of all migration apps there
is is good enough,
there's absolutly no reason to start from scratch? Yes I mean fork,
and let it live it's
own life in django.contrib without any constrains about pulling
changes from the original.
It seems like its to difficult to make such a decision, I get the
feeling that the core team is
to afraid to get criticism of picking the wrong one. But as I said,
there is no wrong one.
People with other needs can always choose some of the other
solutions.
There's no way there will migrations in django ever which will fit all
django users in the world,
this is pretty clear after all discussions there have been.
Thats the nice thing about loose coupling.
I don't see why this is a terrible time for discussions, the whole
idea of discussions is to laborate with ideas. I don't see how that
makes it difficult for us to get 1.1 out.
On Apr 27, 1:45 pm, Andrew Godwin <and...@aeracode.org> wrote:
> > As Russ said, this is a terrible time for this discussion. Further
> > even if 50 people come here and say that they like South that's not a
> > convincing reason to include it. 50 users is a tiny minority of
> > Django developers, so we need to look at real technical reasons, not
> > what people like, since we can probably get 100 people who like any
> > given migration system.
> I agree with this completely; the core devs I've spoken to don't yet
> want to roll in a migration solution, and I'm 100% behind that, as I
> still think there's no clear winner.http://code.djangoproject.com/wiki/SchemaEvolutionlists six active
> migration solutions, and there's obviously a reason there's more than
> one; Django has always been about swappable components, and rolling one
> solution in might easily make people think that's the only choice. (In
> addition, it would slow down development progress into a 6 month release
> cycle, and that's something I personally think South in particular
> wouldn't benefit from at the moment)
> That said, I would like to see some mention of schema evolution in the
> Django docs at some point; it's a very common problem, and we could
> easily come up with a neutral page to point people at all their options,
> rather than leaving them to find that wiki page on their own.
On Mon, 2009-04-27 at 13:22 -0700, andr...@klydd.se wrote:
[...]
> It seems like its to difficult to make such a decision, I get the > feeling that the core team is > to afraid to get criticism of picking the wrong one.
Permit me to correct that impression: you are mistaken.
> But as I said, > there is no wrong one.
That's also not a really valid assumption. There are still significant differences and different limitations and advantages with each approach to database migration. A bit more convergence and experience -- which is happening -- is already going on and will continue to do so. Look at all the active projects in this space. They are all changing their approaches as time goes by, based on feedback, maintenance experience and general whims.
> People with other needs can always choose some of the other > solutions.
Which is no different from right now. Django permits and encourages external applications. You shouldn't be surprised when they exist. Moving anything into contrib right this minute adds a relatively small advantage to the current situation: it saves you from one extra download. It has a number of disadvantages, including added maintenance burden and expectation management.
There is a clear policy for things going into contrib and clear reasons for not putting things in there. Database evolution is one of the prime examples of wy not to include something before time.
> There's no way there will migrations in django ever which will fit all > django users in the world, > this is pretty clear after all discussions there have been.
> Thats the nice thing about loose coupling.
> I don't see why this is a terrible time for discussions, the whole > idea of discussions is to laborate with ideas. I don't see how that > makes it difficult for us to get 1.1 out.
Look at the major contributors to this list and the people who have the deepest understanding of the platform. Now look at the list of people doing the reviews and commits to get 1.1 out. Notice the large overlap. Consider that thinking about these problems is actually fairly difficult and takes time. Then realise that database migration is only one of maybe a dozen large things that people want to discuss. Clearer now? If not, repeat the process.
On Apr 27, 10:49 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> Permit me to correct that impression: you are mistaken.
Good! That's what I want'ed to be.
> That's also not a really valid assumption. There are still significant
> differences and different limitations and advantages with each approach
> to database migration. A bit more convergence and experience -- which is
> happening -- is already going on and will continue to do so. Look at all
> the active projects in this space. They are all changing their
> approaches as time goes by, based on feedback, maintenance experience
> and general whims.
This applies to django, webdevelopment and software in general aswell
and it's a good thing imo, "magic removal" in django
is a good example of how django not changed the values for what it
stands for
but slightly changed it's approach and became more explicit.
--
I will accept the fact that you guys don't want to discuss this now.
I didnt want to make anyone upset. I was kind of thinking about this
when I
mentioned that "everyone is probably fed up with this topic"
So Im hereby withdrawing from this thread.
|
