hi, I had 4 legacy sites running on pre-MR django, written back in 2005. Since feature requests were minimal once the apps were complete, there was no reason to upgrade them. Recently however, after I started using virtualenv for my trunk apps, I was having problem with admin log in on the old apps. Apparently admin login was looking in the wrong place for authentication and I was getting a postgresql error - a restart of apache usually set this right temporarily, but users started complaining. So I migrated the apps to trunk. The process may be of interest to someone, so here is a brief documentation of the process:
1. models: global search and replace to change 'meta' to 'models', maxlength to max_length, lazydate to datetime.now, META to Meta. Then manually moving admin to the new admin.py. 2. views: the basic structure of the views is the same. Only the query syntax has changed. This has to be done manually, line by line. '.html' has to be added to the template names. Imports have to be changed - just a copy/paste from the imports in any uptodate app suffices. template_loader is no longer used. I found to my surprise that the forms were made manually - either django did not have forms then, or I did not use them. The forms had to be rewritten using ModelForms and the corresponding templates also rewritten. 3. urls: no change 4. templates: .html extension was added. obj.get_foo_url changed to obj.foo.url for files and images. 5. thumbnails: I had been using nesh thumbnails. The whole nesh code had to be removed from templatetags. It was replaced with sorl.thumbnail. Slight change in template code to accomodate sorl.thumbnail syntax. Replacement of ImageWithThumbnail with ImageField in models did the trick. 6. database: I am using postgresql, and in the various shifts I had done, the existing databases were in 8.x. I did a pg_dump using -a (data only) and -D (inserts with column names). This sql file had to be massaged with a series of document wide search and replace operations - comparison of the output of \dt on the old and new databases gave what needed to be changed. Basically changing plural to singular. And some name changes, for example 'sites' becomes 'django.site', 'core.sessions' becomes django.session. I then did a syncdb on the new database and read the massaged file into it. The only errors were regarding 'packages' which do not appear to have an equivalent in the latest trunk. On testing the sites, I found that no data was lost (or if anything was lost it was not significant). Anyway I retained the old databases in case of need. Net result: process was rather tedious, but no real blocks. At first I had done a pg_dump using -a and -d, and got into trouble because the order of fields had changed. But doing a -D solved this problem. Hope this helps anyone who is hesitating about such a migration. -- regards kg http://lawgon.livejournal.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
