Schema evolution

15 views
Skip to first unread message

Jacob Kaplan-Moss

unread,
Feb 27, 2006, 10:26:41 PM2/27/06
to Django developers
Hey folks --

I've posted (over 1200 words of) my thoughts on schema evolution to the
wiki: http://code.djangoproject.com/wiki/SchemaEvolution.

Any thoughts before I start on this?

Jacob

Matt Croydon

unread,
Feb 27, 2006, 10:40:51 PM2/27/06
to django-d...@googlegroups.com
On 2/27/06, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:

Any thoughts before I start on this?

I'm definitely +1 on this.  The flexibility of using SQL or Python for migration lets people use the tools that they are most familiar/comfortable  with.  While I think that anyone with "real" data to worry about should use to_version_X.out to ensure integrity, making it optional is key for keeping it simple for the newbs.

--Matt

hs...@nwlink.com

unread,
Feb 28, 2006, 12:09:07 AM2/28/06
to Django developers

I'm not sure exactly what reparations you're thinking will be possible
by rolling back a DDL transaction. I'm pretty sure most db's don't
have full transaction control over DDL. Issuing a DDL statement
usually involves at least an implicit commit, so, e.g., if something
goes wrong three DDL commands into your evolution you're not going to
be able to roll back to initial state. Backing up the db before the
series of DDL statements is only sure way to guarantee a rollback for
all db's, I think.

-- Herb

Ian Holsman

unread,
Feb 28, 2006, 12:22:31 AM2/28/06
to django-d...@googlegroups.com
my only suggestion that I don't see in the wiki is to create a backup
version of the table(s) before you attempt any DDL transactions.
you could then you the 'insert INTO .. select ...' syntax to do your
conversions.
that way you keep all your old data if/when u screw up.
this should be OK for most small-medium size tables.. and if you are
doing large ones you should be doing your own custom SQL anyways.


--
I...@Holsman.net -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909

If everything seems under control, you're not going fast enough. -
Mario Andretti

Malcolm Tredinnick

unread,
Feb 28, 2006, 12:28:21 AM2/28/06
to django-d...@googlegroups.com

Looks good. The only part that raised a few flags for me is the
possibility of missing files (in the conclusion section). I can see the
argument for allowing missing files (e.g. the evolution from version 3
to version 4 turned out to be bad, was never rolled out anywhere but to
the testing systems, etc). But in production cases such as the use cases
in this page, mistakes are going to be costly -- forgetting to roll out
one upgrade and not getting a warning will cause stress down the road
(oh, make the bad memories stop).

Thinking about this some more, I guess if I was doing this in practice
as an operations guy, I would routinely extract the list of evolution
table entries for the package I think I just upgraded so that I could
check it is the same on all machines. So maybe this isn't a big issue,
but other people with large production system experience (the "Carol"
use case) might want to think about what could go wrong here, too.

But generally, this would be a great enhancement, I think. Nice writeup.

Cheers,
Malcolm

Ben Bangert

unread,
Feb 28, 2006, 12:37:36 AM2/28/06
to Django developers
I'm inclined to agree with Ian on this. I've had very bad experiences
with the Rails version of schema migrations, and having to restore db
backups, then try them over and over when screw-ups happen (which ALTER
statements always seem to cause when attempted in a cross-db way).

Despite how many people are using Rails schema migrations, its not
perfect, and when it dies, it dies in a horrid way that leaves you
unable to upgrade the db schema. This is typically due to a fault in
the webapp as lots of Rails webapp code is aimed at Mysql, so using
Postgres almost guarantees a screw-up (and I use Postgres extensively).

Since its possible (and perhaps likely in some cases) that the tables
can have something impacting them that leaves the script unable to
migrate using ALTER properly, structuring the updates as 'insert INTO'
syntax as Ian suggests would make it much easier to manually apply any
changes should the automatic ones fail. Ideally the migration script
should be easily readable so a DBA or someone could troubleshoot a
failed migration if need be.

