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<javascript:> > > wrote: > >> On Fri, 21 Sep 2012 17:54:06 -0400, Rohit Banga >> <iamroh...@gmail.com <javascript:>> 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 >> wlf...@ix.netcom.com <javascript:> >> 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<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/-/_Cn_whm6R50J. 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.
