Evolving forums

[GoogleCodeExporter]

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?

Original issue reported on code.google.com by feric...@gmail.com on 31 Aug 2009 at 7:48

[GoogleCodeExporter]

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?

Original comment by byme...@gmail.com on 2 Sep 2009 at 9:58

[GoogleCodeExporter]

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.

Original comment by feric...@gmail.com on 3 Sep 2009 at 7:06

[GoogleCodeExporter]

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.

Original comment by byme...@gmail.com on 3 Sep 2009 at 10:31

[GoogleCodeExporter]

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.

Original comment by rwpoul...@gmail.com on 3 Sep 2009 at 11:19

• Changed state: Done

[GoogleCodeExporter]

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 :)

Original comment by feric...@gmail.com on 3 Sep 2009 at 11:27

[GoogleCodeExporter]

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.

Original comment by byme...@gmail.com on 3 Sep 2009 at 11:30

[GoogleCodeExporter]

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.

Original comment by rwpoul...@gmail.com on 3 Sep 2009 at 1:18

[GoogleCodeExporter]

OK, it's a good valid point of view. My support for the idea.

Original comment by byme...@gmail.com on 3 Sep 2009 at 1:32