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 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:
> 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
> > for example).
> Is it possible to express schema evolution in terms of django_evolution
> 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,
> public = models.BooleanField(_("public"), default=False)
> - changenum = models.PositiveIntegerField(_("change number"),
> + change_id = models.CharField(_("change ID"), max_length=255,
> null=True, db_index=True)
> repository = models.ForeignKey(Repository,
> 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
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at