Comments (7)
Well, it's a little too late to switch to sites now, but what I don't like about sites is that it's not very flexible. You can't add new fields to it and most likely everyone wants extra fields on their tenants, this is also why I chose the Mixin approach. Besides that I didn't know if using sites would have any unpredictable side effect on other parts of the code, seeing as django seems to use it internally in multiple places.
from django-tenant-schemas.
Hi,
Would it be fare to suggest that there is a setting which would trigger the
tenant mixin to synchronize the sites and if used then the middleware would
also make sure that the current site is always set correctly for requests?
Regards,
-Stefan
On Wed, Feb 6, 2013 at 2:38 PM, Bernardo Pires Carneiro <
[email protected]> wrote:
Well, it's a little too late to switch to sites now, but what I don't like
about sites is that it's not very flexible. You can't add new fields to it
and most likely everyone wants extra fields on their tenants, this is also
why I chose the Mixin approach. Besides that I didn't know if using sites
would have any unpredictable side effect on other parts of the code, seeing
as django seems to use it internally in multiple places.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-13184553.
from django-tenant-schemas.
Can you please explain how you depend on sites? What do you need from it?
2013/2/6 Stefán Baxter [email protected]
Hi,
Would it be fare to suggest that there is a setting which would trigger
the
tenant mixin to synchronize the sites and if used then the middleware
would
also make sure that the current site is always set correctly for requests?Regards,
-StefanOn Wed, Feb 6, 2013 at 2:38 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Well, it's a little too late to switch to sites now, but what I don't
like
about sites is that it's not very flexible. You can't add new fields to
it
and most likely everyone wants extra fields on their tenants, this is
also
why I chose the Mixin approach. Besides that I didn't know if using
sites
would have any unpredictable side effect on other parts of the code,
seeing
as django seems to use it internally in multiple places.—
Reply to this email directly or view it on GitHub<
https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13184553>.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-13186608.
Bernardo Pires Carneiro
from django-tenant-schemas.
Hi,
I need nothing from it :). It just seems right to include support for sites
for the "tenant-sites".
It would allow packages that function correctly with sites to function
correctly with tenant-schemas.
Regards,
-Stefan
On Wed, Feb 6, 2013 at 3:22 PM, Bernardo Pires Carneiro <
[email protected]> wrote:
Can you please explain how you depend on sites? What do you need from it?
2013/2/6 Stefán Baxter [email protected]
Hi,
Would it be fare to suggest that there is a setting which would trigger
the
tenant mixin to synchronize the sites and if used then the middleware
would
also make sure that the current site is always set correctly for
requests?Regards,
-StefanOn Wed, Feb 6, 2013 at 2:38 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Well, it's a little too late to switch to sites now, but what I don't
like
about sites is that it's not very flexible. You can't add new fields
to
it
and most likely everyone wants extra fields on their tenants, this is
also
why I chose the Mixin approach. Besides that I didn't know if using
sites
would have any unpredictable side effect on other parts of the code,
seeing
as django seems to use it internally in multiple places.—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13184553>.
—
Reply to this email directly or view it on GitHub<
https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186608>.Bernardo Pires Carneiro
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-13186779.
from django-tenant-schemas.
Oh I see. Well, in that case I would avoid using the sites table at all if
possible (just to save an extra query). We could force django to return a
fake site when calling Site.objects.get_current(). Would this be enough?
2013/2/6 Stefán Baxter [email protected]
Hi,
I need nothing from it :). It just seems right to include support for
sites
for the "tenant-sites".
It would allow packages that function correctly with sites to function
correctly with tenant-schemas.Regards,
-StefanOn Wed, Feb 6, 2013 at 3:22 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Can you please explain how you depend on sites? What do you need from
it?2013/2/6 Stefán Baxter [email protected]
Hi,
Would it be fare to suggest that there is a setting which would
trigger
the
tenant mixin to synchronize the sites and if used then the middleware
would
also make sure that the current site is always set correctly for
requests?Regards,
-StefanOn Wed, Feb 6, 2013 at 2:38 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Well, it's a little too late to switch to sites now, but what I
don't
like
about sites is that it's not very flexible. You can't add new fields
to
it
and most likely everyone wants extra fields on their tenants, this
is
also
why I chose the Mixin approach. Besides that I didn't know if using
sites
would have any unpredictable side effect on other parts of the code,
seeing
as django seems to use it internally in multiple places.—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13184553>.
—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186608>.
Bernardo Pires Carneiro
—
Reply to this email directly or view it on GitHub<
https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186779>.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-13186987.
Bernardo Pires Carneiro
from django-tenant-schemas.
Hi,
I don't think so. These packages normally have rules, settings, preferences
linked to the proper site.
Caching tenant and site objects, across threads (django-idmapper), to avoid
db lookup for every page request might this a trivial impact.
Fell free to close this issue, it's really just an observation on my behalf
at this time.
Regards,
-Stefan
On Wed, Feb 6, 2013 at 3:29 PM, Bernardo Pires Carneiro <
[email protected]> wrote:
Oh I see. Well, in that case I would avoid using the sites table at all if
possible (just to save an extra query). We could force django to return a
fake site when calling Site.objects.get_current(). Would this be enough?2013/2/6 Stefán Baxter [email protected]
Hi,
I need nothing from it :). It just seems right to include support for
sites
for the "tenant-sites".
It would allow packages that function correctly with sites to function
correctly with tenant-schemas.Regards,
-StefanOn Wed, Feb 6, 2013 at 3:22 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Can you please explain how you depend on sites? What do you need from
it?2013/2/6 Stefán Baxter [email protected]
Hi,
Would it be fare to suggest that there is a setting which would
trigger
the
tenant mixin to synchronize the sites and if used then the
middleware
would
also make sure that the current site is always set correctly for
requests?Regards,
-StefanOn Wed, Feb 6, 2013 at 2:38 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Well, it's a little too late to switch to sites now, but what I
don't
like
about sites is that it's not very flexible. You can't add new
fields
to
it
and most likely everyone wants extra fields on their tenants, this
is
also
why I chose the Mixin approach. Besides that I didn't know if
using
sites
would have any unpredictable side effect on other parts of the
code,
seeing
as django seems to use it internally in multiple places.—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13184553>.
—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186608>.
Bernardo Pires Carneiro
—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186779>.
—
Reply to this email directly or view it on GitHub<
https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186987>.Bernardo Pires Carneiro
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-13187151.
from django-tenant-schemas.
Hi Stefan,
I just wanted to say that I like your smart observations! If you are
interested in implementing this feel free to send in a patch, but I would
wait until someone asks for these features.
Bernardo
2013/2/6 Stefán Baxter [email protected]
Hi,
I don't think so. These packages normally have rules, settings,
preferences
linked to the proper site.
Caching tenant and site objects, across threads (django-idmapper), to
avoid
db lookup for every page request might this a trivial impact.Fell free to close this issue, it's really just an observation on my
behalf
at this time.Regards,
-StefanOn Wed, Feb 6, 2013 at 3:29 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Oh I see. Well, in that case I would avoid using the sites table at all
if
possible (just to save an extra query). We could force django to return
a
fake site when calling Site.objects.get_current(). Would this be enough?2013/2/6 Stefán Baxter [email protected]
Hi,
I need nothing from it :). It just seems right to include support for
sites
for the "tenant-sites".
It would allow packages that function correctly with sites to function
correctly with tenant-schemas.Regards,
-StefanOn Wed, Feb 6, 2013 at 3:22 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Can you please explain how you depend on sites? What do you need
from
it?2013/2/6 Stefán Baxter [email protected]
Hi,
Would it be fare to suggest that there is a setting which would
trigger
the
tenant mixin to synchronize the sites and if used then the
middleware
would
also make sure that the current site is always set correctly for
requests?Regards,
-StefanOn Wed, Feb 6, 2013 at 2:38 PM, Bernardo Pires Carneiro <
[email protected]> wrote:Well, it's a little too late to switch to sites now, but what I
don't
like
about sites is that it's not very flexible. You can't add new
fields
to
it
and most likely everyone wants extra fields on their tenants,
this
is
also
why I chose the Mixin approach. Besides that I didn't know if
using
sites
would have any unpredictable side effect on other parts of the
code,
seeing
as django seems to use it internally in multiple places.—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13184553>.
—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186608>.
Bernardo Pires Carneiro
—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186779>.
—
Reply to this email directly or view it on GitHub<https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13186987>.
Bernardo Pires Carneiro
—
Reply to this email directly or view it on GitHub<
https://github.com/bcarneiro/django-tenant-schemas/issues/21#issuecomment-13187151>.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-13187415.
Bernardo Pires Carneiro
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.