Add support for Shared Applications

[bernardopires]

An application is considered to be shared when it's table are in the public schema. Some apps make sense being shared. Suppose you have some sort of public data set, for example, a table containing census data. You want every tenant to be able to query it.

Right now, this is not possible, at least not in practical way. By default all models are being synced to every schema, including public. Please take a look at the tenant-schemas needs your help! section if you have an idea on how to do this.

django-appschema tries to solve this in a very hackish and dangerous way by altering django's app cache. This is not safe for on-the-fly creation of tenants, so this is not an option. django-schemata partially solves it by forcing you to move your shared tables to the public schema. When syncing the tables for tenant-specific applications, the search path is set to public plus the tenant's schema, which means all tables that already exist on public will not be created when syncing. This is not ideal because it doesn't allow you have to applications that are both shared and tenant-specific. For example, you may need to have a user system for your main domain and another for your tenants. Or you may want to have south in both.

To enable this, an idea would be to let all models, both shared and tenant-specific to be synced. After the sync, the unnecessary models can be deleted from the database. There would be three arrays, SHARED_APPS, TENANT_APPS and MUTUAL_APPS. For example, when syncing the public schema, we can just iterate over TENANT_APPS deleting their tables. When syncing tenants, we delete the SHARED_APPS tables. We can then enable the tenants to also see the public schema. This is of course not very elegant, but shouldn't present a big hit on performance (how often do you sync your models?) and doesn't involve hacking django's cache.

An ever simpler solution would be if it were possible to select which models have to be synced. AFAIK this is not possible, syncdb is called for all models on INSTALLED_APPS.

What do you think of this solution? Do you have a better idea? Please send in your feedback!

[lancespeelmon]

+1 this model sounds workable, thanks, L

[acmeguy]

Could the INSTALLED_APPS list be populated differently based on what syncdb mode (parameter) is running?

[bernardopires]

I'm not sure, but I think I did try that and the problem is that django
seems to cache INSTALLED_APPS internally. Changing it live could result in
some nasty errors if an user is using your website simultaneously.

2013/2/2 Stefán Baxter notifications@github.com

Could the INSTALLED_APPS list be populated differently based on what
syncdb mode (parameter) is running?

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

Bernardo Pires Carneiro

[acmeguy]

hmmm, can we try again? I am willing to look into the syncdb part if you are willing to look into the rest.

[bernardopires]

sure, let's try it mate!

2013/2/2 Stefán Baxter notifications@github.com

hmmm, can we try again? I am willing to look into the syncdb part if you
are willing to look into the rest.

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

Bernardo Pires Carneiro

[acmeguy]

I will create SHARED_APPS and TENANT_APPS which will produce different results in INSTALLED_APPS for syncdb based on a parameter reflected in settings.SYNCDB_MODE = 'public' or 'tenant' and will then include both when the parameter is missing. (I think that will at least get us started)

[bernardopires]

Perfect!

2013/2/2 Stefán Baxter notifications@github.com

I will create SHARED_APPS and TENANT_APPS which will produce different
results in INSTALLED_APPS for syncdb based on a parameter reflected in
settings.SYNCDB_MODE = 'public' or 'tenant' and will then include both when
the parameter is missing. (I think that will at least get us started)

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

Bernardo Pires Carneiro

[acmeguy]

Ok, I have it working (I think). I will create a fork in a little while (dinner) and create a pull request.

[acmeguy]

