On 7/4/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > > 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. > You don't have to maintain the generated file. After you've updated the database, there's no need to keep it. When you want another update to the database, you create a new file and change there what you want.
> > > > >> 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. > Well, you can separate nifty transformations (which will be done on one computer) and system migration. Noam --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
