New architecture does not seem to allow centralized django.contrib.auth

[bernardopires]

New architecture does not seem to allow centralized django.contrib.auth

[bernardopires]

Hi Ted,

even though the docs says auth is required on TENANT_APPS, I think it
should actually work without it. What error are you getting when running sync_schemas?

2013/5/1 Ted Chen [email protected]

It's been awhile since I inspected tenant_schemas. I've been using a
branch successfully in my SaaS. I wanted to check out the latest commit. In
doing so, however, the latest software seems to not work with my
requirements.

I require that django.contrib.auth exists in public, since I want
centralized authorization and billing (my stripe-based billing app needs to
join in with the auth_user table). However, it seems that the latest
tenant_schema code requires that auth also be placed in TENANT_APPS (in
addition to optionally in SHARED_APPS). Otherwise, I get a DB error when
doing sync_schemas. However, when I do that and successfully do a
sync_schemas, my users (for which there exists an auth table in public) are
not authorized to login into a tenant. I suppose I would need to somehow
synchronize the user in each tenant with auth_user in public. But that
would be too unwieldy.

I would like to use the latest commit, since with my current branch of
tenant_schemas (forked 9 months ago), whenever I do a syncdb, I need to
delete tables in public that should only be in each tenant. Your latest
commit seems to have a solution for that using sync_db.

Any thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43
.

Bernardo Pires Carneiro

[surfer26th]

Bernardo,
I am getting a DB error. I don't have a copy of the trace, unfortunately. I've gone back to the branch that I forked 9 months ago. Also, I reverted my code that included the settings, so I would need to add all that back to a separate branch in order to re-create.
I did not get the DB error when I added auth, contenttypes, and sites to tenant_apps. Also, note that I had to add 'sites' as well, even though that does not show up as a mandatory in your docs under tenant_apps.
Thanks for getting back to me! If you are serious about looking into this, then I can try creating a branch to re-create the problem when I have more time.
Ted

--- On Wed, 5/1/13, Bernardo Pires Carneiro [email protected] wrote:

