Re: How to separate data having the same model but belonging to different users?

On Fri, 21 Sep 2012 17:54:06 -0400, Rohit Banga
<iamrohitbanga@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
wlfraed@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.