Add support for Shared Applications about django-tenant-schemas HOT 30 CLOSED

+1 this model sounds workable, thanks, L

from django-tenant-schemas.

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

from django-tenant-schemas.

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 [email protected]

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

from django-tenant-schemas.

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

from django-tenant-schemas.

sure, let's try it mate!

2013/2/2 Stefán Baxter [email protected]

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

from django-tenant-schemas.

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)

from django-tenant-schemas.

Perfect!

2013/2/2 Stefán Baxter [email protected]

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

from django-tenant-schemas.

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

from django-tenant-schemas.

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)

from django-tenant-schemas.

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 [email protected]

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

from django-tenant-schemas.

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.

from django-tenant-schemas.

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 [email protected]

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

from django-tenant-schemas.

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

from django-tenant-schemas.

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.

from django-tenant-schemas.

Understand, this should be a simple addition.

from django-tenant-schemas.

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 <
[email protected]> 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//issues/1#issuecomment-13090962.

from django-tenant-schemas.

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 [email protected] 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 <
[email protected]> 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//issues/1#issuecomment-13090962.

from django-tenant-schemas.

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 [email protected]

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 [email protected] 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 <
[email protected]> 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

from django-tenant-schemas.

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" [email protected]
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 [email protected]

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 [email protected] 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 <
[email protected]> 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.

from django-tenant-schemas.

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 [email protected]

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 [email protected]

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 [email protected] 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 <
[email protected]> 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

from django-tenant-schemas.

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 [email protected]

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" [email protected]
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 [email protected]

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 [email protected]
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 <
[email protected]> 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

from django-tenant-schemas.

fine, use this anyway you like :)

On Mon, Feb 4, 2013 at 7:43 PM, Bernardo Pires Carneiro <
[email protected]> 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 [email protected]

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" [email protected]

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 [email protected]

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 [email protected]
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 <
[email protected]> 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.

from django-tenant-schemas.

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

from django-tenant-schemas.

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" [email protected]
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 [email protected]

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 [email protected] 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 <
[email protected]> 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.

from django-tenant-schemas.

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

from django-tenant-schemas.

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 <
[email protected]> 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.

from django-tenant-schemas.

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

from django-tenant-schemas.

great, thnx!

On Tue, Feb 5, 2013 at 10:49 AM, Bernardo Pires Carneiro <
[email protected]> 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.

from django-tenant-schemas.

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

from django-tenant-schemas.

I'm fine :)

from django-tenant-schemas.