Changes between Version 118 and Version 119 of RemovingTheMagic


Ignore:
Timestamp:
Apr 27, 2006, 12:50:42 PM (19 years ago)
Author:
Adrian Holovaty
Comment:

Cleaned up latest changes to page.

Legend:

Unmodified
Added
Removed
Modified
  • RemovingTheMagic

    v118 v119  
    194194=== Auth_permissions case changes ===
    195195
    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_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 manage.py due to the disparity in existing installations of the magic-removal branch. To fix your {{{auth_permissions}}} table, execute these SQL statements:
    197197
    198198{{{
     
    367367|| {{{permissions.get_list(package__label__exact='foo')}}}  || {{{Permission.objects.filter(package__exact='foo')}}}  ||
    368368   
    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
     371In 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.
    372372
    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.
    585585
    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 
    588586Also note that managers can't be accessed from instances:
    589587
Back to Top