Changes between Version 9 and Version 10 of ContribAuthImprovements


Ignore:
Timestamp:
03/23/2012 12:09:22 AM (3 years ago)
Author:
russellm
Comment:

Added some extra points based on discussions in IRC

Legend:

Unmodified
Added
Removed
Modified
  • ContribAuthImprovements

    v9 v10  
    101101 * Doesn't solve the analogous problem for any other project. E.g., contrib.comments already has pluggable Comments models, and has invented a bespoke solution. Other projects will have similar needs; this solution doesn't address the duplication of code.
    102102 * Has unpredictable failure modes if a third-party app assumes that User has a certain attribute or property which the project-provided User model doesn't support (or supports in a way different to the core auth.User model).
     103 * Prone to unpredictable problems if `AUTH_USER_MODEL` is modified after the initial syncdb (i.e., someone changes the settings to change the User model, but doesn't document/alert anyone that a migration will be required). This might be able to be managed by introducing a management table to the database to track the syncdb-time value for the AUTH_USER_MODEL setting, and raising a validation error if the current setting value doesn't match the value in the table.
    103104
    104105== Solution 2a: `USER_MODEL` setting ==
     
    133134 * Existing apps need to be updated to reflect the fact that auth.User may not be the User model. All instance of !ForeignKey(User) need to updated to !ForeignKey(settings.AUTH_USER). Failure modes will be unpredictable, as auth.User will still exist as a table, but won't contain any User information.
    134135 * Still has the settings-models circular dependency problem
     136 * As with Solution 2, prone to unpredictable problems if `USER_MODEL` is modified after the initial syncdb.
    135137
    136138== Solution 3: Leverage App Refactor ==
     
    160162
    161163 * Doesn't address the immediate problem for !EmailField. We could do the same User/!SimpleUser conversion here; with the added benefit that we are also introducing App Refactor, so we can use the distinction between an "unconfigured" auth app and a "Django 1.5 App Refactor Configured" auth app as the point for identifying whether User or !SimpleUser is in use.
     164
     165 * As with Solution 2, prone to unpredictable problems if the app configuration is modified after the initial syncdb.
    162166
    163167== Solution 3a: Transparent !LazyForeignKeys ==
Back to Top