Opened 18 years ago

Closed 18 years ago

Last modified 17 years ago

#890 closed defect (fixed)

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

Reported by: aaronsw Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: dev
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (6)

comment:1 by aaronsw, 18 years ago

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

comment:2 by Adrian Holovaty, 18 years ago

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().

comment:3 by rjwittams, 18 years ago

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.

comment:4 by anonymous, 18 years ago

Component: Admin interfaceDatabase wrapper
milestone: Version 0.92
Version: SVN

This bug can be closed with magic-removal drops.

comment:5 by Adrian Holovaty, 18 years ago

Resolution: fixed
Status: newclosed

Fixed in magic-removal.

comment:6 by Adrian Holovaty, 17 years ago

milestone: Version 0.92

Milestone Version 0.92 deleted

Note: See TracTickets for help on using tickets.
Back to Top