Issue 75: Evolving forums
Status:  Done
Owner:
Closed:  Sep 2009
Reported by feric...@gmail.com, Aug 31, 2009
What steps will reproduce the problem?
1. Deploy a forum before adding body_html
2. Update the forum
3. Try to evolve it

The body_html cannot be evolved because it does not have a default value
and it cannot be null. I made it nullable and after that I resaved all the
posts (it were only a few at this time). Is there another way to do it?
Sep 2, 2009
#1 byme...@gmail.com
But why do you want the body_html to be null? Any message cannot be null, so either
the body_html.

Did you run the commands detailed in the new README.txt?
Sep 3, 2009
#2 feric...@gmail.com
I don't want body_html to be null but I am using django-evolution (alternative to
south or dmigrations). This is why I did not write the ALTER commands described in
your README.txt. In this case we don't want it to be null or have some '' default
value but we would add that for the migrations to work (I guess your ALTER command
adds the body_html COLUMN with null value too, until we call the save method for all
the posts). 

What I have done to be able to run ./manage evolve is:
1. make body_html nullable (so it could be added with the null value to the past Posts)
2. run the evolve command
3. change the models.py file back (remove nullable attributes) to be able to update
from you in the future without potential conflicts

The problem now is that I wont be able to evolve something else in the future because
django-evolution will detect that my Post models are changed since my last evolve
(and it will not be willing to evolve Posts.body_html the way they are now) and will
not run my other model migration either.

In the current state I won't be able to use django-evolution to evolve django-forum
and will have to run commands from your README.txt, which is not so bad but is kind
of rudimentary (especially considering that I have the django-evolution system
installed and tracking my changes).

I can still run the evolve command specifying my other application names to avoid
django-forum.

In conclusion it is not so bad but it's a little annoying.
Sep 3, 2009
#3 byme...@gmail.com
Oh yeah, shit happens! :D
Well, I don't know if there's a better solution for django-evolution users. For now
we have the rudimentary methods which at least work.
Sep 3, 2009
Project Member #4 rwpoul...@gmail.com
Hi fericean,

I'll take your suggestion on board: Rather than making a field non-null if it's being
added after the rest of the model, we'll try to make it 'null=True' in models.py. In
this example it wouldn't have made a difference to the actual application and would
have made your life easier.

Are there any other guidelines we should be trying to follow? Keeping in mind that
this is an in-progress application rather than a stable release.
Status: Done
Owner: rwpoulton
Sep 3, 2009
#5 feric...@gmail.com
From my point of view if the added fields have default values or can be null then the
models can be migrated easily. I have a django-forum in production but when you
commit some changes I try them first in a staging area so if I see any problems I'll
let you know together with my proposed solution.

So thanks a lot and keep up the good work,
Radu Fericean from Romania :)
Sep 3, 2009
#6 byme...@gmail.com
Hi Ross. It's a good solution but only temporarily and for special migration cases.

If we want our application to be strong to failures it should be null. If something
bad happens creating a message then we may have a null body_html field, and this is
the last thing we want.
Sep 3, 2009
Project Member #7 rwpoul...@gmail.com
IMO if we can make life easier for people using 3rd party software with relatively
little effort on our part, we should do so.

Not saying that always making fields 'null=True' is a good thing; just that we should
try and be responsible netizens.
Sep 3, 2009
#8 byme...@gmail.com
OK, it's a good valid point of view. My support for the idea.