Noam Raphael wrote:
> On 7/4/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
>> I don't like the "edit the file" part. I can think of 2 alternatives:
>>
>> 1. add an attribute to one/both of the models. something like
>>
>> class Book(models.Model):
>> name = models.CharField(blank=True, "migrate_to"="book_name" )
>>
>> 2. a 3rd file that defines those kind of translations, which might be about
>> the
>> same by just subclassing the existing models.
>>
>> class Book(models.Book):
>> book_name = Book.name()
>>
>> (I am totally winging it here, so forgiveme if my brain storm has some
>> turbulence.)
>>
>
> What I like about my idea is that you don't need to learn new syntax
> for migration. And syntax like this will never be enough - for
> example, how would you convert a field with a full name into two
> fields, the first name and last name? Using my idea, it will simply
> be:
>
> n.first_name, n.last_name = o.name.split()
>
> (Well, you would have to add some error handling, but it won't be a
> lot more complicated.)
The problem I see is maintaining the generated file. This process will often
start before the target system is stable, so as soon as you start making
changes
to the target model, the converter will need to be updated too. If the
transformation formulas are part of one of the models, then there isn't
anything
to keep in sync.
maybe put the transformation in the target model:
def getfirst(name):
return name.split()[0]
def getfirst(name):
return name.split()[1]
first_name = models.CharField(blank=True, "migrate_from"="getfirst(name)"
)
last_name = models.CharField(blank=True, "migrate_from"="getlast(name)" )
but I am not thrilled about jamming a bunch of conversion stuff in the new
model
either. conversion stuff sucks.
>
>> Also, along the lines of slow... you are going to love this one: how about
>> making it use the web server as the source which would allow migrating
>> between 2
>> servers where http is the only exposed protocol? it would also take care of
>> migrating between systems where I don't have both db stacks installed on one
>> box
>> - consider win/mssql -> linux/SqlLite. yeah yeah, django/mssql doesn't exist
>> yet... but it makes a good example :)
>
> I think that for this you can use "./manage.py dumpdata" and
> "./manage.py loaddata". See
> http://groups.google.com/group/django-users/msg/02f5447f41207a65
But then you don't get any of the nifty transformations which is kinda the
point
of your idea.
Carl K
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
