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.
Thanks Rohit Banga http://iamrohitbanga.com/ On Fri, Sep 21, 2012 at 4:55 PM, Nikolas Stevenson-Molnar < nik.mol...@consbio.org> wrote: > If I understand correctly, that's not the type of dynamic loading you > need. That statement can be the much simpler: > > >>> from mysite.departments.form import getDepartment > > Rather, if you need models (tables) mapped to users at runtime, you need > to load the *those* dynamically (normally you would define the model in > your code, which includes--either implicitly or explicitly--the table name). > > At the risk of sounding like a broken record: simpler is better, and > multiple, dynamically loaded models with the same schema is *not* simple > ;) > > _Nik > > > On 9/21/2012 1:43 PM, Rohit Banga wrote: > > Sure Nikolas I will reconsider your solution. > In case I go for model inheritance then can I use the following solution > to load the class dynamically? > > mod = __import__('mysite.departments', fromlist=[form.getDepartment()]) > > > klass = getattr(mod, 'form.getDepartment()') > > > Thanks > Rohit Banga > http://iamrohitbanga.com/ > > > On Fri, Sep 21, 2012 at 4:33 PM, Nikolas Stevenson-Molnar < > nik.mol...@consbio.org> wrote: > >> I would still argue that the best solution is to use a robust >> permissions model which would preclude this. Wherever there is code, you >> invariably have the potential for security flaws. The more complicated you >> make that code, the more chances for mistakes. On the other hand, simpler >> code with well-defined methods for data access (e.g., maybe you never use >> MyModel.objects, but rather have a custom function for filtering objects >> based on permissions constraints; then you only have to ensure security in >> one place) make for fewer mistakes and a code base which is easier to >> maintain. >> >> _Nik >> >> >> On 9/21/2012 12:26 PM, Rohit Banga wrote: >> >> >> I don't want to filter rows by "userid" since one place we forget the >> filter in the code and there is an unauthorized data access. >> >> >> -- >> 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. > > > -- > 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.
