Changes between Version 13 and Version 14 of ContribAuthImprovements

Timestamp:

Mar 23, 2012, 10:08:54 PM (13 years ago)

Author:

bhuztez

Comment:

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

ContribAuthImprovements

@@ -51 +51 @@
  * Introduces a setting that immediately becomes deprecated (since it won't be needed once the migration cycle is complete)
  * Doesn't address the problem with any other usage of !EmailField having a max_length of 75.
- * 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.
+ * 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__}}})
+    {{{#!python
+        self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE
+    }}}
 
 == Solution 1a: Superminimal with forced migration ==
@@ -164 +167 @@
  * Existing projects require no migration. the same as solution 2/2a.
  * Unlike solution 2a, change is not required for existing apps. 
- * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. the same as solution 2.
+ * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. the same as solution 2a.
 
 === Problems ===
@@ -171 +174 @@
  * Doesn't address the !EmailField length problem. (can be solved by schema migration tools?)
  * !ModelForm must be more restrictive, otherwise, django will suffer security issues, just as the register_globals of PHP or the mass-assignment of Rails.
- * !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.
+ * !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?)
 
 == Solution 3: Leverage App Refactor ==