- Ben

hugo

unread,
Feb 28, 2006, 9:58:47 AM2/28/06
to Django developers
>I'm not sure exactly what reparations you're thinking will be possible
>by rolling back a DDL transaction. I'm pretty sure most db's don't
>have full transaction control over DDL. Issuing a DDL statement
>usually involves at least an implicit commit, so, e.g., if something
>goes wrong three DDL commands into your evolution you're not going to
>be able to roll back to initial state.

PostgreSQL and SQLite fully support transactioned DDLs. MySQL might -
if it is a MySQL with transactions. Oracle doesn't support it and I
can't say anything on MSSQL. DDL-transactionality is definitely
something you can't expect if you want to have support for multiple
databases, so a backup/restore way of keeping the old state is much
more portable.

bye, Georg

Linicks

unread,
Feb 28, 2006, 11:20:47 AM2/28/06
to Django developers
"This is great!" Schema evolution is something that I have wanted
since I started using Django. As a safety precaution you could add a
warning when you are running the migration/evolution.

ex. "Warning This May Destroy Your Data, And Render Your
Application Inoperable. Would you like to backup your database?"
[yes/no]

* If "yes" - Exit the script to backup of the database.

* If "no" - Proceed with the migration/evolution without a backup.

This will have the added benefit of making the procedure interactive so
that the migration/evolution command isn't accidentally executed
without some sort of verification.


--Nick

Christopher Lenz

unread,
Feb 28, 2006, 2:55:20 PM2/28/06
to django-d...@googlegroups.com
Am 28.02.2006 um 15:58 schrieb hugo:
>> I'm not sure exactly what reparations you're thinking will be
>> possible
>> by rolling back a DDL transaction. I'm pretty sure most db's don't
>> have full transaction control over DDL. Issuing a DDL statement
>> usually involves at least an implicit commit, so, e.g., if something
>> goes wrong three DDL commands into your evolution you're not going to
>> be able to roll back to initial state.
>
> PostgreSQL and SQLite fully support transactioned DDLs.

Actually, PySQLite 2.x does an implicit commit after any DDL
statement. I don't think this is enforced at the SQLite level, but
supposedly the PySQLite author had reasons to do this in the bindings.

Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

Jeremy Dunck

unread,
Feb 28, 2006, 3:39:02 PM2/28/06
to django-d...@googlegroups.com
On 2/28/06, Christopher Lenz <cml...@gmx.de> wrote:
> Actually, PySQLite 2.x does an implicit commit after any DDL
> statement. I don't think this is enforced at the SQLite level, but
> supposedly the PySQLite author had reasons to do this in the bindings.

Do you know what the reasons were, or where we should look for them?
The spec sez no implicit commits:

"
Note that
if the database supports an auto-commit feature, this must
be initially off. An interface method may be provided to
turn it back on.
"

Given that there's almost no other discussion of transaction behavior,
I think this should have some weight. Since I'm poking at SQL Server
support (which also does auto-commit), I'd like to know what the issue
was before stepping in it.

Luke Plant

unread,
Feb 28, 2006, 6:22:13 PM2/28/06
to django-d...@googlegroups.com

As others have said - great work.

I'm not sure about versioning on a per model basis -- I think a single
version number per database (or, more likely, per 'app') is better.
Upgrades will often affect more than one model, esp foreign key type
changes. For databases that support transactions, you will want to do
changes to the all the affected models or nothing at all, so having a
single version number to update when you have successfully upgraded
seems to make much more sense. At my day job I know we have a system
for clients web sites that works in this way. It also has the concept
of multiple 'apps' within a physical database, and has a single
'schema' table that is used to keep track of it.

This method also has the advantage that version numbers don't pollute
your model, but store this in a separate table. It might also be nice
to keep track of all past updates, not just the current version -- so
as well as an integer field for the version number you'd have a text
field containing the actual SQL that was executed to upgrade to that
version, and the date of upgrade for completeness. That could be a
great help for debugging problems, and reproducing the schema of the
live DB on a testing database.