From: Bernardo Pires Carneiro [email protected]
Subject: Re: [django-tenant-schemas] New architecture does not seem to allow centralized django.contrib.auth (#43)
To: "bcarneiro/django-tenant-schemas" [email protected]
Cc: "Ted Chen" [email protected]
Date: Wednesday, May 1, 2013, 1:24 PM

Hi Ted,

even though the docs says auth is required on TENANT_APPS, I think it

should actually work without it. What error are you getting when running `

sync_schemas`?

2013/5/1 Ted Chen [email protected]

It's been awhile since I inspected tenant_schemas. I've been using a

branch successfully in my SaaS. I wanted to check out the latest commit. In

doing so, however, the latest software seems to not work with my

requirements.

I require that django.contrib.auth exists in public, since I want

centralized authorization and billing (my stripe-based billing app needs to

join in with the auth_user table). However, it seems that the latest

tenant_schema code requires that auth also be placed in TENANT_APPS (in

addition to optionally in SHARED_APPS). Otherwise, I get a DB error when

doing sync_schemas. However, when I do that and successfully do a

sync_schemas, my users (for which there exists an auth table in public) are

not authorized to login into a tenant. I suppose I would need to somehow

synchronize the user in each tenant with auth_user in public. But that

would be too unwieldy.

I would like to use the latest commit, since with my current branch of

tenant_schemas (forked 9 months ago), whenever I do a syncdb, I need to

delete tables in public that should only be in each tenant. Your latest

commit seems to have a solution for that using sync_db.

Any thoughts?

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/43

.

Bernardo Pires Carneiro

—
Reply to this email directly or view it on GitHub.

[bernardopires]

Previously you did need auth, contenttypes and sites, but now you shouldn't
need it any longer because the tenant and public schemas are pretty much
completely independent now when being synced. Only TENANT_APPS get synced
to the tenants and only SHARED_APPS are synced to public. Was the issue you
were seeing with the DB using the latest django-tenant-schemas version? If
yes, I'd love if you could reproduce this error and we can work on it
together. I want this repo to be as flexible as possible!

2013/5/1 Ted Chen [email protected]

Bernardo,
I am getting a DB error. I don't have a copy of the trace, unfortunately.
I've gone back to the branch that I forked 9 months ago. Also, I reverted
my code that included the settings, so I would need to add all that back to
a separate branch in order to re-create.
I did not get the DB error when I added auth, contenttypes, and sites to
tenant_apps. Also, note that I had to add 'sites' as well, even though that
does not show up as a mandatory in your docs under tenant_apps.
Thanks for getting back to me! If you are serious about looking into this,
then I can try creating a branch to re-create the problem when I have more
time.
Ted

--- On Wed, 5/1/13, Bernardo Pires Carneiro [email protected]
wrote:

From: Bernardo Pires Carneiro [email protected]
Subject: Re: [django-tenant-schemas] New architecture does not seem to
allow centralized django.contrib.auth (#43)
To: "bcarneiro/django-tenant-schemas" <
[email protected]>
Cc: "Ted Chen" [email protected]
Date: Wednesday, May 1, 2013, 1:24 PM

Hi Ted,

even though the docs says auth is required on TENANT_APPS, I think it

should actually work without it. What error are you getting when running `

sync_schemas`?

2013/5/1 Ted Chen [email protected]

It's been awhile since I inspected tenant_schemas. I've been using a

branch successfully in my SaaS. I wanted to check out the latest commit.
In

doing so, however, the latest software seems to not work with my

requirements.

I require that django.contrib.auth exists in public, since I want

centralized authorization and billing (my stripe-based billing app needs
to

join in with the auth_user table). However, it seems that the latest

tenant_schema code requires that auth also be placed in TENANT_APPS (in

addition to optionally in SHARED_APPS). Otherwise, I get a DB error when

doing sync_schemas. However, when I do that and successfully do a

sync_schemas, my users (for which there exists an auth table in public)
are

not authorized to login into a tenant. I suppose I would need to somehow

synchronize the user in each tenant with auth_user in public. But that

would be too unwieldy.

I would like to use the latest commit, since with my current branch of

tenant_schemas (forked 9 months ago), whenever I do a syncdb, I need to

delete tables in public that should only be in each tenant. Your latest

commit seems to have a solution for that using sync_db.

Any thoughts?

—

Reply to this email directly or view it on GitHub<
https://github.com/bcarneiro/django-tenant-schemas/issues/43>

.

Bernardo Pires Carneiro

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-17305093
.

Bernardo Pires Carneiro

[surfer26th]

Bernardo,
I did use the latest commit. I will try to reproduce it. Probably not today though. By end of week. Thanks for your interest!
Ted

--- On Wed, 5/1/13, Bernardo Pires Carneiro [email protected] wrote:

From: Bernardo Pires Carneiro [email protected]
Subject: Re: [django-tenant-schemas] New architecture does not seem to allow centralized django.contrib.auth (#43)
To: "bcarneiro/django-tenant-schemas" [email protected]
Cc: "Ted Chen" [email protected]
Date: Wednesday, May 1, 2013, 1:45 PM

Previously you did need auth, contenttypes and sites, but now you shouldn't

need it any longer because the tenant and public schemas are pretty much

completely independent now when being synced. Only TENANT_APPS get synced

to the tenants and only SHARED_APPS are synced to public. Was the issue you

were seeing with the DB using the latest django-tenant-schemas version? If

yes, I'd love if you could reproduce this error and we can work on it

together. I want this repo to be as flexible as possible!

2013/5/1 Ted Chen [email protected]

Bernardo,

I am getting a DB error. I don't have a copy of the trace, unfortunately.

I've gone back to the branch that I forked 9 months ago. Also, I reverted

my code that included the settings, so I would need to add all that back to

a separate branch in order to re-create.

I did not get the DB error when I added auth, contenttypes, and sites to

tenant_apps. Also, note that I had to add 'sites' as well, even though that

does not show up as a mandatory in your docs under tenant_apps.

Thanks for getting back to me! If you are serious about looking into this,

then I can try creating a branch to re-create the problem when I have more

time.

Ted

--- On Wed, 5/1/13, Bernardo Pires Carneiro [email protected]

wrote:

From: Bernardo Pires Carneiro [email protected]

Subject: Re: [django-tenant-schemas] New architecture does not seem to

allow centralized django.contrib.auth (#43)

To: "bcarneiro/django-tenant-schemas" <

[email protected]>

Cc: "Ted Chen" [email protected]

Date: Wednesday, May 1, 2013, 1:24 PM

Hi Ted,

even though the docs says auth is required on TENANT_APPS, I think it

should actually work without it. What error are you getting when running `

sync_schemas`?

2013/5/1 Ted Chen [email protected]

It's been awhile since I inspected tenant_schemas. I've been using a

branch successfully in my SaaS. I wanted to check out the latest commit.

In

doing so, however, the latest software seems to not work with my

requirements.

I require that django.contrib.auth exists in public, since I want

centralized authorization and billing (my stripe-based billing app needs

to

join in with the auth_user table). However, it seems that the latest

tenant_schema code requires that auth also be placed in TENANT_APPS (in

addition to optionally in SHARED_APPS). Otherwise, I get a DB error when

doing sync_schemas. However, when I do that and successfully do a

sync_schemas, my users (for which there exists an auth table in public)

are

not authorized to login into a tenant. I suppose I would need to somehow

synchronize the user in each tenant with auth_user in public. But that

would be too unwieldy.

I would like to use the latest commit, since with my current branch of

tenant_schemas (forked 9 months ago), whenever I do a syncdb, I need to

delete tables in public that should only be in each tenant. Your latest

commit seems to have a solution for that using sync_db.

Any thoughts?

—

Reply to this email directly or view it on GitHub<

https://github.com/bcarneiro/django-tenant-schemas/issues/43>

.

Bernardo Pires Carneiro

—

Reply to this email directly or view it on GitHub.

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-17305093

.

Bernardo Pires Carneiro

—
Reply to this email directly or view it on GitHub.

[bernardopires]

Hey Ted,

did you get everything working?

Bernardo

[surfer26th]

Bernardo,

Thanks for getting back to me. I did a pip install of django-tenant-schemas last week. Initially, I thought everything was fine. However, I encountered errors doing a manage.py sync_schemas and upoon the creation of a new schema (using the tenantmixin).

In settings.py, I included contenttypes and auth in 'SHARED_APPS' only. I have copied the traces for the sync_schema and database error (when I tried creating a new schema) below. Apparently, the new schema was successfully created, but I encountered a database error. The sync_schema error suggests to me that there is a problem if contenttypes is in SHARED_APPS (and not in TENANT_APPS). Also, I speculate that the database error that I encountered is related,

Would appreciate your view!

Regards,

Ted

sync_schemas error trace:

Bernardo,

There could be an issue. I ran a python manage.py sync_schemas and I ran into this problem. It seemed to do a sync with my public schema but ran into a problem when sync'ing in my tenant, which I named "demo". Here's the trace. Could it be that you still require django_content_type in your tenant_apps? I placed it only in my shared_apps:

(v_productcentral)ted@productcentralhost:~/productcentral$ python manage.py sync_schemas
=== Running syncdb for schema public
Creating tables ...
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
=== Running syncdb for schema demo
Creating tables ...
Traceback (most recent call last):
File "manage.py", line 10, in
execute_from_command_line(sys.argv)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/init.py", line 443, in execute_from_command_line
utility.execute()
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/init.py", line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
self.execute(_args, *_options.dict)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
output = self.handle(_args, *_options)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle
return self.handle_noargs(**options)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/tenant_schemas/management/commands/sync_schemas.py", line 60, in handle_noargs
self.sync_tenant_apps(schema_name)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/tenant_schemas/management/commands/sync_schemas.py", line 98, in sync_tenant_apps
syncdb_command.execute(**self.options)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
output = self.handle(_args, *_options)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/base.py", line 371, in handle
return self.handle_noargs(**options)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 110, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/management/sql.py", line 189, in emit_post_sync_signal
interactive=interactive, db=db)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send
response = receiver(signal=self, sender=sender, **named)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 35, in create_permissions
ctype = ContentType.objects.get_for_model(klass)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/contrib/contenttypes/models.py", line 42, in get_for_model
defaults = {'name': smart_unicode(opts.verbose_name_raw)},
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/manager.py", line 134, in get_or_create
return self.get_query_set().get_or_create(**kwargs)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/query.py", line 445, in get_or_create
return self.get(**lookup), False
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/query.py", line 361, in get
num = len(clone)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/query.py", line 85, in len
self._result_cache = list(self.iterator())
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/query.py", line 291, in iterator
for row in compiler.results_iter():
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 763, in results_iter
for rows in self.execute_sql(MULTI):
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 818, in execute_sql
cursor.execute(sql, params)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/backends/util.py", line 40, in execute
return self.cursor.execute(sql, params)
File "/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 52, in execute
return self.cursor.execute(query, args)
django.db.utils.DatabaseError: relation "django_content_type" does not exist
LINE 1: ..."."app_label", "django_content_type"."model" FROM "django_co...

Database error trace is here:

DatabaseError at /createtenant_verify/
current transaction is aborted, commands ignored until end of transaction block
Request Method: POST
Request URL: http://demandanalytix.com/createtenant_verify/
Django Version: 1.4.5
Exception Type: DatabaseError
Exception Value:
current transaction is aborted, commands ignored until end of transaction block
Exception Location: /home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/tenant_schemas/postgresql_backend/base.py in set_search_path, line 57
Python Executable: /home/ted/.virtualenvs/v_productcentral/bin/python
Python Version: 2.7.3
Python Path:
['/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/requests/packages',
'/home/ted/productcentral',
'/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg',
'/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg',
'/home/ted/.virtualenvs/v_productcentral/lib/python2.7',
'/home/ted/.virtualenvs/v_productcentral/lib/python2.7/plat-linux2',
'/home/ted/.virtualenvs/v_productcentral/lib/python2.7/lib-tk',
'/home/ted/.virtualenvs/v_productcentral/lib/python2.7/lib-old',
'/home/ted/.virtualenvs/v_productcentral/lib/python2.7/lib-dynload',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages']
Server time: Thu, 30 May 2013 12:52:01 -0700
Traceback Switch to copy-and-paste view

/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/core/handlers/base.py
in
get_response
response = middleware_method(request, response) ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/contrib/sessions/middleware.py
in
process_response
request.session.save() ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/contrib/sessions/backends/db.py
in
save
sid = transaction.savepoint(using=using) ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/transaction.py
in
savepoint
return connection.savepoint() ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/backends/init.py
in
savepoint
self._savepoint(sid) ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/backends/init.py
in
_savepoint
self.cursor().execute(self.ops.savepoint_create_sql(sid)) ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/django/db/backends/init.py
in
cursor
cursor = self.make_debug_cursor(self._cursor()) ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/tenant_schemas/postgresql_backend/base.py
in
_cursor
cursor = self.pg_thread.set_search_path(cursor) ...
▶ Local vars
/home/ted/.virtualenvs/v_productcentral/local/lib/python2.7/site-packages/tenant_schemas/postgresql_backend/base.py
in
set_search_path
raise utils.DatabaseError(e.message) ...

[bernardopires]

Hi Ted,

many thanks for the report and the traces! I have encountered this error before and you are completely right. Because content_types is listed on INSTALLED_APPS, django thinks it's available everywhere, however it's not actually installed in the tenants. So content_types has to be installed on the tenants too, else it will not work.

Bernardo

[vmaatta]

I ran into the same issue with "auth_user". I.e. "DatabaseError: relation "auth_user" does not exist" when django.contrib.auth was only in SHARED_APPS as per the latest Documentation. I got past that by adding auth to TENANT_APPS. And then the same error was reported for "django_site". So in the end I had to add the following to tenant apps in addition to the actual tenant app:

'django.contrib.contenttypes',
'django.contrib.auth',
'django.contrib.sites',

Might be that I have to add more apps to TENANT_APPS at some point but for now I got sync_schemas to go through with these.

[guillempuey]

I'm facing the same problem, but in my case I only need to add the django.contrib.auth to the TENANT_APPS. Why does it happen? If I do that I'll have 2 user tables (one public and one per tenant), how is the authentication managed? which table does the work?

[guillempuey]

Hi Bernardo,

My purpose is creating a multitenant application able to serve several companies. I've been reading a lot of documentation and for me, the best approach is using multi-schemas, that's what make me arrive to your framework.
The requirements that I need is to have centralized authentication (django.contrib.auth) in order to have a central login page where after the user has correctly loged in, it will be redirected to the correct subdomain / schema.
Each company will manage its own users but I want them to be stored in the public schema, because I need to access also remotely using Web services to a centralized and fixed URL.
In addition to that, I've to extend the User Model to add additional information. So in my public tenant I want to have:

• Company
• User (django.contrib.auth)
• Agent (extension of User 1:1)

In my tenant schemas I need to have some models with ForeigKey to Agent Model, which must be in the public schema. First of all, is it possible to have relations between public and tenant specific schemas?

At the moment I'm not able to get that working, I have the following content in INSTALLED_APPS:

SHARED_APPS = (
'tenant_schemas', # mandatory
'myApp.common', # you must list the app where your tenant model resides in

'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.staticfiles',
'tastypie', -> will use it for web services

)

TENANT_APPS = (
# The following Django contrib apps must be in TENANT_APPS
'django.contrib.contenttypes',
'myApp.frontend',
#'myApp.webservice',
)

INSTALLED_APPS = SHARED_APPS + TENANT_APPS

The second question that I have is which is the best way to create the public Tenant. As far as it is mandatory prior to acces to any url, i'd like to create it automatically the first time that I run the server. Which is the best place to do that?

Everything runs ok with the public schema, but when I create a new Company (tenant model) the syncronization of the new schema works (it creates all the tables) but django fails with the following stack trace: http://dpaste.com/1225585/

So it seems that need the auth application also in TENANT_APPS, but why?

Please @bcarneiro can you help me with that?

[bernardopires]

Hello all,

I will look into this issue as soon as I have the time.
Barnalite, from a postgresql point of view this is possible, to reference
one schema from another, but this can not be done with this app. I'd
recommend you to look at another app.

Bernardo
Am 10.06.2013 13:26 schrieb "Barnalite" [email protected]:

Hi Bernardo,

My purpose is creating a multitenant application able to serve several
companies. I've been reading a lot of documentation and for me, the best
approach is using multi-schemas, that's what make me arrive to your
framework.
The requirements that I need is to have centralized authentication
(django.contrib.auth) in order to have a central login page where after the
user has correctly loged in, it will be redirected to the correct subdomain
/ schema.
Each company will manage its own users but I want them to be stored in the
public schema, because I need to access also remotely using Web services to
a centralized and fixed URL.
In addition to that, I've to extend the User Model to add additional
information. So in my public tenant I want to have:

• Company
• User (django.contrib.auth)
• Agent (extension of User 1:1)

In my tenant schemas I need to have some models with ForeigKey to Agent
Model, which must be in the public schema. First of all, is it possible to
have relations between public and tenant specific schemas?

At the moment I'm not able to get that working, I have the following
content in INSTALLED_APPS:

SHARED_APPS = (
'tenant_schemas', # mandatory
'myApp.common', # you must list the app where your tenant model resides in

'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.staticfiles',
'tastypie', -> will use it for web services

)

TENANT_APPS = (

The following Django contrib apps must be in TENANT_APPS

'django.contrib.contenttypes',
'myApp.frontend',
#'myApp.webservice',
)

INSTALLED_APPS = SHARED_APPS + TENANT_APPS

The second question that I have is which is the best way to create the
public Tenant. As far as it is mandatory prior to acces to any url, i'd
like to create it automatically the first time that I run the server. Which
is the best place to do that?

Everything runs ok with the public schema, but when I create a new Company
(tenant model) the syncronization of the new schema works (it creates all
the tables) but django fails with the following stack trace:
http://dpaste.com/1225585/

So it seems that need the auth application also in TENANT_APPS, but why?

Please @bcarneiro https://github.com/bcarneiro can you help me with
that?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-19193168
.

[kissgyorgy]

I think this is happening because if you put auth into SHARED_APPS only and sync a schema the first time, couple of apps try to make a foreign key referencing auth_user, which is only in the public schema, but the search path is set to the given schema only so the referenced table is not accesible.
For example django_admin_log table has a foreign key to auth_user, so if you put auth in SHARED_APPS only and admin in TENANT_APPS only, sync_schemas wont able to create django_admin_log table because auth_user need to be in the same schema or in the search_path.

One quick and hacky "solution" is to put auth into both SHARED_APPS and TENANT_APPS and ALTER TABLE so primary keys point to public schema instead of the current schema, and DELETE auth_user from that schema after the sync.

Another way to explicitly modify the SQL queries FOREIGN KEYS during sync for app models that have FOREIGN KEYS to SHARED_APPS models to point to public schema.
I can't do this because I'm a a Django newbie, but if somebody can help me or point me to the right direction, I would make the patch! Basically I don't even know how to modify the generated SQL queries what Django ORM generates.

[bernardopires]

I just reproduced this issue by simply following the tutorial (only
content_types on SHARED_APPS). Walkman, you got very near the source of
the problem. What you describe is not accurate because syncing apps, only
one schema is visible, so there is no attempt to reference auth_user on
another schema. What happens is that because you have auth on
SHARED_APPS, this means it is also on INSTALLED_APPS. Django seems to
make some automatic queries relying on auth_permission if you have auth
on INSTALLED_APPS. I think because you have installed auth, everytime
after syncing a new model, it tries to add the permissions associated with
that model. But on the tenant's domain, there is no permissions table and
therefore the query fails.

There may be a way to override the signal/events to stop this behavior, but
I don't have the time to look into this right now. Feel free to bastle
around.

2013/8/14 Walkman [email protected]

I think this is happening because if you put auth into SHARED_APPS only
and sync a schema the first time, couple of apps try to make a foreign key
referencing auth_user, which is only in the public schema, but the search
path is set to the given schema only so the referenced table is not
accesible.
For example django_admin_log table has a foreign key to auth_user, so if
you put auth in SHARED_APPS only and admin in TENANT_APPS only,
sync_schemas wont able to create django_admin_log table because auth_userneed to be in the same schema or in the search_path.

One quick and hacky "solution" is to put auth into both SHARED_APPS and
TENANT_APPS and ALTER TABLE so primary keys point to public schema instead
of the current schema, and DELETE auth_user from that schema after the
sync.

Another way to explicitly modify the SQL queries FOREIGN KEYS during sync
for app models that have FOREIGN KEYS to SHARED_APPS models to point to
public schema.
I can't do this because I'm a a Django newbie, but if somebody can help me
or point me to the right direction, I would make the patch! Basically I
don't even know how to modify the generated SQL queries what Django ORM
generates.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-22631360
.

Bernardo Pires Carneiro

[kissgyorgy]

I think we are talking about the same thing, I just wasn't clear enough so please clarify this, because I think I'm ready with the solution, just need to make sure it's right 😄

So, let's suppose auth is only in SHARED_APPS and tables are synced to public schema already. admin is only in TENANT_APPS.
On tenant sync, queries are restricted to the given schema (which is created), yes.
The syncdb command makes a list of queries based on INSTALLED_APPS and thinks that auth is in the current schema, because it's not schema-aware, so for example it tries to reference auth_user from django_admin_log table like this:

CREATE TABLE "django_admin_log" (
    "id" serial NOT NULL PRIMARY KEY,
    "action_time" timestamp with time zone NOT NULL,
    "user_id" integer NOT NULL REFERENCES "auth_user" ("id") DEFERRABLE INITIALLY DEFERRED,
    "content_type_id" integer REFERENCES "django_content_type" ("id") DEFERRABLE INITIALLY DEFERRED,
    "object_id" text,
    "object_repr" varchar(200) NOT NULL,
    "action_flag" smallint CHECK ("action_flag" >= 0) NOT NULL,
    "change_message" text NOT NULL
)
;

but because auth_user is not in the current schema (only public), PostgreSQL won't reference it, and the query will fail. That's what I meant by

django_admin_log table has a foreign key to auth_user

So one possible solution is to modify the query, and make an explicit reference to the "public"."auth_user" table, or any table reference which model's is in SHARED_APPS, right?
Please confirm we are on the same boat 😄 and I can send the pull request soon.

[fuhrysteve]

I keep running into this problem of not being able to write to the admin log (and other similar situations) as well. It seems to happen when I get my application in an odd state. I often find myself dropping tables and re-syncing them in the earlier stages of development (rather than doing migrations all the time, since they can get tricky). I've found that it's usually because I do the sync / south stuff in the wrong order.

At any rate, thus far I've found the django admin stuff to be the most tricky part of getting this module working, so glad to see this part of the application get some attention.

[bernardopires]

@walkman, I'm not sure if manually patching the query is the best way to solve this. I think one of the cool things we do on this app is not having to edit any query, we simply set the search_path before running all queries. Would your solution also work if there's another default django app that causes the same problem as admin (without having to write new code specifically for that app)?

One soluton might be to patch INSTALLED_APPS before calling sync_schemas. When calling the sync commands, it will only sync the proper apps and this way it will not think admin is installed and everything will work. This could potentially also make the sync_schemas and migrate_schemas code a lot simpler, but I don't know what side effects this might have when patching INSTALLED_APPS dynamically on a production environment.

Just to make it clear, what exactly are you trying to achieve here? Just that it works with these settings or to allow TENANT_APPS to reference tables on SHARED_APPS? The latter might only be possible by manually patching the queries as you did.

[kissgyorgy]

If you put an app to SHARED_APPS, it means you want every other application to interact with it, use it's data, reference it's tables, etc.
If you manually remove shared apps from INSTALLED_APPS before tenant_sync, no reference to that app's tables will created at all. I don't think the SHARED_APPS setting should work this way.
My solution works with every app automatically. It detects shared apps, and forces reference during sync only. After sync, nothing is modified and works everything nicely.

[bernardopires]

Ok, so what you want to do is to allow a tenant app to reference a shared
app.

What does your code do when I have auth and admin both on public and on
tenant? What if I have an app on tenant and want it to reference auth,
how do I choose what is being referenced?

Personally I think a better solution would be to have a special foreign
key, say, ForeignKeyToPublic which then generates the proper queries,
would this be possible? Would you be happy with this solution? I think this
is also more intuitive for the user, he knows what is happening.

What do you guys think?

If you put an app to SHARED_APPS, it means you want every other application
to interact with it, use it's data, reference it's tables, etc.
If you manually remove shared apps from INSTALLED_APPS before tenant_sync,
no reference to that app's tables will created at all. I don't think the
SHARED_APPS setting should work this way.
My solution works with every app automatically. It detects shared apps, and
forces reference during sync only. After sync, nothing is modified and
works everything nicely.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/43#issuecomment-24813777
.

[kissgyorgy]

What does your code do when I have auth and admin both on public and on
tenant?

You are right, I didn't think about this case, but the logically expected behavior is to reference tables in the schema, not on public, right? It's easy to do either.

Personally I think a better solution would be to have a special foreign key, say, ForeignKeyToPublic which then generates the proper queries, would this be possible?

We should approach this topic consistently, I mean if the default way with this app to make things public or tenant by SETTINGS, we should stick to it. (Other approach could be setting these properties in models Meta class, but that would require modification of models. Current approach is better in my opinion.) So I suggest a solution with settings also, specifically SHARED_MODELS. It's also a tuple, containing exact models in the same appname.Model form. These will be synced and referenced to public schema only. (I already implemented this.)
So for example if you put django.contrib.auth into TENANT_APPS and SHARED_APPS, the default behavior would be to not reference public from schema, but if you put let's say auth.User into SHARED_MODELS, every reference to auth_user table would be forced to "public"."auth_user".

SHARED_MODELS could be FORCED_PUBLIC_MODELS or FORCED_PUBLIC_APPS, whatever you suggest or we agree on if you like this idea.

If you put an app to SHARED_APPS, it means you want every other application to interact with it, use it's data, reference it's tables, etc.

Actually, PUBLIC_SCHEMA_URLCONF messes things up quite a bit, because if a user put something into SHARED_APPS how do you know what he want to achieve? Actually I was thinking about this lately and I open a new issue for this because this is a huge topic too.

[bernardopires]

Yes, the default should be referencing tables on the tenant, not on public.

Personally I'm not a big fan of adding another settings dicitonary to specify which models should be referenced on public. This is the purpose of your SHARED_MODELS, correct?

Wouldn't a ForeignKeyToPublic work?

[kissgyorgy]

Personally I'm not a big fan of adding another settings dicitonary to specify which models should be referenced on public. This is the purpose of your SHARED_MODELS, correct?

Yes, but one-by-one. So you can put an app into TENANT_APPS, but only one model from that app into the public schema.
I use it to have a shared user table, so every user can register only once and use his account on every tenant model (checking if a user belong to that tenant, but changing tenants or belonging to more than one tenant is possible with this method), but I need different permissions and groups for every tenant!

Wouldn't a ForeignKeyToPublic work?

If I understand correctly, it should be specified in the Model, but I thought the whole point of this app is that Django Models are not aware that they are using a multi-schema database, and no modification needed for any app. So if we would make a new field ForeignKeyToPublic,

• apps written with ForeignKeyToPublic would only work with this app, they would not be generic Django apps.
• it would be a mix and match of methods. Why not every model has an option (in Meta) to specify which schema it should be synced to and leave INSTALLED_APPS as it is?

That's why I think a setting would be better.

[bernardopires]

I might have found a solution to make SHARED_APPS and TENANT_APPS truly independent, allowing centralized auth to be possible. It patches django's AppCache and INSTALLED_APPS. I'll write in the django's devs list to check if this could be dangerous.

[bernardopires]

Hey @surfer26th @vmaatta @Barnalite and others interested,

I've just pushed a new branch called experimental-appcache. I did get centralized auth working with it, migrate_schemas also works. If you can, please try it and see if it works for you guys. Thanks a lot in advance!

[vmaatta]

I'm afraid I'm not using tenant-schemas in anything right now so I can't be
of much help.

Ville

On 2 Nov 2013, at 15:02, Bernardo Pires [email protected] wrote:

Hey guys @surfer26th https://github.com/surfer26th
@vmaattahttps://github.com/vmaatta
@Barnalite https://github.com/Barnalite ,

I've just pushed a new branch called experimental-appcache. I did get
centralized auth working with it, migrate_schemas also works. If you can,
please try it and see if it works for you guys. Thanks a lot in advance!

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/43#issuecomment-27621526
.

[bernardopires]

I've found another solution for this problem, this time using a database router. The branch is called experimental-db-router. I also got centralized auth working with it. It requires a new setting

DATABASE_ROUTERS = (
    'tenant_schemas.routers.TenantSyncRouter',
)

This is a much better solution than manually patching AppCache, which could have nasty side effects. Using a database router is harmless.

[kissgyorgy]

Man, db-router is freaking awesome compared to my solution! I was able to customize it for my needs in a matter of minutes! I will use it and report any issues.

[kissgyorgy]

I played with Django database routers quite a bit and finished my shared_models feature. Here are my thoughts:
database routers would be nice, but it's impossible to make public only one model, but leave the rest in tenant schemas, because the router's allow_syncdb method only decide if the table for a model should be created or not. It's not possible that the table is not created, but a ForeignKey to public created. If someone doesn't need this feature, it would be nice, because it's simple.
Also here is this South ticket and [this StackOverflow answer](which tells South is not very good with database routers) however I didn't played with that myself.

However my implementation in shared-models-v1 modify the SQL statements which happens on syncdb and migrate, so it's now that scenario is very well possible. No relations, indexes will be left out, still every single Model can be picked to sync into public schema!
However the routers idea is nice, and I didn't know about them before.

I think it's very common scenario that someone want a centralized User table, but want different Groups, even Permissions for every tenant, that's why I think shared_models is an essential feature.

[bernardopires]

Just a quick question walkman, how are the permissions for the users going
to work? Are only the permissions for shared apps going to be synced? Or is
the table permissions still created on the tenants?

[kissgyorgy]

Anything can be created anywhere, you specify it with the settings. For example: User go into public only, but Groups and Permissions synced to every tenant. Those tables will reference the public schema auth_user table (with ForeignKey relationships), so Groups and Permissions will be unique to every, but every tenant will see the same users! The modified postgresql backend takes care of every Table, ForeignKey and Index creation. It's pretty complicated but works really well. I'm already writing unit tests!

[bernardopires]

Sounds awesome, I'll try it as soon as I can. :)

2013/11/21 Kiss György [email protected]

Anything can be created anywhere, you specify it with the settings. For
example: User go into public only, but Groups and Permissions synced to
every tenant. Those tables will reference the public schema auth_usertable (with ForeignKey relationships), so Groups and Permissions will be
unique to every, but every tenant will see the same users! The modified
postgresql backend takes care of every Table, ForeignKey and Index
creation. It's pretty complicated but works really well. I'm already
writing unit tests!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-28991575
.

Bernardo Pires Carneiro

[surfer26th]

I am sorry that I have not responded earlier. I've been very busy getting my second release out, which is a SaaS. Tenant Schemas is a hugely strategically important component of my platform. I cannot emphasize that enough.

My Tenant Schema fork is something I scraped off of Bernardo's github page well over a year ago. My SaaS has been operating online for a few months, albeit with a few users. However, with my second release, I expect to get a lot more users. Because of MY need for centralized auth, I have had to stick with the old version of Tenant Schemas and I have not been able to get South working. With my expectation that I will continue to evolve my SaaS with a much larger number of users in 2014, I have a recurring nightmare that I will not be able to manage my site without getting database migrations (i.e. South) working. Therein lies my renewed interest in helping move this forward.

I thought that it would be important to portray my Use Case, since I think it is a common one for SaaS.

My need for Centralized User:
Users register in the Public schema. This is terribly important for me, since I use Stripe for centralized billing. BTW, I am taking advantage of Django Stripe Payments, which foreign key's into Users. I also want to access Users from one table for marketing purposes, and therefore, having Users in each of the tenant schemas (instead of in Public) is less than ideal for that. I have created (in Public) my own membership app for Tenants. The account creator automatically gains “sys admin” (NOT Django sys admin mind you) rights to invite other users and assigns their permissions. I do NOT allow any users access to Django Admin.

How have I managed up to now:
The old Dj Tenant Schemas initially had a connection to only the Tenant or to Public within postgresql_backend, but not to both. I changed that piece of the code to connect to both (like as it is in Django Schemata), so that the apps in Public could be seen from within each Tenant. (Since I forked that early piece of Tenant Schemas, I have noted that Tenant Schemas now also has adopted the shared connection scheme).

After I do the first syncdb (which populates Public with all models (tables)), I run a script that deletes the tables that were created in Public, but that are needed only in each Tenant. From that point on, whenever a Tenant is created (by a user),Tenant-create is invoked (using TenantMixin) and the tenant models (and ONLY the tenant-specific models) are created properly in the tenant. This seems to be working well. I have tried to get South working, but (using my old Tenant Schemas fork) could not get the South table installed in both Public and each tenant schema. So, up to now, I haven't been using South.

The good news is that I have proven that I can have centralized User administration and that my shared apps (in Public) are working fine in combination with my Tenant apps. I do NOT do a foreign-key from any of my tenant models to any model in Public, like Barnalite is trying to do.

My Contemplated Next Steps:
As I am about to release my version 2, this is a good time for me to try to converge back to the Tenant Schemas main branch. Over the next month, I will create a new development environment for my code and fork the latest Tenant Schemas. I will be attempting to do the following:

(1) in settings.py, place 'django.contrib.contenttypes', 'django.contrib.auth' into BOTH Shared Apps and Tenant Apps
(2) put South into both as well
(3) add code to a management command to automatically delete the django content type table and auth tables from the Tenant namespace after the Tenant is created

If this works with my App, and if South migration works, then this should provide me a solution that I will be able to live with.

---

Bernardo, Walkman –

Do either of you have any insights about the merits/dismerits of my plan? Also, would Walkman's "Shared Models" work for my Use Case, and should I be using that instead, even though I don't think I need all the capabilities that Shared_Models has to offer?

I sincerely appreciate all the hard work on this strategically important code.

Ted

---

[Also, BTW my app uses Celery for async tasks, and I have proven that Celery workers spawned from a tenant app can work. I do this by setting the connection at the top of the Task and closing the connection at the bottom

at the top of a task.py, I do this:

tenant = get_object_or_404(Tenant, schema_name = schema_name)    
connection.set_tenant(tenant)    
 ….

at the bottom, I do this:

connection.close() ]

[surfer26th]

Bernardo,

I have re-read this thread multiple times, but just began to take a serious look at your experimental-db-router branch. For my needs, at least, it looks promising. I will play around with it. I am concerned about Walkman's last comment about South not working with his SHARED_MODELS.

Ted

[kissgyorgy]

If you don't need to share only one model from an app, the router approach is just perfect. And simple.

[surfer26th]

Walkman -- Thank you for your insight on the router approach.

I wanted to share with you my approach on permissions, since it may be applicable to you. In looking at the Use Case you are trying to do -- assigning permissions in Tenant and foreign Key to Users -- I do the same thing, I believe, but have all that in Public Apps. Let me be more specific: I have created a Membership model (in Public Apps) that foreign key's to the Tenant model and also to User (both of which are also in Public). Membership model designates which users are assigned to which Tenant. The account creator for each Tenant is the de facto admin for the Tenant, and is the person who invites members to his/her Tenant (schema) and assigns permissions. Permissions is a field within the Membership model.

In contrast, the apps and models that I have placed in Tenant_apps are the ones that contain absolutely proprietary user data (that the user uploads from their ERP systems) and that absolutely must be "protected" and isolated from those of other Tenants. Also, by placing those models in each Tenant, it greatly improves the manageability of things for me and reduces the risk of a really bad thing happening to the data. I cannot imagine needing to manage humongous tables consisting of every Tenants' large chunks of proprietary data and the fragmentation problems that would invariably occur and all the management challenges and nightmares. This is where the technology strategy of using Postgresql schemas and Django Tenant-Schema plays such an important role.

Ted

[surfer26th]

Bernardo --

I have been playing around with the experimental_db_router branch for my SaaS on my development machine. That's my code that requires centralized auth, as described above.

Everything seems to be operating well so far. I am able to place all these ONLY in SHARED_APPS: ('django.contrib.auth','django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages','django.contrib.staticfiles', 'django.contrib.admin')
along with my other SHARED_APPS. My TENANT_APPS consists of four applications (besides South) and 12 tables (models).

Also, I have successfully created the south_migrationhistory tables in both the 'Public' schema and in a Tenant schema (by adding South in SHARED_APPS and TENANT_APPS and by doing a manage.py sync_schemas).

Since I have existing tables in my SaaS in both Public as well as multiple Tenant schemas, and since I need to convert to South, I would like to add to the tenant_schemas management commands a command to Convert_to_South. I will create it (using the migrate_schemas command as a template) and will try it with my development system. If it appears to work, I will submit a pull request to add convert_to_south_schemas.py.

I still have more verification to do, in addition to creating and running the convert_to_south_schemas command. Hopefully, I will be able to report back status early this week.

[surfer26th]

Continued to work with the experimental_db_router branch on my development environment.

Good news: I was able to create a new Tenant on-the-fly (using TenantMixin) and using Django 1.5.5 (I can't use Django 1.6, since it creates errors with my software which I don't have time to sort out right now). Also, the south_migrationhistory table in my new Tenant was properly faked.

Another Good News: I created a command to Convert_to_South, as discussed above. It worked properly on my existing models within an existing Tenant! I will create a pull-request to add the command with a caution: I used as a template the migrate_schemas command, and to be honest, I don't have a clue about parts of the code.

Not So Good News (or warning for people): I initially tried to create a Tenant with my software using Django 1.4.5. But I encountered a database error (trace shown below). I tried modifying the tenant-schema commands to try to isolate the problem, but to no avail. The thing that worked was moving up to Django 1.5.5.
What was interesting was the following, despite this error: The Tenant was created, and so were ALL the tables, including south_migrationhistory. The transaction was aborted before schema_migration within def create_schema in class TenantMixin when the path was set to the schema. By the way, I attempted to create the Tenant by bypassing South, but encountered the same error. I then bracketed call_command('sync_schemas',... in TenantMixin with Try ./. Except pass and that got me into the schema_migration command, but encountered another same database error when path was set to public. So, the schema_migrationhistory was not filled in with the intended fake migrations. I even went so far to replace the code in Postgresql_backend with the new code that Walkman created (that removed PGThread). But the result was the same.

---

My trace is as follows:

DatabaseError at /createtenant_verify/
current transaction is aborted, commands ignored until end of transaction block
Request Method: POST
Request URL: http://localhost:8000/createtenant_verify/
Django Version: 1.4.5
Exception Type: DatabaseError
Exception Value:
current transaction is aborted, commands ignored until end of transaction block
Exception Location: /home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py in execute, line 52
Python Executable: /home/ted/Envs/v_dev/bin/python
Python Version: 2.7.3
Python Path:
['/home/ted/Envs/v_dev/sandbox',
'/home/ted/Envs/v_dev/lib/python2.7',
'/home/ted/Envs/v_dev/lib/python2.7/plat-linux2',
'/home/ted/Envs/v_dev/lib/python2.7/lib-tk',
'/home/ted/Envs/v_dev/lib/python2.7/lib-old',
'/home/ted/Envs/v_dev/lib/python2.7/lib-dynload',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/home/ted/Envs/v_dev/local/lib/python2.7/site-packages']
Server time: Wed, 4 Dec 2013 12:51:25 -0800
Traceback Switch to copy-and-paste view

/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/core/handlers/base.py in get_response
response = middleware_method(request, response)
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/contrib/sessions/middleware.py in process_response
request.session.save()
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/contrib/sessions/backends/db.py in save
sid = transaction.savepoint(using=using)
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/db/transaction.py in savepoint
return connection.savepoint()
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/db/backends/init.py in savepoint
self._savepoint(sid)
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/db/backends/init.py in _savepoint
self.cursor().execute(self.ops.savepoint_create_sql(sid))
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/debug_toolbar/utils/tracking/init.py in wrapped
return callback(original, _args, *_kwargs)
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/debug_toolbar/panels/sql.py in cursor
result = original(self)
...
▶ Local vars
/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/db/backends/init.py in cursor
cursor = self.make_debug_cursor(self._cursor())
...
▶ Local vars
/home/ted/Envs/v_dev/sandbox/ProductCentralMT/thirdparty/tenant_schemas/postgresql_backend/base.py in _cursor
cursor = self.pg_thread.set_search_path(cursor)
...
▶ Local vars
/home/ted/Envs/v_dev/sandbox/ProductCentralMT/thirdparty/tenant_schemas/postgresql_backend/base.py in set_search_path
cursor.execute('SET search_path = %s', [self.schema_name])
...
Variable Value
cursor
<django.db.backends.postgresql_psycopg2.base.CursorWrapper object at 0x7f9824e64090>
self
<ProductCentralMT.thirdparty.tenant_schemas.postgresql_backend.base.PGThread object at 0x7f9824948600>
public_schema_name
'public'

/home/ted/Envs/v_dev/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py in execute
return self.cursor.execute(query, args)
...
▼ Local vars
Variable Value
query
'SET search_path = %s'
self
<django.db.backends.postgresql_psycopg2.base.CursorWrapper object at 0x7f9824e64090>
args
[u'acdc']
e
InternalError('current transaction is aborted, commands ignored until end of transaction block\n',)

[quietlyconfident]

Reading the beginning of this issue/thread (which is still open) one gets the idea that centralized auth is not possible. But then reading the end it seemed that it was a work in progress; but the last post is almost a year ago.

What is the status at the moment?

[quietlyconfident]

Would allowing the user to change the search order of private vs public schemas help this problem at all? #205

[bernardopires]

This should now be possible thanks to the database router. I've added more tests ensuring this works. Foreign keys constraints however do not get created. Let me know how this goes for you guys!

[tpyo]

@bernardopires Thanks for this. The TenantSyncRouter probably needs allow_migrate(), I saw some warnings about this when migrating to 1.7.

From the 1.7 release notes:

The allow_syncdb method on database routers is now called allow_migrate, but still performs the same function. Routers with allow_syncdb methods will still work, but that method name is deprecated and you should change it as soon as possible (nothing more than renaming is required).

[bernardopires]

I guess we'll need to keep both because of 1.6, thanks for the heads up tpyo! Do you want to send a pull request that adds allow_migrate() performing exactly like allow_syncdb()?

[tpyo]

Happy to: #217

[surfer26th]

Bernardo - I forked your experimental branch (experimental db router) that you created in late 2013 ("fixed sync_schemas and migrate_schemas not taking arguments") and have been using it with Django 1.5.5 on my production server with success since. I have done quite a few migrations in development and in production successfully. As I am updating/upgrading my software, I hope to get back in sync with your master. Thank you for your continued work on this and specifically for closing this issue out!

Thanks to tpyo for the warning on Django 1.7 and migrations. I will not upgrade to Django 1.7, but hope to upgrade to 1.6.

[bernardopires]

Hi Ted @surfer26th, I'm now using the router in the master so you should have no problems upgrading! Let me know if you have any issues. Thanks for your continued suppport!