Changes between Version 9 and Version 10 of ContribAuthImprovements

Timestamp:

Mar 23, 2012, 12:09:22 AM (13 years ago)

Author:

Russell Keith-Magee

Comment:

Added some extra points based on discussions in IRC

ContribAuthImprovements

@@ -101 +101 @@
  * 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.
  * 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). 
+ * 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.
 
 == Solution 2a: `USER_MODEL` setting ==
@@ -133 +134 @@
  * 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.
  * Still has the settings-models circular dependency problem
+ * As with Solution 2, prone to unpredictable problems if `USER_MODEL` is modified after the initial syncdb.
 
 == Solution 3: Leverage App Refactor ==
@@ -160 +162 @@
 
  * 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.
+
+ * As with Solution 2, prone to unpredictable problems if the app configuration is modified after the initial syncdb.
 
 == Solution 3a: Transparent !LazyForeignKeys ==