Changes between Version 118 and Version 119 of RemovingTheMagic

04/27/2006 12:50:42 PM (10 years ago)
Adrian Holovaty

Cleaned up latest changes to page.


  • RemovingTheMagic

    v118 v119  
    194194=== Auth_permissions case changes ===
    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 to break due to the disparity in existing installations of the Magic Removal branch.  In order to fix your auth_permissions table, execute these SQL statements:
     196Changeset [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 due to the disparity in existing installations of the magic-removal branch. To fix your {{{auth_permissions}}} table, execute these SQL statements:
    367367|| {{{permissions.get_list(package__label__exact='foo')}}}  || {{{Permission.objects.filter(package__exact='foo')}}}  ||
    369 === Be sure to import your models ===
    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 {{{}}} and do something like {{{from mymodelmodule import *}}}.  -- LaloMartins
     369=== Model location changed ===
     371In previous Django versions, models lived in a {{{models/}}} subdirectory of your app package. Now, they should live in a file {{{}}} directly within your app package.
    373373=== Changes to model syntax ===
    584584Note 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.
    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)
    588586Also note that managers can't be accessed from instances:
Back to Top