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 <wlfr...@ix.netcom.com>wrote: > On Fri, 21 Sep 2012 17:54:06 -0400, Rohit Banga > <iamrohitba...@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/ => server.localhost:8080 > http://mathematics.server.localhost/ => server.localhost:8081 > or > http://physics.server.localhost/ => > 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 > wlfr...@ix.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-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. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. 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.