There might be a problem if someone changed the DB schema outside of the
django method, but even then, there would at least be a table where
they could manually log what they've done. It might even be possible
to inspect those tables and check that the current schema is what it
ought to be.

Luke


--
"Procrastination: Hard work often pays off after time, but laziness
always pays off now." (despair.com)

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/

sal

unread,
Feb 28, 2006, 8:31:00 PM2/28/06
to Django developers

I like what you've said.
For many years I worked on a development project that was heavily
database dependant. We developed our own migration system similar to
yours. With multiple developers with their own versions of code and
local databases, as well as various testing servers, and different
customers on different release versions, this approach proved to be
very robust and reliable. It always allowed any developer to dig
himself out of a versioning problem.

I personally like the per model versioning soution. It keeps things
modular, and I feel that is a big goal with Django.

I would encourage building in some sort of easy way to check for
mismatched versions of the database and code. Versioning problems for
large systems are really difficult to solve without help. Perhaps a
flag in the settings module would turn on auto versioning check and
somehow warn a user of any mismatches, then they can choose what to do
next (maybe I don't want to upgrade the db, but instead rollback my
code for a particular server).

I like the introspection idea if it can save time for me on easy
changes. And it is nice for newbies, but there is no point in solving
overly difficult schema migration problems automatically. I don't see
how someone can remain a database newbie while simultaneously
developing a system complicated enough to need such migration support.

Maybe the introspection system could generate some automatic comments
with the before and after schemas of a migration script. Just looking
at scripts, it can be difficult to tell the purpose. But a quick glance
at schemas would be really nice.

Thanks for the great work on Django, btw. I intend to get rich by
standing on your shoulders. :)

sean

Luke Plant

unread,
Mar 1, 2006, 4:19:07 AM3/1/06
to Django developers

> This method also has the advantage that version numbers don't pollute
> your model, but store this in a separate table.

Ignore that bit, you were already suggesting that version numbers are
stored in a separate table, I didn't read it very carefully.

Luke

Christopher Lenz

unread,
Mar 1, 2006, 5:49:24 AM3/1/06
to django-d...@googlegroups.com
Am 28.02.2006 um 21:39 schrieb Jeremy Dunck:
> On 2/28/06, Christopher Lenz <cml...@gmx.de> wrote:
>> Actually, PySQLite 2.x does an implicit commit after any DDL
>> statement. I don't think this is enforced at the SQLite level, but
>> supposedly the PySQLite author had reasons to do this in the
>> bindings.
>
> Do you know what the reasons were, or where we should look for them?

I'm not really sure, here's the code that does it:

http://initd.org/tracker/pysqlite/browser/pysqlite/trunk/src/
cursor.c#L509

... which just says "to be safe" :-P

Brant Harris

unread,
Apr 24, 2006, 2:47:40 PM4/24/06
to django-d...@googlegroups.com
I've created a proposal for working all of the Schema Evolution tidbits out:
http://code.djangoproject.com/wiki/SchemaEvolutionProposal

If you get a chance to read and comment, I'd appreciate. I think it's
a good system. Obviously there are a lot of things to think about.
But this would be a good place to start.

Thanks

On 2/27/06, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>

joe.d...@gmail.com

unread,
Apr 26, 2006, 3:22:15 PM4/26/06
to Django developers
Hi all, I'm a CS undergrad at the University of Minnesota. I hope to do
a Summer of Code project with Django. Specifically I'd like to work on
schema evolution. I just wanted to introduce myself and get involved in
the process.

So enough with the introductions. On to my comments on the proposal:

I like the per app versioning. I think that per model versioning could
easily get ugly. Keeping track of the relationships between models with
different version numbers would not be any fun. Also, expressing the
evolution at the app level allows evolve to create new models (as in
the blog example of adding a tags model). Also, per app versioning
keeps the version numbers of related models in sync. If we had per
model versioning then we might have an up to date tags model at version
2 and an up to date entries model at version 3. That feels wrong. Since
the models are related to each other, if they're both up to date it
makes sense for them to have identical version numbers.

