First, I want to be 100% sure that we're having the same definition of this field. This field represents an upstream server-side ID that is tied to that specific set of changes, and will exist up to and possibly past the point where the change is committed, regardless of how many updates are made to that review request. The upstream changeset information should contain useful information, such as the description or bugs closed. Once a changenum is set on a review request, it should not change.
To my knowledge, django-evolution has no way of changing a field's type to an incompatible type. The FakeChangeFieldType works because the two types are, at the database level, the same. Changing data types is a lot harder, and there's 0 support for this in Django Evolution. So right now, raw SQL would be the only current option (assuming it can be done in a standard way), but if we do it it must be thoroughly tested with every database type Django supports. I would say that my preferred option would be to patch django-evolution to support a ChangeFieldType that converted between certain types, and then use that. That could be unit tested and support could be tuned for each database type. Plus it's more reusable and other projects could benefit. Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.review-board.org VMware, Inc. - http://www.vmware.com On Thu, May 14, 2009 at 10:07 PM, Alexey Morozov <morozov...@ngs.ru> wrote: > > Hi! > > On Tuesday 12 May 2009 04:41:06 Christian Hammond wrote: > > > As for the DB change, we have a nice database migration system in place. > > You pretty much need to just make the change to the appropriate Model > > class(es) and then add an Evolution definition (see > reviews/evolutions/*.py > > for example). > > Is it possible to express schema evolution in terms of django_evolution > calls, > not raw SQLs? > > As for model change, I think it would be smth like this: > > diff --git a/reviews/models.py b/reviews/models.py > index 570551c..38e112b 100644 > --- a/reviews/models.py > +++ b/reviews/models.py > @@ -180,7 +180,7 @@ class ReviewRequest(models.Model): > status = models.CharField(_("status"), max_length=1, choices=STATUSES, > db_index=True) > public = models.BooleanField(_("public"), default=False) > - changenum = models.PositiveIntegerField(_("change number"), > blank=True, > + change_id = models.CharField(_("change ID"), max_length=255, > blank=True, > null=True, db_index=True) > repository = models.ForeignKey(Repository, > related_name="review_requests", > > but I'm not sure how existing RB DBs should be evolved. Seems that neither > djblets' FakeChangeFieldType nor django_evolution's ChangeField isn't > suitable for the task. Simply add a field and then write a raw SQL to copy > data? Would it be portable enough? Any comments? > > Alexey Morozov > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
