Changes between Version 118 and Version 119 of RemovingTheMagic
- Timestamp:
- Apr 27, 2006, 12:50:42 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RemovingTheMagic
v118 v119 194 194 === Auth_permissions case changes === 195 195 196 A change checked into the MR branch on [2745] changed the verbose_names of two modules, Groups and Users to be lowercased instead of uppercased ("users" instead of "Users"). This results in the ''syncdb'' function of manage.py to break due to the disparity in existing installations of the Magic Removal branch. In order to fix your auth_permissionstable, execute these SQL statements:196 Changeset [2745] changed the {{{verbose_name}}}s of two models in the {{{django.contrib.auth}}} app -- {{{Group}}} and {{{User}}} -- to be lowercased instead of uppercased ({{{"users"}}} instead of {{{"Users"}}}). This breaks the {{{syncdb}}} function of manage.py due to the disparity in existing installations of the magic-removal branch. To fix your {{{auth_permissions}}} table, execute these SQL statements: 197 197 198 198 {{{ … … 367 367 || {{{permissions.get_list(package__label__exact='foo')}}} || {{{Permission.objects.filter(package__exact='foo')}}} || 368 368 369 === Be sure to import your models===370 371 Django won't recursively import everything inside a "models" package in your app. In fact, "startapp" doesn't even create "models" as a package anymore! Now Django imports "yourapp.models", and uses whatever classes in there that are subclasses of {{{models.Model}}}. So if you want to keep using a package, you need to go in your {{{___init__.py}}} and do something like {{{from mymodelmodule import *}}}. -- LaloMartins 369 === Model location changed === 370 371 In previous Django versions, models lived in a {{{models/}}} subdirectory of your app package. Now, they should live in a file {{{models.py}}} directly within your app package. 372 372 373 373 === Changes to model syntax === … … 584 584 Note that related-object lookup uses the default manager of the related object, which means the API for accessing related objects is completely consistent with the API for accessing objects via a manager. 585 585 586 (This example, while probably representative of the way an existing model would look, introduces an unfortunate asymmetry into the m2m accessors. At least for new designs it would likely be better practice to use the name site_set rather than sites as in the above; then all the magic-removal m2m versions would have consistent obj.xxx_set.yyy names instead of the needlessly confusing mix seen here. I guess the inferred name is still a little bit of magic that m-r can't do away with. mjm)587 588 586 Also note that managers can't be accessed from instances: 589 587