I wonder if we want to support 'devolving' (going back to old
versions). I think devolving should be treated exactly the same as
evolving - you actually never go back to old versions, you just evolve
your models so that they are the same as they used to be. Having some
special mechanism that would automagically devolve models would either
cause lossage or be rather messy.

For example evolving might remove a field from a model. Devloving
should recreate the field, but what about the data that the model used
to have in that field? The user probably wants their data back, but I
don't think there's a good way to automagically recreate the data short
of keeping track of all the schemas that have ever existed and all the
data that's ever been in the model. So trying to make devolving more
automatic than evolving either means a big mess of tables of data that
used to exist or a large potential for lossage. Still, it feels like
there is a better way to deal with devolving. Since we already have an
explanation of how to evolve it feels like we ought to be able to
automatically figure out how to devolve.

Joe

Brant Harris

unread,
Apr 26, 2006, 3:52:02 PM4/26/06
to django-d...@googlegroups.com
Hi Joe.

"devolving" or performing a "rollback" on an evolution is covered only
slightly at the end of my proposal. Basically the idea would be to
also add "pre_rollback" and "post_rollback" function hooks for the
evolve() function as well. This way, the responsible admin would be
able to provide rollbacks whenever needed. But we can't problem
ourselves with the possible loss of data. That's just going to be
there. We can minimize, but I think the best option is to suggest
backing up of the database to the user.

joe.d...@gmail.com

unread,
Apr 27, 2006, 4:23:09 PM4/27/06
to Django developers
Ok, thanks for clarifying on the comment on rollbacks.

Still, I think rollbacks shouldn't be included. From the user's
perspecitive there won't be much difference between a rollback and an
evolve. In both cases they can write pre and post (or pre_rollback and
post_rollback) functions. Granted, they'll have to remember what their
models used to look like, but its not really up to us to make backups,
right? If a user really wants to rollback a production app, they can
get an old version of models.py out of their revision control and
evolve with it. If they're prototyping a new app and a change breaks
something, chances are they made a small mistake. Don't rollback - fix
the mistake and evolve forward.

Its just not clear to me what we're gaining from rollbacks. On the
other hand, keeping track of all the shadows will clutter things up a
lot in the code and in either the filesystem or database (whereever
shadows end up living).

Joe

Brantley Harris

unread,
Apr 27, 2006, 4:35:14 PM4/27/06
to django-d...@googlegroups.com
The rollbacks are really only usefull (in my mind) for when you go
forward on an app, and it turns out to break something, so you
"rollback". I do think it is a bit of a fringe-case, and can be
handled by proper database backing up. However, I don't see why we
couldn't support it. Plus, I've figured out that we're going to have
to keep a record of the models anyway.

Malcolm Tredinnick

unread,
Apr 27, 2006, 8:54:34 PM4/27/06
to django-d...@googlegroups.com

Coming from a background of using very large databases that evolve over
time in high-availability, tightly controlled environments: the ability
to rollback is very useful, because it matches the ability to roll back
any other upgrades. You are proposing to implement rollback via "roll
forwards to something we hope is equivalent", but in many production
environments in large corporations, that isn't an acceptable risk. You
need to be able to roll *back* to the earlier version and be able to
prove (in some sense) that it is identical to the earlier version. This
includes things like version numbers being the same as they were before
the upgrade.

Now, that being said, if Django didn't support this as part of schema
evolution, the world will not end. In situations like the above, we
would do what we do now (as you suggest), backup the schema before the
upgrade and if we have to roll back work out a script to remove any
extra data that is in the new columns and restore the schema to the
backed up version. Such a procedure is often part of the rollout
preparation.

So we can document rollback as out of scope and suggest how to do it
outside of Django, but there is a difference between rollback and evolve
in an accountable production environment.

