On Wed, Apr 29, 2009 at 10:42 AM, DavidP wrote:
>
> A solution to the schema evolution problem is to reframe it and solve
> a different problem.
While I'm glad you are enthusiastic about the schema evolution
problem, now is not the best time to be discussing it. We are trying
(d
A solution to the schema evolution problem is to reframe it and solve
a different problem.
The "problem" with schema evolution is caused by a violation of the
DRY principle. There is redundancy between the db schema and
django's .py files. The DRY violation may be remov
On Apr 27, 10:49 pm, Malcolm Tredinnick
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
>
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,
>
d 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)
>
>
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
le 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 wrote:
> >
> > &g
'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 wrote:
>
> > I know everyone is fed up with discussions about schema evolution and
> > multi db support but when it co
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
on one
platform.
On Apr 16, 3:15 am, Andreas 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
On Thu, Apr 16, 2009 at 4:15 PM, Andreas 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 dis
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 ever
And here is a list of various schema evolution projects;
http://code.djangoproject.com/wiki/SchemaEvolution
Dougal
---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/
2009/3/25 Alex Gaynor :
>
>
> On Wed, Mar 25, 2009 at 10:28 AM, dononyx wrote:
>>
>> Was th
On Wed, Mar 25, 2009 at 10:28 AM, dononyx 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
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
cool. looks like nothing that'll effect us. i've switched back to one
common postgresql backend.
danke. :)
Yuri Baburov wrote:
> 2007/10/3, Derek Anderson <[EMAIL PROTECTED]>:
>> yes, because that is what django does with it's psycopg2 backend. (or
>> at least did, when i originally added
2007/10/3, Derek Anderson <[EMAIL PROTECTED]>:
>
> yes, because that is what django does with it's psycopg2 backend. (or
> at least did, when i originally added psycopg2 to the branch) i'm not a
> big postgres user, i don't know what the differences between the two
> are, i didn't know why they
yes, because that is what django does with it's psycopg2 backend. (or
at least did, when i originally added psycopg2 to the branch) i'm not a
big postgres user, i don't know what the differences between the two
are, i didn't know why they had done so originally, so until i figured
it out i t
Derek Anderson skrev:
> hey nis,
>
> 1) psycopg2 has been added as a backend
>
Any reason for not using my code (importing postgresql.py for both
backends) rather than having two source files which are identical?
Shouldn't we at least replace postgresql_pcycopg2.py with
from postgresql import
t -
> especially if we limit ourselves to versions >=7.4 - I am happy to help
> in this area.
i'll take any suggestions you have. :)
thanks,
derek
Nis Jørgensen wrote:
> Derek Anderson skrev:
>> Django External Schema Evolution Branch
>> =
Derek Anderson skrev:
> Django External Schema Evolution Branch
> ===
> http://code.google.com/p/deseb/
>
> I've released v0.2, which supports both MySQL and Postgresql, and works
> with both django-head and django-v0.96.
>
&
Django External Schema Evolution Branch
===
http://code.google.com/p/deseb/
I've released v0.2, which supports both MySQL and Postgresql, and works
with both django-head and django-v0.96.
This release contains the introspection/generation code only.
Russel, I'm only a non-programmer user, but just curious question:
why you (all of core developers) implement the schema evolution in
the self model that is evolving and not outside the model?
Why not if you have:
from django.db import models
class Poll(models.Model):
que
code speaks volumes compared to
> descriptions. I'll have need for schema evolution in a future project,
> so I've been following these discussions, and I've completely lost
> track of who's working on what, and how each offering is expected to
> work.
>
> Pers
I won't get into the discussion on features or implementation yet, but
I do have to agree that working code speaks volumes compared to
descriptions. I'll have need for schema evolution in a future project,
so I've been following these discussions, and I've completely lost
tr
On 9/28/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> well, this i just don't understand. plenty of programming topics
> considerably more challenging than this are solved via listserv every
> day in the open source world. i'd rather have a public discussion
> incorporating everyone's needs,
well, this i just don't understand. plenty of programming topics
considerably more challenging than this are solved via listserv every
day in the open source world. i'd rather have a public discussion
incorporating everyone's needs, ideas and concerns, not just "you and
ben" deciding between
On 9/28/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> p.s. long emails on complicated topicsdetails get murky. so i've
> labeled the four major questions {Q1-4} so we can further isolate where
> we do and do not see eye2eye. :)
Rather that descend in to another few weeks of multi-page
On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> Paul Davis wrote:
> >
> > As near as I can tell these are the main issues that don't seem to be
> resolved:
> >
> > 1. Balancing ease of use with power of use (Ie, Alice vs. Carol)
> > 2. Level of versioning: Model vs. Application vs.
Paul Davis wrote:
>
> As near as I can tell these are the main issues that don't seem to be
> resolved:
>
> 1. Balancing ease of use with power of use (Ie, Alice vs. Carol)
> 2. Level of versioning: Model vs. Application vs. Entire database
> 3. Application of versions: v1 -> v2 -> v3 =? v1 ->
Paul Davis wrote:
>
> As near as I can tell these are the main issues that don't seem to be
resolved:
>
> 1. Balancing ease of use with power of use (Ie, Alice vs. Carol)
> 2. Level of versioning: Model vs. Application vs. Entire database
> 3. Application of versions: v1 -> v2 -> v3 =? v1 -
ack. ;)
So for some reason schema evolution is causing quite a bit of
controversy among the django crowd. At first I couldn't figure out why
until I started reading about the large range of ideas for
implementation. But then, the more I read, the more confused I became
again.
As near as I ca
Russell Keith-Magee wrote:
> It's not the _model_ per se - just a rendition of the significant data
> in the model.
a rose by any other name (but yes, i assumed you meant not the
actual textual rendition, but a data structure containing all the
database-relevant attributes of the model)
>>
nt to know what is the status of the Schema Evolution.
> Reading trac docs and browse code repository I see that you have
> several implementations.
>
> What is the most stable implementation?
> What is the implementation you probably merge in svn?
>
> What are the big future
On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
> > The latter, by comparing the signature of the models.py that you have
> > with the signature in the Evolution table. The evolution table
> > contains the signature of the last model that was sync'd; if this
>
On Sep 27, 12:52 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 9/27/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Sep 27, 6:18 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> > I'm actually waiting for some code to be put up to
> >http://code.google.com/p/django-evolution/-
Russell Keith-Magee wrote:
> The latter, by comparing the signature of the models.py that you have
> with the signature in the Evolution table. The evolution table
> contains the signature of the last model that was sync'd; if this
> doesn't correspond to the current model, you need migrations to
On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> ok, yes, introspection we all agree has to be used for validation (1)
> and signature creation (2). we're all on the same page as that being a
> good thing.
Wait up a moment - (2) is an entirely optional part of my proposal. My
proposal p
ok, yes, introspection we all agree has to be used for validation (1)
and signature creation (2). we're all on the same page as that being a
good thing.
but what SoC2006, my subsequent work and what i think most people here
are talking about when we say "evolution through introspection" is ab
On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> russell, i've re-read your linked email (from 8/4/07), and i'm still
> totally lost as to what you're proposing. i'm reading of application
> and verification of an SQL-abstraction syntax:
>
> mutations = [
>AddColumn('
07 email?) link?
>
> http://groups.google.com/group/django-developers/browse_thread/thread/da7831d08081d7b7/49347e67d22fa3cc?rnum=1#49347e67d22fa3cc
>
>>> Derek - on a housekeeping issue - are you happy for us to write-lock
>>> the schema-evolution bra
ers/browse_thread/thread/da7831d08081d7b7/49347e67d22fa3cc?rnum=1#49347e67d22fa3cc
> > Derek - on a housekeeping issue - are you happy for us to write-lock
> > the schema-evolution branches and close the outstanding tickets in
> > Django's ticket database relating to that br
to your
8/4/2007 email?) link?
> Derek - on a housekeeping issue - are you happy for us to write-lock
> the schema-evolution branches and close the outstanding tickets in
> Django's ticket database relating to that branch?
if you don't mind, i'd prefer you keep them ope
On 9/27/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> On Sep 27, 6:18 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> I'm actually waiting for some code to be put up to
> http://code.google.com/p/django-evolution/ - Russell (I'm pretty sure
> it was him... we discussed it at the end of the sprin
On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> ok, for the official status:
>
> as mentioned earlier, yuri and i are joining forces on
> introspection-driven schema evolution. and since automatic
> introspection is so controversial (and obviously a poison pi
ok, for the official status:
as mentioned earlier, yuri and i are joining forces on
introspection-driven schema evolution. and since automatic
introspection is so controversial (and obviously a poison pill for
acceptance into django-proper), we've rewriting it as an external library.
SmileyChris wrote:
> I like Derek's take on model comparison using introspection, but
> really think that it should be based on a migration system. I know
> several Django developers agree with me on this (including Russell).
i see them as two distinct, non-exclusive tasks, with automatic
intros
> I'm actually waiting for some code to be put up to
> http://code.google.com/p/django-evolution/ - Russell (I'm pretty sure
> it was him... we discussed it at the end of the sprint) has someone
> who has been working on some code and I really want to see it before I
> do any more work.
You better
> I like Derek's take on model comparison using introspection, but
> really think that it should be based on a migration system. I know
> several Django developers agree with me on this (including Russell).
Rails has migrations because it has introspection already built-in.
I don't understand why
On Sep 27, 6:18 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> There were also attempts to do schema-evolution in other way, but no
> other project released more than limited alpha versions. I rechecked
> it today.
I'm guessing this could refer to my code.
I'
Hi,
Waiting for Derek, as he's official person responsible for
implementing schema-evolution functionality in django (if we can use
"responsible" with open source) and maintainer of schema-evolution
branch.
What I can say now, is that since django now allows custom commands,
we
Hi,
I just want to know what is the status of the Schema Evolution.
Reading trac docs and browse code repository I see that you have
several implementations.
What is the most stable implementation?
What is the implementation you probably merge in svn?
What are the big future steps we (django
Jacob Kaplan-Moss wrote:
> So what hooks do you think you'd need? Would the sql-level hooks being
> discussed in other threads be sufficient?
would you allow a hook for still annotating in models.py?
derek
--~--~-~--~~~---~--~~
You received this message because y
On 8/9/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
> i considered this. but i have my doubts that i could get the necessary
> hooks pushed through to allow this to function as an external app.
Hrm - I'd think again there. Personally, I'd *much* rather see
migration done as a third-party bit si
Brantley Harris wrote:
> Er, could you re-factoritize your system into a stand-alone app? Then
> it could be added by anyone. That seems like win/win to me.
i considered this. but i have my doubts that i could get the necessary
hooks pushed through to allow this to function as an external app
On 8/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> * Every time I have written an API with a pre and post phase, I have
> ended up needing a post-pre and pre-post, and post-post, and pre-pre,
> and really-no-I-mean-it-pre
Well since the user defines the pre and post phases, he can ap
Er, could you re-factoritize your system into a stand-alone app? Then
it could be added by anyone. That seems like win/win to me.
On 8/9/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
>
> > I thought you were proposing moving away form ordered sequences? Besides:
>
Russell Keith-Magee wrote:
> I thought you were proposing moving away form ordered sequences? Besides:
i am moving towards graphs of schema revisions. but while lines are
always graphs (and graphs can have order), only the simplest graph can
be represented as a line. and graph paths are alwa
On 8/9/07, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> On 8/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > My goals:
> > * Keep the model file as a canonical representation of what the tables
> > should look like right now.
> > * Keep each migration as an atomic unit.
> > * Provide an
On 09-Aug-07, at 1:56 AM, Brantley Harris wrote:
> "hint" seems like the wrong word. "suggest", "guide", "auto",
> "build"?
preview?
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
--~--~-~--~~~---~--~~
You received this message
On 8/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> My goals:
> * Keep the model file as a canonical representation of what the tables
> should look like right now.
> * Keep each migration as an atomic unit.
> * Provide an entry point for raw SQL migrations
> * Provide some validation that
On 8/8/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> > 1) Isn't the list of known schema fingerprints just the list of keys
> > in the migration graph/dictionary?
>
> no. it adds ordering. (the keys are a set remember) we wouldn't need
> it if python had something similar to java's LinkedHa
On 8/8/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> as i said before i'm not wed to it. (actually i feel it's a rather
> minor point) propose a different location. i just want it somewhere
> simple and obvious. (or if you two just hate the keyword, what would
> you like to call it?)
Its
On 08/08/2007, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
>
> i have had this exact situation happen to me before. (rolling out a
> change, then another change reversing it) actually several times. i
> have NEVER had a scenario where client Y says "can you please make sure
> i lose my data?"
>
it get
> accidentally leaked to development wrecking the lives of millions) a
> copy-paste requirement is your protection from my introspected evil. :)
One simple question, do you trust syncdb operation?
And who said earlier about butt-easy schema evolution? Now it seems to
be easy only f
Yuri Baburov wrote:
\> 1) Would the app_name/schema_evolution.py be automatically
generated/updated?
> I don't want to be a monkey copying output of sqlevolve and
> sqlfingerprint to that file. I better remove all parts of file that I
> won't use.
no. i think that those who don't trust introspe
Model was deleted and
another created in future with the same name (name clashes and no
references to old table is left). Temporary model created to get
information from m2m field and copied to another table with
schema-evolution and then removed from models.py.
My position (and not only mine)
Yuri Baburov wrote:
> 1) How one writes operation to reset all field values to default? Is
> it a migration at all?
just stick an "update mytable set col=value;" in your upgrade script.
(but if you're doing this outside of any schema changes, yes i would
argue that this is not a migration issue
ocumentation
and probably the ideal for large/serious development work. but i don't
think we need to force everyone to do it this way.
> Don't get me wrong, I've very excited about the prospect of
> schema-evolution getting merged :)
danke :)
--~--~-~--~~--
with int
constants, the labels of which are editable in another part of the app).
I am making the decision to do this, aware that I am dropping the old
data and starting new with a default value of a different type.
Depending on how often it gets released, it might work. If
schema-evolution decid
Hi Derek,
Here are my questions.
1) How one writes operation to reset all field values to default? Is
it a migration at all?
2) How about python-written migrations?
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: [EMAIL PROTECTED]
--~--~-~--~~---
i have had this exact situation happen to me before. (rolling out a
change, then another change reversing it) actually several times. i
have NEVER had a scenario where client Y says "can you please make sure
i lose my data?"
your schema integrity in assured. the data integrity is also assu
Russell Keith-Magee wrote:
>> * full migration graphs should be supported, not just linear steppings
>> * a list of known schema fingerprints
>> * a dict mapping (from_fprint,to_fprint) pairs to scripts (lists of
>> sql statements and/or python function calls, to be run in order...think
>> p
Jacob Kaplan-Moss wrote:
> On 8/7/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>> Again - IMHO, the 'aka' syntax is a non-starter (for all the reasons I
>
> Russ is doing a great job speaking for me here, too.
>
> We're currently trying to move non-required metadata *out* of the
> model (c
Russell Keith-Magee wrote:
> 3) If you are using fingerprints to identify nodes in the graph, how
> do you handle cyclic states (e.g., v1, I add a field, v2 delete it ,v3
> add it again)? As I read your proposal, the fingerprint for v1 and v3
> should be the same - which will cause some major prob
Oh, and one other thing:
Derek, I really appreciate your hard work on this. You're getting an
large amount of pushback, but that's because this is a critical
feature and we want to get it right.
So please don't confuse criticism with a lack of gratitude!
Jacob
--~--~-~--~~-
a BDFL or majority core-dev
> pronouncement to the contrary, or you can provide a compelling reason
> why 'aka' is desirable, it's probably safe to assume that
> schema-evolution with 'aka'-style syntax as currently proposed won't
> be merged to trunk.
On 8/6/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> who wish to perform different combinations of the two basic subtasks of
> schema evolution:
>
> 1. generation of SQL via magical introspection
> 2. storage and auto-application of upgrade SQL
>
> the first i&
n't trust it (they
want it generated at development and stored for use in production)
4. users who hate introspection and just want auto-application of their
own scripts
who wish to perform different combinations of the two basic subtasks of
schema evolution:
1. generation of SQL via
hey mike, we use a modified version of dbmigration in production at
work, I sent you an email with our mods.
cheers,
peter
> This part of the plan looks quite similar to the dbmigration project
> athttp://www.aswmc.com/dbmigration/- hope that its useful in some way :)
> If not, ah well, it work
Hi,
> 6) The user can define evolutions. They exact sequence is defined in
> the Meta property of the model:
>
> class Author(Model):
>...
>class Meta:
> evolution = [
> 'v1',
> 'v2',
> 'pre_christmas_2006',
> 'valentines_day_2007',
> 'v5
ired, and produces
a first pass .py migration. If Alice is trusting, she just runs
./manage.py syncdb --hint --evolve; this will generate the hint and
evolve the database, all in one step.
Some caveats:
At stage 8, if there isn't a match in the evolutions table for the
current signature, som
On 8/4/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
Hi Derek;
First off - let me apologize - my comments were not intended to be
harsh or derogatory.
You have done some great work here, and I don't want to give you the
impression that your efforts are not appreciated and valued.
However, your
Brantley Harris wrote:
> Your
> philosophy seems to be, "Those problems are spiky edge cases", but I
> think the hope was they would be solved as well, or at least put on
> track for a solution later on.
more like "low-hanging-most-useful-fruit first" :) everyone agrees
that there will never b
2007/8/4, Brantley Harris <[EMAIL PROTECTED]>:
> ps. Did you ever see my long-ago proposal?
> (http://code.djangoproject.com/wiki/SchemaEvolutionProposal)
Hi Brantley, you have written very nice proposal, I like it!
Your evolutions are python equivalent of Rails migrations, but have
better syntax
migrate, and then import the altered
data into the new schema, which all but precludes a distributed
solution.
If we go back to Jacob's Schema Evolution page
(http://code.djangoproject.com/wiki/SchemaEvolution) you can see that
he identifies 3 different tactics, but really there are j
Russell Keith-Magee wrote:
> - The 'aka' approach has some serious flaws.
for the scenario you give the aka approach (or any formatting of
model+existing_schema+rename_metadata) works just fine. i detail how
(with working examples and sql output) here:
http://kered.org/blog/2007
ding installation and usage instructions) is
> available both in the branch and here:
Hi Derek,
As I noted in your last thread on schema-evolution, I'm _really_ not
happy with this design, and I am a _strong_ -1 on merging this branch.
- The 'aka' approach has some serious fla
branch and here:
http://code.djangoproject.com/wiki/SchemaEvolutionDocumentation
additionally, the latest changes from the trunk (r5787) have been merged
into the schema-evolution branch, so you won't lose any recent updates
by giving it a shot.
obviously, this is an area with a l
actually, "model changes, db needs update" is exactly what i think about
when i think of schema evolution. ;) but seriously...
> * You have to change all your code at once to match the new name
>(evolution is a slow process in nature ;-)
excellent point. for large
I did some thinking about the "aka"-parameter you use to name the old
fieldname/modelname and some things that would be nice to have when
schema _evolution_ is supported by django. I highlighted evolution,
because that means more than just "model changes, db needs update" I think.
I think the aka
yep. i just updated the schema-evolution branch to match the trunk. or
you can apply this patch instead:
http://kered.org/blog/wp-content/uploads/2007/07/django_schema_evolution-svn20070719patch.txt
Sebastian Macias wrote:
> Does it work with the trunk?
>
> On Jul 19, 5:33
> Also, I've ported the changes to SVN. I would like to solicit testers,
> for potential inclusion in django-proper.
>
> Thanks,
> Derek
>
> Derek Anderson wrote:
> > Hey all,
>
> > I've ported my schema evolution work from my SoC project last
On 7/20/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>
> heh, i read this and was like "there are other backends?!?" ;p
>
> nope, sqlite/mysql/postgres is all she wrote right now, as that was all
> that existed last summer when i did the bulk of the work on this. but
> i'll add oracle and mssql
gt; http://kered.org/blog/wp-content/uploads/2007/07/django_schema_evolut...
>>> Also, I've ported the changes to SVN. I would like to solicit testers,
>>> for potential inclusion in django-proper.
>>> Thanks,
>>> Derek
>>> Derek Anderson wrote:
>
> > Thanks,
> > Derek
>
> > Derek Anderson wrote:
> > > Hey all,
>
> > > I've ported my schema evolution work from my SoC project last summer to
> > > Django v0.96. To use it, download the patch below, and run the
> > &g
es /
> documentation:
>
> http://kered.org/blog/wp-content/uploads/2007/07/django_schema_evolut...
>
> Also, I've ported the changes to SVN. I would like to solicit testers,
> for potential inclusion in django-proper.
>
> Thanks,
> Derek
>
> Derek Anderson wrot
ngo-proper.
Thanks,
Derek
Derek Anderson wrote:
> Hey all,
>
> I've ported my schema evolution work from my SoC project last summer to
> Django v0.96. To use it, download the patch below, and run the following:
>
> $ cd //site-packages/django/
> $ patch -p1 < ~
Hey all,
I've ported my schema evolution work from my SoC project last summer to
Django v0.96. To use it, download the patch below, and run the following:
$ cd //site-packages/django/
$ patch -p1 < ~//django_schema_evolution-v096patch.txt
It should output the following:
patching f
Hi,
I'm using the multi-db branch to do schema-evolution. I'm bringing
this up to see if it is worth pursuing or if there is some better idea
somewhere...
The basic idea is, have a v1 and a v2 database, with the v1 models in
the first and the v2 models in the latter, and create
1 - 100 of 196 matches
Mail list logo