Ok, I did something as simple as wrapping the syncdb command with INSTALLED_APPS manipulation based on two settings (--tenant or --shared) and I have verified that it creates only the corresponding tables. Is that enough?
(I'm looking at the code and wondering if you had something else in mind)

[bernardopires]

Hi Stefán,

yes, that is exactly the way I had in mind! That's perfect! How did you get
it to only sync the necessary tables? I'm looking forward to your patch!

2013/2/2 Stefán Baxter notifications@github.com

Ok, I did something as simple as wrapping the syncdb command with
INSTALLED_APPS manipulation based on two settings (--tenant or --shared)
and I have verified that it creates only the corresponding tables. Is that
enough?
(I'm looking at the code and wondering if you had something else in mind)

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

Bernardo Pires Carneiro

[acmeguy]

Hi, it's there along with the pull request. You will need to change the way new tenant domains are initiated if this is to work properly.

[bernardopires]

Hi Stéfan, many thanks for the exciting patch!! I'll look onto it as soon
as I can. I'll probably have to tweak some small details for backwards
compatibility and update the documentation.

2013/2/3 Stefán Baxter notifications@github.com

Hi, it's there along with the pull request. You will need to change the
way new tenant domains are initiated if this is to work properly.

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

Bernardo Pires Carneiro

[acmeguy]

Hope it's soon. I'd really like to start using this :)

[bernardopires]

Stefan, I'd like your input on something. I think there may be a need for having models that are public-exclusive or that are both tenant-specific and at the public schema. For example, suppose I want to have south on the tenants and also on public. Should we treat this as having a model being both, tenant-specific and shared? That means it would be under SHARED_APPS and TENANT_APPS. It is a bit misleading because saying shared gives the impression the tenant is going to be able to use it. So we have the following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We should be able to achieve this via SHARED_APPS and TENANT_APPS and it should work perfectly right now because models are synced with only one schema at the search_path. So when syncing tenants it doesn't know what exists on public. But when at a normal view the search_path will be set to <tenant>, public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make sense? I can't think of an example.

[acmeguy]

Understand, this should be a simple addition.

[acmeguy]

Hi,

The way it works now is that SHARED_APPS are public-exclusive (shared) and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only created
in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so it's
visible for "public tables in the public scope" and then fro "tenant tables
only in the tenant scope"? (that would mean that the south tables are in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a need for
having models that are public-exclusive or that are both tenant-specific
and at the public schema. For example, suppose I want to have south on the
tenants and also on public. Should we treat this as having a model being
both, tenant-specific and shared? That means it would be under SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.

2. A model has to be shared, for example auth.

3. A model should exist in both worlds, for example south. We should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it should work
   perfectly right now because models are synced with only one schema at the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to ,
   public making the shared data visible.

4. A model is public-exclusive. Does this scenario even make sense? I
   can't think of an example.

   —
   Reply to this email directly or view it on GitHubhttps://github.com/Add support for Shared Applications #1#issuecomment-13090962.

[acmeguy]

Hi,

Ultimately this approach uses the ._meta.managed setting to affect which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting which is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a whole
different level.

Manipulating this setting is trivial* and it +connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive (shared) and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so it's
visible for "public tables in the public scope" and then fro "tenant tables
only in the tenant scope"? (that would mean that the south tables are in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a need for
having models that are public-exclusive or that are both tenant-specific
and at the public schema. For example, suppose I want to have south on the
tenants and also on public. Should we treat this as having a model being
both, tenant-specific and shared? That means it would be under SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.

2. A model has to be shared, for example auth.

3. A model should exist in both worlds, for example south. We should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it should work
   perfectly right now because models are synced with only one schema at the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to ,
   public making the shared data visible.

4. A model is public-exclusive. Does this scenario even make sense? I
   can't think of an example.

   —
   Reply to this email directly or view it on GitHubhttps://github.com/Add support for Shared Applications #1#issuecomment-13090962.

[bernardopires]

I ran your command setting the verbosity of syncdb to 3 and it seems like
somehow all installed_apps are still processed on the background, even
though the tables are not created. Is this how it's supposed to work?

2013/2/4 Stefán Baxter notifications@github.com

Hi,

Ultimately this approach uses the ._meta.managed setting to affect which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting which
is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a whole
different level.

Manipulating this setting is trivial* and it
+connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive (shared)
and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so it's
visible for "public tables in the public scope" and then fro "tenant
tables
only in the tenant scope"? (that would mean that the south tables are in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a need
for
having models that are public-exclusive or that are both
tenant-specific
and at the public schema. For example, suppose I want to have south on
the
tenants and also on public. Should we treat this as having a model
being
both, tenant-specific and shared? That means it would be under
SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it should
   work
   perfectly right now because models are synced with only one schema at
   the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to
   ,
   public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make sense? I
   can't think of an example.

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

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

Bernardo Pires Carneiro

[acmeguy]

Yes, all models are validated. The manage switch then stops it from
creating them in the wrong place. This is the desired way and the only way
to create valid relations between schemas
On 4 Feb 2013 19:17, "Bernardo Pires Carneiro" notifications@github.com
wrote:

I ran your command setting the verbosity of syncdb to 3 and it seems like
somehow all installed_apps are still processed on the background, even
though the tables are not created. Is this how it's supposed to work?

2013/2/4 Stefán Baxter notifications@github.com

Hi,

Ultimately this approach uses the ._meta.managed setting to affect which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting which
is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a whole
different level.

Manipulating this setting is trivial* and it
+connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive (shared)
and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so it's
visible for "public tables in the public scope" and then fro "tenant
tables
only in the tenant scope"? (that would mean that the south tables are
in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a need
for
having models that are public-exclusive or that are both
tenant-specific
and at the public schema. For example, suppose I want to have south
on
the
tenants and also on public. Should we treat this as having a model
being
both, tenant-specific and shared? That means it would be under
SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives
the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it should
   work
   perfectly right now because models are synced with only one schema at
   the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to
   ,
   public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make sense? I
   can't think of an example.

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13090962>.

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

Bernardo Pires Carneiro

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

[bernardopires]

Ok, it seems it was a bug on my side. --shared seems to work perfectly now,
but I still have a small issue with --tenant.

2013/2/4 Bernardo Carneiro carneiro.be@gmail.com

I ran your command setting the verbosity of syncdb to 3 and it seems like
somehow all installed_apps are still processed on the background, even
though the tables are not created. Is this how it's supposed to work?

2013/2/4 Stefán Baxter notifications@github.com

Hi,

Ultimately this approach uses the ._meta.managed setting to affect which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting which
is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a whole
different level.

Manipulating this setting is trivial* and it
+connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive (shared)
and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so it's
visible for "public tables in the public scope" and then fro "tenant
tables
only in the tenant scope"? (that would mean that the south tables are
in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a need
for
having models that are public-exclusive or that are both
tenant-specific
and at the public schema. For example, suppose I want to have south on
the
tenants and also on public. Should we treat this as having a model
being
both, tenant-specific and shared? That means it would be under
SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives
the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it should
   work
   perfectly right now because models are synced with only one schema at
   the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to
   ,
   public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make sense? I
   can't think of an example.

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

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

Bernardo Pires Carneiro

Bernardo Pires Carneiro

[bernardopires]

Alright, everything seems to be working now. It was again a mistake on my
part, I didn't have the bare minimum apps listed under tenant_apps, like
django.contrib.user. So, I'm now going to adapt your code a little so that
it can replace sync_schemas, ok? I'm keeping your --tenant and --shared
options, but if none is presented, then both are ran (shared first). If
TENANT_APPS neither SHARED_APPS are set than it just supposes everything is
managed (nothing will be changed). This way it should be backwards
compatible. What do you think?

2013/2/4 Stefán Baxter notifications@github.com

Yes, all models are validated. The manage switch then stops it from
creating them in the wrong place. This is the desired way and the only way
to create valid relations between schemas
On 4 Feb 2013 19:17, "Bernardo Pires Carneiro" notifications@github.com
wrote:

I ran your command setting the verbosity of syncdb to 3 and it seems
like
somehow all installed_apps are still processed on the background, even
though the tables are not created. Is this how it's supposed to work?

2013/2/4 Stefán Baxter notifications@github.com

Hi,

Ultimately this approach uses the ._meta.managed setting to affect
which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting
which
is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a whole
different level.

Manipulating this setting is trivial* and it
+connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't
manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com
wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive
(shared)
and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so
it's
visible for "public tables in the public scope" and then fro "tenant
tables
only in the tenant scope"? (that would mean that the south tables
are
in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a
need
for
having models that are public-exclusive or that are both
tenant-specific
and at the public schema. For example, suppose I want to have south
on
the
tenants and also on public. Should we treat this as having a model
being
both, tenant-specific and shared? That means it would be under
SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives
the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We
   should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it
   should
   work
   perfectly right now because models are synced with only one schema
   at
   the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to
   ,
   public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make sense?
   I
   can't think of an example.

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13090962>.

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13092777>.

Bernardo Pires Carneiro

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

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

Bernardo Pires Carneiro

[acmeguy]

fine, use this anyway you like :)