Regards,
Malcolm

joe.d...@gmail.com

unread,
Apr 27, 2006, 10:53:03 PM4/27/06
to Django developers
My hope is that it won't be 'roll forwards to something we hope is
equivalent' because the user would be using evolve with the old version
of their schema, hopefully from their revision control. If you're using
the exact same schema as you were before you rolled out the upgrade
than you're rolling forwards to something you know is equivalent. I
suppose you don't know with certainty that the path taken to get from
one version of your schema to the next and then back again will be
identical. But you do know that whenever you evolve, you end up with
tables in the database that exactly match the schema you're evolving
to. It will remain the admin's responsibility to make sure their data
migrates safely. Either you have to write pre_rollback and
post_rollback functions to migrate your data or you have to write pre
and post functions.

I suppose when rolling forward to the old version, evolve might not
realize that a particular field should be altered. In other words, it
might delete one field and create another rather than altering the
existing field. Keeping an exact record of how things were upgraded
would allow you to undo exactly what was done. This could prevent some
data lossage. But exactly the same thing (a field getting deleted when
it should get altered) could happen when you're upgrading, and if that
happens it doesn't do you any good to be able to roll back in exactly
the same way as you rolled out. I don't think there is a way to prevent
the possibility of losing your data. So, it seems crazy to roll out
changes without backups.

The way I envision things happening is, if you want to rollback your
schema along with other upgrades you would just rollback to an older
version of your revision control system, which would roll back the
schema and the upgrades that came along with it. Then all you have to
do is write pre and post and evolve your schema.

What I think evolve should do is guarentee you that the schema you have
in models.py is exactly the schema in the database, and provide
function hooks to allow you to write migration code.

Of course, you guys are all a lot more experienced with large
corporations and the risks they're willing to take. If this is
unrealistic just let me know. Also, Brant said something along the
lines that we would have to keep track of all the versions anyway - why
is that?

Malcolm Tredinnick

unread,
Apr 28, 2006, 12:15:16 AM4/28/06
to django-d...@googlegroups.com
On Fri, 2006-04-28 at 02:53 +0000, joe.d...@gmail.com wrote:
> My hope is that it won't be 'roll forwards to something we hope is
> equivalent' because the user would be using evolve with the old version
> of their schema, hopefully from their revision control. If you're using
> the exact same schema as you were before you rolled out the upgrade
> than you're rolling forwards to something you know is equivalent. I
> suppose you don't know with certainty that the path taken to get from
> one version of your schema to the next and then back again will be
> identical. But you do know that whenever you evolve, you end up with
> tables in the database that exactly match the schema you're evolving
> to. It will remain the admin's responsibility to make sure their data
> migrates safely. Either you have to write pre_rollback and
> post_rollback functions to migrate your data or you have to write pre
> and post functions.

I guess I may be remembering something we talked about earlier, but we
were talking of tracking version numbers in the tables or something like
that. That is where I have problems with using rollback as roll forwards
to an older schema, because version numbers would incremement.
Otherwise, everything you say makes sense (except we probably can prove
the forwards and backwards will be the identity; I would hope we would
try, at least).

> I suppose when rolling forward to the old version, evolve might not
> realize that a particular field should be altered. In other words, it
> might delete one field and create another rather than altering the
> existing field. Keeping an exact record of how things were upgraded
> would allow you to undo exactly what was done. This could prevent some
> data lossage. But exactly the same thing (a field getting deleted when
> it should get altered) could happen when you're upgrading, and if that
> happens it doesn't do you any good to be able to roll back in exactly
> the same way as you rolled out. I don't think there is a way to prevent
> the possibility of losing your data. So, it seems crazy to roll out
> changes without backups.
>
> The way I envision things happening is, if you want to rollback your
> schema along with other upgrades you would just rollback to an older
> version of your revision control system, which would roll back the
> schema and the upgrades that came along with it. Then all you have to
> do is write pre and post and evolve your schema.
>
> What I think evolve should do is guarentee you that the schema you have
> in models.py is exactly the schema in the database, and provide
> function hooks to allow you to write migration code.
>
> Of course, you guys are all a lot more experienced with large
> corporations and the risks they're willing to take. If this is
> unrealistic just let me know. Also, Brant said something along the
> lines that we would have to keep track of all the versions anyway - why
> is that?

