I don't think so. The question actually had a different point, namely "When I put a decorator on my model, how do I keep the original name for the table?" It didn't specify what the decorator does. There is a link to a doc on proxy models, but it appears that they create multiple tables.
I should think that if you have a foreign key to the department in all tables that must be segregated by department, you could create a decorator that would apply a filter with the department key. But I don't know how to do it. On Saturday, September 22, 2012 11:23:16 PM UTC-4, Rohit Banga wrote: > > Thats interesting Bill. > Are you talking about something like this? > > http://stackoverflow.com/questions/3276700/django-model-subclass-without-changing-database-name > > Thanks > Rohit Banga > http://iamrohitbanga.com/ > > > On Sat, Sep 22, 2012 at 8:15 PM, Bill Beal <b.b...@eximflow.com<javascript:> > > wrote: > >> Question for an expert from a newbie: Could you decorate each model that >> has data that needs to be separated by departments? If so, you wouldn't >> have to remember to code the department filter on each retrieval. >> >> >> On Friday, September 21, 2012 10:06:35 PM UTC-4, Rohit Banga wrote: >> >>> Hi Dennis >>> Thanks for summarizing the contents of the mails. >>> Do you foresee any problems with the Model Inheritance scheme? At my end >>> I am stuck at getting a way to achieve dynamic polymorphism - which is >>> probably because I am new to Python. >>> >>> I can create a new subclass for every Department I add. manage.py >>> syncdb creates the new table for every new department I add. Now I want >>> to write the application logic agnostic of the specific department. I want >>> to load the appropriate subclass dynamically at runtime. I haven't been >>> able to do this right now. >>> I can afford to create a new subclass everytime and run manage.py syndb >>> after that but cannot rewrite all the application logic all over again. >>> >>> I feel given the subclass name there should be an easy way in python to >>> get the subclass itself which I should use for the current user. >>> >>> At this point I should also mention there are a set of about 5-6 tables >>> (department being just one example) that I need to replicate for each new >>> department. I am thinking of doing it all via subclassing. That is I would >>> need to load as many subclass objects dynamically given the name of the >>> department. >>> If I can get the set of subclasses to use with a not too ugly looking >>> code is it still a terrible idea? >>> >>> Thanks >>> Rohit Banga >>> http://iamrohitbanga.com/ >>> >>> >>> On Fri, Sep 21, 2012 at 9:34 PM, Dennis Lee Bieber <wlf...@ix.netcom.com >>> > wrote: >>> >>>> On Fri, 21 Sep 2012 17:54:06 -0400, Rohit Banga >>>> <iamroh...@gmail.com> declaimed the following in >>>> gmane.comp.python.django.user: >>>> >>>> > Thanks Nikolas. I think my example was not clear. >>>> > >>>> > But all the code is shared between the departments (another reason >>>> for you >>>> > to say use the same tables!). >>>> > I do not need to have the explicit department name in the code. I >>>> don't >>>> > know the name of the departments yet! (It is just a metaphor) >>>> > I just want to add behavior like PhysicsDepartment.objects.**filter() >>>> or >>>> > create(), save() anywhere I want. >>>> > I want to work with the base class while loading the data from the >>>> subclass >>>> > at runtime. Simple polymorphism but with different database tables in >>>> the >>>> > backend. >>>> > >>>> >>>> I expect that over 95% of the responses will all emphasize using >>>> single set of tables, and a filter by the department (which is retrieved >>>> from the log-in authorization information) >>>> >>>> Anything else means you have to somehow dynamically: >>>> >>>> 1) use one database for authorization and; somehow OPEN a >>>> department >>>> database connection that the models will hook into instead of using a >>>> "load-time" database. That probably means you have to replace the Django >>>> database connection system with one that you call at run-time. IOW, you >>>> do not have a database configured in the normal manner -- but EVERY >>>> Django function that issues an SQL operation would have to do something >>>> like: >>>> >>>> if not dbConnection: >>>> dbName = authuserdepartmentname >>>> dbConnection = whateverapi(database=dbName,..**.) >>>> >>>> where dbConnection is whatever Django normally uses to track the >>>> database connection. >>>> >>>> >>>> 2) not use Django models defined at build time (ie, in code), but >>>> dynamically build the models at run-time so that you can specify the >>>> table name when accessed (sort of using code templates into which you >>>> substitute the needed table names which are then imported later -- good >>>> luck getting Django to recognize the validity of the models). >>>> >>>> >>>> 3) operate separate "servers" for each department. Each server >>>> would >>>> have its own location for datafiles, but you can probably share the >>>> application code via soft-links or maybe even one shared code directory. >>>> This is workable for those databases that allow connections defined by >>>> file name/path (SQLite, embedded Firebird) but not for those using a >>>> dedicated database server (MySQL, PostgreSQL) -- because the file "name" >>>> will be fixed, but the data path would be relative to the "web server" >>>> URL. Of course, if you have many departments, you end up with many >>>> "servers" on different ports: >>>> >>>> http://server.localhost:8080/ Physics >>>> http://server.localhost:8081/ Mathematics >>>> >>>> or your server on port 80 rewrites URLs >>>> >>>> >>>> http://physics.server.**localhost/<http://physics.server.localhost/>=> >>>> server.localhost:8080 >>>> >>>> http://mathematics.server.**localhost/<http://mathematics.server.localhost/>=> >>>> server.localhost:8081 >>>> or >>>> >>>> http://physics.server.**localhost/<http://physics.server.localhost/>=> >>>> http://server.localhost/**physics <http://server.localhost/physics> >>>> >>>> where the directory structure is something like >>>> >>>> physics/ >>>> app1 -> softlink to common/app1 >>>> data/ >>>> sqlite.db >>>> >>>> mathematics/ >>>> app1 -> softlink to common/app1 >>>> data/ >>>> sqlite.db >>>> >>>> and the path to the database is relative >>>> >>>> ./data/sqlite.db >>>> >>>> >>>> Option 1 is probably easier to create, since the table names >>>> don't >>>> change -- only the "department" database name changes. Creating the >>>> database for each new department means over-riding the admin "sync" >>>> logic since the database name has to be provided rather than extracted >>>> from a configuration field. >>>> >>>> Options 1 and 2 require modifying core Django functionality -- >>>> don't >>>> expect to be able to update Django without recreating the changed core, >>>> and don't expect to be able to use a hosting service that provides >>>> Django as you won't be able to change it with your modifications. >>>> >>>> Option 3 restricts the type of database that can be used, and >>>> requires very heavy administration of the web server configuration, not >>>> just Django. >>>> >>>> >>>> In contrast, using ONE database with just one set of tables, in >>>> which all records have a foreign key to the authorization data (which >>>> provides the department associated with the login), and having all views >>>> filter the data by that department is the solution that is the most >>>> natural scheme to maintain, and can be done within a single Django >>>> application (I use "application" here to mean the collective set of >>>> models and views -- not some code that handles just one web page) >>>> -- >>>> Wulfraed Dennis Lee Bieber AF6VN >>>> wlf...@ix.netcom.com >>>> HTTP://wlfraed.home.netcom.**com/<HTTP://wlfraed.home.netcom.com/> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django users" group. >>>> To post to this group, send email to django...@googlegroups.com. >>>> To unsubscribe from this group, send email to django-users...@** >>>> googlegroups.com. >>>> >>>> For more options, visit this group at http://groups.google.com/** >>>> group/django-users?hl=en<http://groups.google.com/group/django-users?hl=en> >>>> . >>>> >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/django-users/-/_Cn_whm6R50J. >> >> To post to this group, send email to django...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> django-users...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/18TSY9wlGqoJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
