Utilize Sites framework

[bernardopires]

Utilize Sites framework

[bernardopires]

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.

[acmeguy]

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.

[bernardopires]

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,
-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 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

[acmeguy]

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,
-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 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.

[bernardopires]

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,
-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,
-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 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

[acmeguy]

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,
-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,
-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 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.

[bernardopires]

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,
-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,
-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,
-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 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