Changes between Version 118 and Version 119 of RemovingTheMagic

Timestamp:

Apr 27, 2006, 12:50:42 PM (18 years ago)

Author:

Adrian Holovaty

Comment:

Cleaned up latest changes to page.

RemovingTheMagic

@@ -194 +194 @@
 === Auth_permissions case changes ===
 
-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:
+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:
 
 {{{
@@ -367 +367 @@
 || {{{permissions.get_list(package__label__exact='foo')}}}  || {{{Permission.objects.filter(package__exact='foo')}}}  ||
     
-=== Be sure to import your models ===
-
-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
+=== Model location changed ===
+
+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.
 
 === 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.
 
-(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)
-
 Also note that managers can't be accessed from instances: