| 140 | == Solution 2b: `AUTH_USER_MODEL_MIXINS` setting == |
| 141 | |
| 142 | This is similar to solution 2 and 2a, but is quite the opposite to solution 3. |
| 143 | |
| 144 | Making every model pluggable. So that auth.User could be defined like this. |
| 145 | |
| 146 | {{{#!python |
| 147 | class User(models.Model): |
| 148 | __mixins__ = settings.AUTH_USER_MODEL_MIXINS |
| 149 | }}} |
| 150 | |
| 151 | === Implementation === |
| 152 | |
| 153 | * Change bases before creating user-defined Model class in !ModelBase. |
| 154 | {{{#!python |
| 155 | mixins = attrs.get('__mixins__', ()) |
| 156 | bases = load_available_model_mixins(mixins) + bases |
| 157 | }}} |
| 158 | * separate fields out as mixins like solution 2a |
| 159 | |
| 160 | === Advantages === |
| 161 | |
| 162 | * do not have unpredictable problems in solution 2/2a. |
| 163 | * Existing projects require no migration. the same as solution 2/2a. |
| 164 | * Unlike solution 2a, change is not required for existing apps. |
| 165 | * Unrelated and third-party apps can indicate that they depend on various orthogonal mixins. the same as solution 2. |
| 166 | |
| 167 | === Problems === |
| 168 | |
| 169 | * built-in schema migration tools is required. |
| 170 | * Doesn't address the !EmailField length problem. (can be solved by schema migration tools?) |
| 171 | * !ModelForm must be more restrictive, otherwise, django will suffer security issues, just as the register_globals of PHP or the mass-assignment of Rails. |
| 172 | |