The warnings about unapplied evolutions during rb-site install/update are harmless. We're doing a syncdb, which Django Evolution listens to and then checks for unapplied evolutions, but we then follow it up with an evolve.
If you're not seeing the list of fields that couldn't be evolved anymore, you should be good! Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Mon, Oct 25, 2010 at 1:38 PM, mxbraun <matthew.br...@intel.com> wrote: > I should also mention that the creation of RB mentioned above, also > said that it was successful...not to be a doubting Thomas, > but...ummm ...honest? Are you sure? > > Here's the complete output from this segment of RB creation: > ------------------------------------------ > * Installing the site... > Building site directories ... OK > Building site configuration files ... OK > Creating database ... Creating table siteconfig_siteconfiguration > Creating table changedescs_changedescription > Creating table django_evolution > *** 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://reviews.xxxxxxxxx.com/admin/settings/ > There are unapplied evolutions for diffviewer. > There are unapplied evolutions for reviews. > There are unapplied evolutions for scmtools. > Adding baseline version for new models > Project signature has changed - an evolution is required > Installing index for siteconfig.SiteConfiguration model > Installing index for django_evolution.Evolution model > No fixtures found. > /usr/local/lib/python2.6/site-packages/pycrypto-2.3-py2.6-linux- > x86_64.egg/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: > This application uses RandomPool, which is BROKEN in older releases. > See http://www.pycrypto.org/randpool-broken > Registering new SCM Tool Clear Case > (reviewboard.scmtools.clearcase.ClearCaseTool) in database > OK > Performing migrations ... Evolution could not be simulated, possibly > due to raw SQL mutations > Evolution successful. > OK > Creating administrator account ... OK > Saving site settings ... OK > --------------------------------------------------------- > > I don't have evidence that it failed--in fact, it seems to work. My > concern is that I'm just not testing thoroughly enough. > > If "Congratulations--you're done" is the answer, hey, I'm all for > that. Just trying to figure out if I understand and should believe > what I'm seeing. :-) > > Thanks again, > > m@ > > > On Oct 25, 9:54 am, mxbraun <matthew.br...@intel.com> wrote: > > 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> > <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@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<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