On Mon, Feb 4, 2013 at 7:43 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Alright, everything seems to be working now. It was again a mistake on my
part, I didn't have the bare minimum apps listed under tenant_apps, like
django.contrib.user. So, I'm now going to adapt your code a little so that
it can replace sync_schemas, ok? I'm keeping your --tenant and --shared
options, but if none is presented, then both are ran (shared first). If
TENANT_APPS neither SHARED_APPS are set than it just supposes everything
is
managed (nothing will be changed). This way it should be backwards
compatible. What do you think?

2013/2/4 Stefán Baxter notifications@github.com

Yes, all models are validated. The manage switch then stops it from
creating them in the wrong place. This is the desired way and the only
way
to create valid relations between schemas
On 4 Feb 2013 19:17, "Bernardo Pires Carneiro" notifications@github.com

wrote:

I ran your command setting the verbosity of syncdb to 3 and it seems
like
somehow all installed_apps are still processed on the background, even
though the tables are not created. Is this how it's supposed to work?

2013/2/4 Stefán Baxter notifications@github.com

Hi,

Ultimately this approach uses the ._meta.managed setting to affect
which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting
which
is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a
whole
different level.

Manipulating this setting is trivial* and it
+connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't
manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com
wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive
(shared)
and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive =
only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so
it's
visible for "public tables in the public scope" and then fro
"tenant
tables
only in the tenant scope"? (that would mean that the south tables
are
in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a
need
for
having models that are public-exclusive or that are both
tenant-specific
and at the public schema. For example, suppose I want to have
south
on
the
tenants and also on public. Should we treat this as having a
model
being
both, tenant-specific and shared? That means it would be under
SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared
gives
the
impression the tenant is going to be able to use it. So we have
the
following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We
   should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it
   should
   work
   perfectly right now because models are synced with only one
   schema
   at
   the
   search_path. So when syncing tenants it doesn't know what exists
   on
   public. But when at a normal view the search_path will be set to
   ,
   public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make
   sense?
   I
   can't think of an example.

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13090962>.

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13092777>.

