Code

Changes between Version 13 and Version 14 of ContribAuthImprovements


Ignore:
Timestamp:
03/23/12 20:08:54 (2 years ago)
Author:
bhuztez
Comment:

I really doubt if solution 1/2 will introduce any circular dependency

Legend:

Unmodified
Added
Removed
Modified
  • ContribAuthImprovements

    v13 v14  
    5151 * Introduces a setting that immediately becomes deprecated (since it won't be needed once the migration cycle is complete) 
    5252 * Doesn't address the problem with any other usage of !EmailField having a max_length of 75. 
    53  * Introduces a circular dependency between settings and models. When settings are loaded, `INSTALLED_APPS` is inspected, and each models file is loaded. If a models file contains a reference to settings, hilarity can ensue. This isn't a problem *most* of the time, but it can lead to some interesting side effects. 
     53 * Introduces a circular dependency between settings and models. When settings are loaded, `INSTALLED_APPS` is inspected, and each models file is loaded. If a models file contains a reference to settings, hilarity can ensue. This isn't a problem *most* of the time, but it can lead to some interesting side effects. (Once you declare a field,  you probably already have settings imported, see code of {{{Field.__init__}}}) 
     54    {{{#!python 
     55        self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE 
     56    }}} 
    5457 
    5558== Solution 1a: Superminimal with forced migration == 
     
    164167 * Existing projects require no migration. the same as solution 2/2a. 
    165168 * Unlike solution 2a, change is not required for existing apps.  
    166  * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. the same as solution 2. 
     169 * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. the same as solution 2a. 
    167170 
    168171=== Problems === 
     
    171174 * Doesn't address the !EmailField length problem. (can be solved by schema migration tools?) 
    172175 * !ModelForm must be more restrictive, otherwise, django will suffer security issues, just as the register_globals of PHP or the mass-assignment of Rails. 
    173  * !ModelForm (and any other code that introspects auth.User) should be made lazy, or else circular dependencies can result. Introspecting auth.User and plugging into auth.User from the same app or an app loaded later is a potential circular dependency. 
     176 * !ModelForm (and any other code that introspects auth.User) should be made lazy, or else circular dependencies can result. Introspecting auth.User and plugging into auth.User from the same app or an app loaded later is a potential circular dependency. (This is not a problem, unless you put mixins in models.py?) 
    174177 
    175178== Solution 3: Leverage App Refactor ==