database tables should be imported directly, not thru django.models.[app_name].[table_name.lower()]s

[aaronsw]

If I define a database table in the foo module, I sort of expect it to be there for me to get it out again. Having it appear inside the django code with a different name is bizarre and confusing and annoying.

[Adrian Holovaty]

Yeah, I feel the same way. The question is how we keep a distinction between record-level methods (Poll.get_choice_list()) and table-level methods (polls.get_list(), polls.get_object()). The table-level methods shouldn't just be simple class methods, because a given object instance shouldn't be able to call get_list() or get_object().

[rjwittams]

Also the stuff in the django.models import hook has to be done somewhere else - when the first model is imported, all of them must be imported. This is not really easy, because by the time you know you are importing a model ( ie the meta.Model metaclass is run ), you are halfway through importing a module. You need to run the import hook when all modules have been imported. But you won't get told when the current module finishes being imported.

The only clean way I can see to do this is some kind of django.meta.init() call, which is called in the basehandler and does this stuff if it hasn't already been done, and anyone using the ORM outside of the handler needs to call that method too...

The unclean way is to treat the model modules being imported directly differently than modules being implicitly imported. IE when their metaclasses finish, go through and patch up anything needed. This would make startup O(mn) with m <- number of metaclasses directly imported and n <- number of metaclasses in total. Not good.

[anonymous]

This bug can be closed with magic-removal drops.

[Adrian Holovaty]

Fixed in magic-removal.

[Adrian Holovaty]

Milestone Version 0.92 deleted