Schema Evolution
dononyx
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??
Alex Gaynor
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
Dougal Matthews
http://code.djangoproject.com/wiki/SchemaEvolution
Dougal
---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/
2009/3/25 Alex Gaynor <alex....@gmail.com>:
Andreas
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.
Russell Keith-Magee
>
> 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.
Yours,
Russ Magee %-)
JL
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
Malcolm Tredinnick
> 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?
Regards,
Malcolm
Joshua Partogi
Alex Gaynor
Andrew Godwin
> 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.
Andrew
and...@klydd.se
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
Malcolm Tredinnick
[...]
> 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.
Regards,
Malcolm
and...@klydd.se
On Apr 27, 10:49 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> Permit me to correct that impression: you are mistaken.
>
> 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.
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.