| Issue 75: | Evolving forums | |
| 1 person starred this issue and may be notified of changes. | Back to list |
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
Sep 3, 2009
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
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
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
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
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
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
OK, it's a good valid point of view. My support for the idea. |