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