django_evolution is reporting the version of '0.5'. This was what was easy_install'ed.
We're trying to do the clearly-documented-as-unsupported task of switching from SQLite3 to mysql, and at the same time, switch from RB beta 0.8 to version 1.5, without losing any data. The new and old RBs are on different systems. "Export old DB, import into new DB" means that something goes wrong, or I screw it up badly, I can easily start all over again with a fresh import. :-) The plan is to go RB0.8:SQLite3 ->[Python Script] -> RB0.8 MySQL -> [import and evolve] ->RB1.5MySQL. I constructed a python script to convert the exported SQLite data to MySQL statements, by combining and cleaning up a number of "found" generic conversion scripts, as well as diagnosing problems from a few almost-successful import attempts. (I can't guarantee that it would work for any other SQLite database, but for a ReviewBoard one, it seems to produce the right result now that I figured out that SQLite's TEXT type should be mapped to MySQL's LONGTEXT type.) I can post it here (with the obvious "YMMV" caveat), if there's interest. So now we face the exciting task of getting the data in and updated. Import occurs without any problem (finally). I'm not completely sure what the steps should be next. The choices seem to be: 1) Create the database in MySQL 2) Import the data into it. 3) Create a new RB, pointing it at the database Doing this resulted in output containing (among other things): *** Migrating settings from settings_local.py to the database. *** If you have previously configured Review Board through a *** settings_local.py file, please ensure that the migration *** was successful by verifying your settings at *** http://zzzzzz.com/admin/settings/ There are unapplied evolutions for diffviewer. There are unapplied evolutions for reviews. There are unapplied evolutions for scmtools. ... ...but oddly enough, the thing seemed to actually work pretty well. Further attempts at evolution and sync'ing resulted yielded "There's nothing to do" sorts of messages. My confidence in this is guardedly optimistic, since everything I tried when subsequently using RB didn't show any breakage. But I'm worried about something breaking a mile or two down the road, after we've been using it, and don't have a way back... What I probably should have done was: 1) Create but not populate the database in MySQL. 2) Create a new RB, pointing it at the empty database. 3) Import the data. 4) rb-site manage /site/www/legacyrb evolve -- --execute 5) rb-site manage /site/www/legacyrb syncdb Like I said, I can start over and experiment at this point, since we're going to do all of this again when we decide to do The Final Migration. Any suggestions as to which approach to take, or how to proceed after the import? Thanks, m@ On Oct 25, 2:22 am, Christian Hammond <chip...@chipx86.com> wrote: > The hints are not something you should ever have to do with Review Board. In > fact, doing so can break things badly. > > First, I hope you have a backup of the database, in case things go wrong. > > Can you tell me what version of django-evolution is installed on that > system? You can check by doing: > > $ python > >>> import django_evolution > >>> django_evolution.__version__ > > Let me know what that says. > > Is this the same system that ran the old Review Board instance? > > Christian > > -- > Christian Hammond - chip...@chipx86.com > Review Board -http://www.reviewboard.org > VMware, Inc. -http://www.vmware.com > > On Mon, Oct 25, 2010 at 12:07 AM, mxbraun <matthew.br...@intel.com> wrote: > > I'm trying to evolve a very old database (Beta 0.8) to version 1.5, > > and running into a problem. When I try the command: rb-site manage / > > site/www/legacyrb evolve -- --execute > > I get the message: > > The stored evolutions do not completely resolve all model changes. > > Run `./manage.py evolve --hint` to see a suggestion for the changes > > required. > > The following are the changes that could not be resolved: > > In model reviews.DefaultReviewer: > > Field 'repository' has been added > > In model reviews.ReviewRequest: > > Field 'changedescs' has been added > > Field 'shipit_count' has been added > > Field 'last_review_timestamp' has been added > > In field 'repository': > > Property 'null' has changed > > ... > > In model diffviewer.FileDiff: > > Field 'status' has been added > > Field 'parent_diff' has been added > > Field 'diff' has been added > > Field 'diff_base64' has been deleted > > In field 'source_file': > > Property 'max_length' has changed > > In field 'dest_file': > > Property 'max_length' has changed > > > Question 1: Ummm...why couldn't those changes be resolved? Will they > > be resolved with a syncdb? > > > So I follow the command's advice, and execute "evolve --hint", which > > tells me (among other things): > > #----- Evolution for diffviewer > > from django_evolution.mutations import * > > from django.db import models > > > MUTATIONS = [ > > AddField('DiffSet', 'basedir', models.CharField, initial=u'', > > max_length=256), > > AddField('FileDiff', 'status', models.CharField, initial=<<USER > > VALUE REQUIRED>>, max_length=1), > > AddField('FileDiff', 'parent_diff', models.Base64Field, > > initial='', db_column='parent_diff_base64'), > > AddField('FileDiff', 'diff', models.Base64Field, initial=<<USER > > VALUE REQUIRED>>, db_column='diff_base64'), > > > So I figure, "Okay, we have the hints--we just need to execute them." > > So I ran: > > # rb-site manage /infrastructure/www/legacyrb evolve -- --hint -- > > execute > > Cannot use hinted evolution: AddField or ChangeField mutation for > > 'FileDiff.status' in 'diffviewer' requires user-specified initial > > value. > > > So, questions: > > 2) How can I specify an appropriate user value? > > 3) The evolution file for filediff.status, where a USER VALUE REQUIRED > > says: > > MUTATIONS = [ > > AddField('FileDiff', 'status', models.CharField, initial='M', > > max_length=1) > > ] > > Looks to me like an initial value is there, and it's an 'M'. What's > > the problem? > > 4) Can I use evolution in this case, or do I need to resort to just > > making the required changes at the SQL level? If so, how are the > > 'db_column' parameters handled? > > > Thanks, > > > m@ > > > -- > > Want to help the Review Board project? Donate today at > >http://www.reviewboard.org/donate/ > > Happy user? Let us know athttp://www.reviewboard.org/users/ > > -~----------~----~----~----~------~----~------~--~--- > > To unsubscribe from this group, send email to > > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~----------~----~----~----~------~----~------~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en