It is not my intention to put a halt to your ideas. They all seem
sensible to me. I was just raising a warning that there are real
situations where rollback cannot be interpreted as roll forwards to
something equivalent. But, as I mentioned in the original email, this is
handled today anyway by external procedures and in those (relatively
rare) situations where it's required, it can continue to be handled that
way.

Focus on working out the schema evolution and making it work. The
details will sort themselves out. There don't appear to be any real
holes in your plan. :-)

Cheers,
Malcolm

Jeroen Ruigrok van der Werven

unread,
May 29, 2006, 8:25:28 AM5/29/06
to django-d...@googlegroups.com
Brant,

On 4/24/06, Brant Harris <deadw...@gmail.com> wrote:
> I've created a proposal for working all of the Schema Evolution tidbits out:
> http://code.djangoproject.com/wiki/SchemaEvolutionProposal
>
> If you get a chance to read and comment, I'd appreciate.

I noticed in the code that you have auto_add_now, whereas it should be
auto_now_add. At least according to
http://www.djangoproject.com/documentation/model_api/

--
Jeroen Ruigrok van der Werven

Derek Anderson

unread,
May 29, 2006, 11:09:37 AM5/29/06
to django-d...@googlegroups.com
jeroen, brant, ilias, etc:

schema evolution was an idea suggested and specifically granted for the
SoC project. i don't know who here was involved with ranking the
proposals, but for better or worse mine was accepted. to a certain
extent i expect this to come with a effort not to trivialize my
existence here before i can even get off the ground.

more to the point: if you have and ideas/recommendations, i'd love to
hear them. if you have questions regarding my abilities/qualifications,
i'll answer those too. but in terms of going forward with your own
implementations, i ask that you put them on hold for just a little
while. if i fail miserably you won't be but a month or two behind
schedule. surely, until then, there are other areas in which you could
contribute without so sharply undercutting my chance for success.

thank you,
-- derek

Todd O'Bryan

unread,
May 29, 2006, 12:03:42 PM5/29/06
to django-d...@googlegroups.com
On May 29, 2006, at 11:09 AM, Derek Anderson wrote:

> schema evolution was an idea suggested and specifically granted for
> the
> SoC project. i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted.

And I for one am very excited.

Do you have an outline somewhere, or is there a copy of your proposal
around that we can comment on?

Todd

Jeroen Ruigrok van der Werven

unread,
May 29, 2006, 12:39:19 PM5/29/06
to django-d...@googlegroups.com
On 5/29/06, Derek Anderson <pub...@kered.org> wrote:
> schema evolution was an idea suggested and specifically granted for the
> SoC project. i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted. to a certain
> extent i expect this to come with a effort not to trivialize my
> existence here before i can even get off the ground.
>
> more to the point: if you have and ideas/recommendations, i'd love to
> hear them. if you have questions regarding my abilities/qualifications,
> i'll answer those too. but in terms of going forward with your own
> implementations, i ask that you put them on hold for just a little
> while. if i fail miserably you won't be but a month or two behind
> schedule. surely, until then, there are other areas in which you could
> contribute without so sharply undercutting my chance for success.

Erhm, the way I read this email answer above you sound a bit miffed.
All I did was email Brant and the list about an issue in the code on
the proposal page I thought Brant put up. If that means that "your
existence gets trivialized" and "your chance for success is sharply
undercut" I seriously have to wonder if you don't need to:

1) read emails with less emotion and/or assumptions;
2) take a break since it almost sounds as if you're overworked or stressed out.

--