Bernardo Pires Carneiro

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13093834>.

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

Bernardo Pires Carneiro

—

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

[bernardopires]

I still need to update the docs but your patch is in! Don't forget to send your patch for the other issue you solved: #3

[acmeguy]

Yes, all models are validated. The manage switch then stops it from
creating them in the wrong place. This is the desired way and the only way
to create valid relations between schemas
On 4 Feb 2013 19:17, "Bernardo Pires Carneiro" notifications@github.com
wrote:

I ran your command setting the verbosity of syncdb to 3 and it seems like
somehow all installed_apps are still processed on the background, even
though the tables are not created. Is this how it's supposed to work?

2013/2/4 Stefán Baxter notifications@github.com

Hi,

Ultimately this approach uses the ._meta.managed setting to affect which
tables should be managed, at what time and in what schema.

For me this is a straight forward approach and relies on a setting which
is
there for this purpose exactly.
The APP cache approach, on the other hand, tries to do this on a whole
different level.

Manipulating this setting is trivial* and it
+connection.set_tenant(tenant,
include_public = True) should provide enough flexibility for these
different scenarios.

*just remember to put it back in its original state and don't manipulate
un-managed models :)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:44 PM, Stefan Baxter stebax@gmail.com wrote:

Hi,

The way it works now is that SHARED_APPS are public-exclusive (shared)
and
TENANT_APPS are tenant-exclusive.
In this context are apps more public than shared? (exclusive = only
created in the corresponding schema (public being a schema))

I would think that the different south modes are controlled with
"connection.set_tenant(tenant, include_public = True)" or
"connection.set_tenant(tenant, include_public = False)"

I'm not to familiar with south but would belong in both groups so it's
visible for "public tables in the public scope" and then fro "tenant
tables
only in the tenant scope"? (that would mean that the south tables are
in
all schemas + public)

Regards,
-Stefan

On Mon, Feb 4, 2013 at 6:21 PM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Stefan, I'd like your input on something. I think there may be a need
for
having models that are public-exclusive or that are both
tenant-specific
and at the public schema. For example, suppose I want to have south on
the
tenants and also on public. Should we treat this as having a model
being
both, tenant-specific and shared? That means it would be under
SHARED_APPS
and TENANT_APPS. It is a bit misleading because saying shared gives
the
impression the tenant is going to be able to use it. So we have the
following scenarios

1. A model is tenant-specific.
2. A model has to be shared, for example auth.
3. A model should exist in both worlds, for example south. We should
   be able to achieve this via SHARED_APPS and TENANT_APPS and it should
   work
   perfectly right now because models are synced with only one schema at
   the
   search_path. So when syncing tenants it doesn't know what exists on
   public. But when at a normal view the search_path will be set to
   ,
   public making the shared data visible.
4. A model is public-exclusive. Does this scenario even make sense? I
   can't think of an example.

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

https://github.com/bcarneiro/django-tenant-schemas/issues/1#issuecomment-13090962>.

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

Bernardo Pires Carneiro

—

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

[bernardopires]

Hey Stefan, your last message turned out weird. Is everything working as you wanted?

[acmeguy]

Have not tried it yet, but I think so (looking at the code) :)
Will hava a report for you tonight.

On Tue, Feb 5, 2013 at 7:01 AM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

Hey Stefan, your last message turned out weird. Is everything working as
you wanted?

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

[bernardopires]

docs have been updated, I'll close this issue if you don't find any problem :)

[acmeguy]

great, thnx!

On Tue, Feb 5, 2013 at 10:49 AM, Bernardo Pires Carneiro <
notifications@github.com> wrote:

docs have been updated, I'll close this issue if you don't find any
problem :)

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

[bernardopires]

Can I close this issue or do you have any other concern?

[acmeguy]

I'm fine :)