Ticket #275 (closed defect: fixed)

Opened 5 years ago

Last modified 3 years ago

restrict migration names to be valid module names

Reported by: stefanfoulis Owned by: andrew
Priority: major Milestone: 0.7
Component: commands Version: 0.6.2
Keywords: Cc:

Description

migration names can contain nearly any character. this can result in migration filenames like:
"0005_model X: added null = True to stuff.py"
On most filesystems this will work fine. But on windows ":" and "?" are not allowed in filenames. Also these are invalid python module names (only alphanumerics, numbers and "_" are allowed)

South should prevent migration names that create invalid python module names.
For usability south could automatically replace spaces and dashes with underscores.

see http://groups.google.com/group/south-users/browse_thread/thread/b9654c73f27e51f5

Attachments

275.patch (8.9 KB) - added by anonymous 5 years ago.

Change History

Changed 5 years ago by anonymous

comment:1 Changed 5 years ago by rob@…

I've attached some patches that attempt to tackle this. I've broken it down into four patches so that hopefully it's easier to extract the useful parts (if any)

  1. Not really related to this issue but the --list command (which I originally wrote) uses the argument 'list' which overwrites the builtin list function. I took the opportunity to rename that argument to list_
  1. Added a function get_invalid_names that is run before the migration and prints warnings for names that are not valid module names
  1. Realised that list_migrations and get_invalid_names duplicate a lot of code so added the function apply_to_apps that takes a callback function. apply_to_apps build up the list of applied migrations and the list of all migrations in app.migration format and then just hands off to the callback for the output
  1. A modification to startmigration that rejects names with invalid characters

I realise now that adding warnings to migrate is pretty much useless. I wrote it to only give warning on unapplied migrations because migrations that have been applied would require the user to manipulate the migrationhistory table in order to repair the name. The potential problem is that, working on a shared project, Alice may have already applied migration 0003 when Bob is warned it has an invalid name and so renames it.

Basically, only the first and the forth patch could be useful

comment:2 Changed 5 years ago by andrew

  • Status changed from new to assigned
  • Milestone set to 0.7

Well, most of the startmigration code is in the process of being rewritten; I think I already renamed the 'list' variable, but I don't think we reject invalid migration names yet.

I'll keep that in mind; I don't think the patch will apply any more, but it's not terribly complex!

comment:3 Changed 5 years ago by andrew

  • Status changed from assigned to closed
  • Resolution set to fixed

I've applied the fix that stops startmigration from allowing invalid module names in [f9a6aa48461a]. list had already been renamed to show_list in the change, and the other changes don't really seem to apply now.

Note: See TracTickets for help on using tickets.