Derek Anderson

unread,
May 29, 2006, 1:30:23 PM5/29/06
to django-d...@googlegroups.com
proposal is here:
https://kered.org/blog/2006/05/24/summer-of-code/

it's more of a bit on a previous/related effort i did than a specific
plan for django. i'm new to this project, and just starting my way
through your all's modeling framework. more will be coming.

jeroen:
not miffed. just marking a little tree in a big forest. :)

Jeroen Ruigrok van der Werven

unread,
May 29, 2006, 1:55:47 PM5/29/06
to django-d...@googlegroups.com
On 5/29/06, Derek Anderson <pub...@kered.org> wrote:

I will check it out later this week.

> it's more of a bit on a previous/related effort i did than a specific
> plan for django. i'm new to this project, and just starting my way
> through your all's modeling framework. more will be coming.

You will find the Django community, as far as I have known it for the
past 9 months or so, very enthusiastic and helpful. In general there's
a large consensus build-up towards decisions (you might be familiar
with +1, 0, -1 votes on email lists, if not, see
http://www.djangoproject.com/documentation/contributing/ - Deciding on
features).

So in other words: welcome.

> jeroen:
> not miffed. just marking a little tree in a big forest. :)

That's good to know, because people *will* read and react to your
proposals. All of this to get Django better.

Like I said, at the end of the week I will comment, since I should
have some free time then.

--

Ilias Lazaridis

unread,
May 29, 2006, 2:43:06 PM5/29/06
to django-d...@googlegroups.com
Derek Anderson wrote:
> jeroen, brant, ilias, etc:
>
> schema evolution was an idea suggested and specifically granted for the
> SoC project. i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted. to a certain
> extent i expect this to come with a effort not to trivialize my
> existence here before i can even get off the ground.

I understand that you feel this way.

But I assure you, that I do not trivialize your existence.

> more to the point: if you have and ideas/recommendations, i'd love to
> hear them. if you have questions regarding my abilities/qualifications,
> i'll answer those too. but in terms of going forward with your own
> implementations, i ask that you put them on hold for just a little
> while. if i fail miserably you won't be but a month or two behind
> schedule. surely, until then, there are other areas in which you could
> contribute without so sharply undercutting my chance for success.

Again I like to tell you that I understand the way you feel and react.

Your suggestions are rational.

But, I for my case cannot fall 1 or 2 months behind the schedule.

To be able to continue the Django Audit...:

http://case.lazaridis.com/multi/wiki/DjangoAudit

...I need a _simple_ evolution mechanism immediately ("add field"
functionality, will be available most possibly tomorrow).

If you read the plan, you will notice that I take the existent SoC
project (and thus you) fully in account:

http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution?version=5

-

(btw: I've noticed this old thread by 'accident')

> thank you,
> -- derek
>
>
> Jeroen Ruigrok van der Werven wrote:
>> Brant,
>>
>> On 4/24/06, Brant Harris <deadw...@gmail.com> wrote:
>>> I've created a proposal for working all of the Schema Evolution tidbits out:
>>> http://code.djangoproject.com/wiki/SchemaEvolutionProposal
>>>
>>> If you get a chance to read and comment, I'd appreciate.
>> I noticed in the code that you have auto_add_now, whereas it should be
>> auto_now_add. At least according to
>> http://www.djangoproject.com/documentation/model_api/
>>
>
> >
>


--
http://lazaridis.com

Brantley Harris

unread,
May 31, 2006, 2:01:16 PM5/31/06
to django-d...@googlegroups.com
Yeah, I always do that. Sorry.

Brantley Harris

unread,
May 31, 2006, 2:02:25 PM5/31/06
to django-d...@googlegroups.com
You got it. I could barely get any feedback on this project anyhow,
and I don't have much time right now to focus on it. So, no problem.

GL

On 5/29/06, Derek Anderson <pub...@kered.org> wrote:
>

Reply all
Reply to author
Forward
0 new messages