Comments (30)
+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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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. - 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
A model is tenant-specific.
A model has to be shared, for example auth.
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.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,
-StefanOn 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
A model is tenant-specific.
A model has to be shared, for example auth.
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.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,
-StefanOn 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,
-StefanOn 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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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.- 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,
-StefanOn 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,
-StefanOn 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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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.- 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,
-StefanOn 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,
-StefanOn 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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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.- 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,
-StefanOn 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,
-StefanOn 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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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.- 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,
-StefanOn 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,
-StefanOn 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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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.- 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,
-StefanOn 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,
-StefanOn 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
- A model is tenant-specific.
- A model has to be shared, for example auth.
- 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.- 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.
Related Issues (20)
- Can't migrate new tables to tennant apps.
- New tenant model is not creating relations in non-public schema with multiple databases
- Accessing tenants data from public. HOT 1
- django-tenants TypeError: argument of type 'TenantQueryset' is not iterable
- ImportError: cannot import name 'force_text' from 'django.utils.encoding' HOT 3
- How to create tenant_schemas.storage.TenantFileSystemStorage within AWS s3 bucket with django-storages 1.12.3
- "Apps aren't loaded yet" when upgrading from django 3.0.10 to 3.2
- Schema Deletion HOT 1
- DRF example
- Support for django 4.0 HOT 7
- how to launch tenant_command loaddata from views with fixtures HOT 1
- Supported Version Django HOT 3
- Distinguish between workspaces
- error 500 DEBUG=False in production HOT 1
- [Solution] Unable to create the django_migrations -relation already exists HOT 1
- healthcheck HOT 2
- Issue in holding DB connection consistently HOT 1
- @contextmanager
- Django-tenants - please help
- About changing public schema to other schema. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-tenant-schemas.