django-threaded-multihost

[John-Scott]

Currently, there is no documentation for django-threaded-multihost in
the django-threaded-multihost code [1].

In the Satchmo documentation, django-threaded-multihost gets a brief
mention in the requirements documentation which simply says [2]:

"""To support multi store configurations"""

I see that if SATCHMO_SETTINGS = {'MULTISHOP': True}, then a monkey
patch for Site.objects.get_current() is applied (which says it
'Patched Django for multihost awareness.').

So we have 'multihost', 'MULTISHOP' and 'multi store'. 'host' and
'store/shop' are two different things right? Is this a documentation
bug/unfortunate naming of a setting?

In another post on this list [3], the OP is trying to host two shops
on the same site, e.g. example.com/shop1/ and example.com/shop2/ but
discovers that the threaded_multihost monkey patch will attempt to
lookup the ``current_site`` in the database by domain and not by
settings.SITE_ID, leading to surprising behavior.

The standard Django supplied shortcut ``Site.objects.get_current()``
is optimized to only hit the db once, for the life of the application
server process by relying on the clearly documented settings.SITE_ID
and caching the result. In threaded_multihost.sites.by_host there's a
whole chain of try/except if/else blocks, which could result in
several queries and, since this is a thread local variable dependent
on each request, this happens every single request.

What does the multihost bit of django-threaded-multihost provide that
using the standard Django sites framework can't?

How would one run multiple stores for the SAME SITE, managed by the
same Django/Satchmo admin interface at all, django-threaded-multihost
or not (e.g. example.com/shop1/ & example.com/shop2/)?
Is this even possible currently?

Any chance the author(s) can shed some light on the intended usage so
we can document this?

Thanks,
John-Scott

[1] http://bitbucket.org/bkroeze/django-threaded-multihost
[2] http://bitbucket.org/chris1610/satchmo/src/tip/docs/requirements.txt#cl-40
[3] http://groups.google.com/group/satchmo-users/browse_thread/thread/7c1c8bc1e488c17d/

[Bruce Kroeze]

I'm the author of django-threaded-multihost.  I'll answer a few of these questions for you.

On Wed, Jul 28, 2010 at 4:37 PM, John-Scott <john.scot...@gmail.com> wrote:

In the Satchmo documentation, django-threaded-multihost gets a brief
mention in the requirements documentation which simply says [2]:

"""To support multi store configurations"""

I see that if SATCHMO_SETTINGS = {'MULTISHOP': True}, then a monkey
patch for Site.objects.get_current() is applied (which says it
'Patched Django for multihost awareness.').

So we have 'multihost', 'MULTISHOP' and 'multi store'. 'host' and
'store/shop' are two different things right? Is this a documentation
bug/unfortunate naming of a setting?

Satchmo calls having multiple shops with the same settings file a "Multishop", while threaded_multihost uses the more generic term "Multihost".  The log output is coming from threaded_multihost, which is why it uses the latter term.

Yes, it could be tightened up a bit, but not a big deal at all, rather nitpicky.  If it truly bothers you, feel free to make the old name deprecated in the Satchmo code and standardize on "Multihost."  As long as it remains backward compatible, I don't care.

 

In another post on this list [3], the OP is trying to host two shops
on the same site, e.g. example.com/shop1/ and example.com/shop2/ but
discovers that the threaded_multihost monkey patch will attempt to
lookup the ``current_site`` in the database by domain and not by
settings.SITE_ID, leading to surprising behavior.

I'm not sure why that is surprising.  The whole idea of threaded_multihost is to enable the use of one settings file and one instance of Django to run multiple stores.  

 

The standard Django supplied shortcut ``Site.objects.get_current()``

is optimized to only hit the db once, for the life of the application
server process by relying on the clearly documented settings.SITE_ID
and caching the result.

This is precisely the problem.  Settings.SITE_ID gets cached.  That means the only truly resilient way to have multiple sites using the built-in sites framework is to have multiple copies of settings.py and to run separate instances of Django against them.

That's far more heavyweight in server resource usage, primarily memory.  One of my clients runs a multiple store configuration on a Slicehost server with 512MB of memory.  That would be impossible to achieve if he had to run four simultaneous Satchmo stores, each with the footprint of 200-300MB.

In threaded_multihost.sites.by_host there's a
whole chain of try/except if/else blocks, which could result in
several queries and, since this is a thread local variable dependent
on each request, this happens every single request.

No, look at it again.  It caches (properly caches, using the caching system, not the in-memory global used by the default Django sites app) the result of the hostname lookup, so in most cases the database isn't hit at all.  If it does have to resolve the current site, then it may take a couple DB hits to try to figure out what the site for the current domain may be.  Then the result is cached and next time will take very low resources to figure out.

What does the multihost bit of django-threaded-multihost provide that
using the standard Django sites framework can't?

1) Significantly decreased memory usage.

2) Much easier configuration - no need to maintain multiple settings files.

3) It is optional - If you'd rather have multiple sites managed by multiple settings files and multiple Django instances, simply never instruct Satchmo to load the monkey patch, and it will work just fine.

How would one run multiple stores for the SAME SITE, managed by the
same Django/Satchmo admin interface at all, django-threaded-multihost
or not (e.g. example.com/shop1/ & example.com/shop2/)?
Is this even possible currently?

No, not supported by Satchmo at the moment.  Threaded_multihost isn't intended for that situation either.

 

--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.

[John-Scott Atlakson]

On Jul 29, 2010, at 7:24 AM, Bruce Kroeze wrote:

I'm the author of django-threaded-multihost.  I'll answer a few of these questions for you.

On Wed, Jul 28, 2010 at 4:37 PM, John-Scott <john.scot...@gmail.com> wrote:

In the Satchmo documentation, django-threaded-multihost gets a brief
mention in the requirements documentation which simply says [2]:

"""To support multi store configurations"""

I see that if SATCHMO_SETTINGS = {'MULTISHOP': True}, then a monkey
patch for Site.objects.get_current() is applied (which says it
'Patched Django for multihost awareness.').

So we have 'multihost', 'MULTISHOP' and 'multi store'. 'host' and
'store/shop' are two different things right? Is this a documentation
bug/unfortunate naming of a setting?

Satchmo calls having multiple shops with the same settings file a "Multishop", while threaded_multihost uses the more generic term "Multihost".  The log output is coming from threaded_multihost, which is why it uses the latter term.

Yes, it could be tightened up a bit, but not a big deal at all, rather nitpicky.  If it truly bothers you, feel free to make the old name deprecated in the Satchmo code and standardize on "Multihost."  As long as it remains backward compatible, I don't care.

Right, it may sound nitpicky if you already know how it all works, but in absence of documentation it's not entirely clear what's being enabled or how. Not trying to be pendantic here, honest ;)

 

In another post on this list [3], the OP is trying to host two shops
on the same site, e.g. example.com/shop1/ and example.com/shop2/ but
discovers that the threaded_multihost monkey patch will attempt to
lookup the ``current_site`` in the database by domain and not by
settings.SITE_ID, leading to surprising behavior.

I'm not sure why that is surprising.  The whole idea of threaded_multihost is to enable the use of one settings file and one instance of Django to run multiple stores.  

The OP was surprised. Again, in absence of documentation, one wouldn't know what is expected behavior unless they trace what is going on in the code closely. All Satchmo says is that you need to install it to 'support multi store configurations'. Nothing indicates that the sites framework will suddenly work differently.

 

The standard Django supplied shortcut ``Site.objects.get_current()``

is optimized to only hit the db once, for the life of the application
server process by relying on the clearly documented settings.SITE_ID
and caching the result.

This is precisely the problem.  Settings.SITE_ID gets cached.  That means the only truly resilient way to have multiple sites using the built-in sites framework is to have multiple copies of settings.py and to run separate instances of Django against them.

That's far more heavyweight in server resource usage, primarily memory.  One of my clients runs a multiple store configuration on a Slicehost server with 512MB of memory.  That would be impossible to achieve if he had to run four simultaneous Satchmo stores, each with the footprint of 200-300MB.

Aha! So this is the use case/intended usage? Use the sites app to set up completely different domains e.g. example.com, foo.com, bar. com but only use a single settings file. django-threaded-multihost will automagically figure out which site is 'current' without needing the setttings.SITE_ID (although it will fall back to this if it can't figure it out).

In threaded_multihost.sites.by_host there's a
whole chain of try/except if/else blocks, which could result in
several queries and, since this is a thread local variable dependent
on each request, this happens every single request.

No, look at it again.  It caches (properly caches, using the caching system, not the in-memory global used by the default Django sites app) the result of the hostname lookup, so in most cases the database isn't hit at all.  If it does have to resolve the current site, then it may take a couple DB hits to try to figure out what the site for the current domain may be.  Then the result is cached and next time will take very low resources to figure out.

I'll take your word for it, that's just what it appeared to be doing on a quick glance. Must have misread what was happening and how.

What does the multihost bit of django-threaded-multihost provide that
using the standard Django sites framework can't?

1) Significantly decreased memory usage.

2) Much easier configuration - no need to maintain multiple settings files.

3) It is optional - If you'd rather have multiple sites managed by multiple settings files and multiple Django instances, simply never instruct Satchmo to load the monkey patch, and it will work just fine.

How would one run multiple stores for the SAME SITE, managed by the
same Django/Satchmo admin interface at all, django-threaded-multihost
or not (e.g. example.com/shop1/ & example.com/shop2/)?
Is this even possible currently?

No, not supported by Satchmo at the moment.  Threaded_multihost isn't intended for that situation either.

Ouch, that's what I was afraid of. I'm just an anecdotal case I guess but I have two big clients that both need to run two separate stores from the same site. Think retail/wholesale. There is completely different pricing policies in place (displayed 'normal' price, 'sale' price) and in some cases different products even. This may have not been the right choice. Hmm.

Thanks for your responses. Again, it's just the absence of documentation that makes all of this a bit opaque, as the author I'm sure it seems completely obvious to you. I had to spend quite a bit of time reading the mailing list and then following the trail of code to get just a basic idea of what was going on, but that still doesn't explain 'why' or 'how' this was intended to be used. Your answers definitely clarify that. I'll see if I can at least distill this into a brief paragraph to add to the documentation.

Thanks again,

John-Scott

[Bruce Kroeze]

On Thu, Jul 29, 2010 at 5:27 AM, John-Scott Atlakson <john.scot...@gmail.com> wrote:

On Jul 29, 2010, at 7:24 AM, Bruce Kroeze wrote:

So we have 'multihost', 'MULTISHOP' and 'multi store'. 'host' and
'store/shop' are two different things right? Is this a documentation
bug/unfortunate naming of a setting?

Satchmo calls having multiple shops with the same settings file a "Multishop", while threaded_multihost uses the more generic term "Multihost".  The log output is coming from threaded_multihost, which is why it uses the latter term.

Yes, it could be tightened up a bit, but not a big deal at all, rather nitpicky.  If it truly bothers you, feel free to make the old name deprecated in the Satchmo code and standardize on "Multihost."  As long as it remains backward compatible, I don't care.

Right, it may sound nitpicky if you already know how it all works, but in absence of documentation it's not entirely clear what's being enabled or how. Not trying to be pendantic here, honest ;)

I realize I may have sounded irritated.  Not my intent.  It really does need more documentation, I'm just not that great a documenter.

  

The standard Django supplied shortcut ``Site.objects.get_current()``

is optimized to only hit the db once, for the life of the application
server process by relying on the clearly documented settings.SITE_ID
and caching the result.

This is precisely the problem.  Settings.SITE_ID gets cached.  That means the only truly resilient way to have multiple sites using the built-in sites framework is to have multiple copies of settings.py and to run separate instances of Django against them.

That's far more heavyweight in server resource usage, primarily memory.  One of my clients runs a multiple store configuration on a Slicehost server with 512MB of memory.  That would be impossible to achieve if he had to run four simultaneous Satchmo stores, each with the footprint of 200-300MB.

Aha! So this is the use case/intended usage? Use the sites app to set up completely different domains e.g. example.com, foo.com, bar. com but only use a single settings file. django-threaded-multihost will automagically figure out which site is 'current' without needing the setttings.SITE_ID (although it will fall back to this if it can't figure it out).

This is exactly the intended usage.  If you need separate settings, template dirs, etc, then separate settings files are the proper way to go about it.

 

How would one run multiple stores for the SAME SITE, managed by the
same Django/Satchmo admin interface at all, django-threaded-multihost
or not (e.g. example.com/shop1/ & example.com/shop2/)?
Is this even possible currently?

No, not supported by Satchmo at the moment.  Threaded_multihost isn't intended for that situation either.

Ouch, that's what I was afraid of. I'm just an anecdotal case I guess but I have two big clients that both need to run two separate stores from the same site. Think retail/wholesale. There is completely different pricing policies in place (displayed 'normal' price, 'sale' price) and in some cases different products even. This may have not been the right choice. Hmm.

I do think you could pull off an integrated backend using separate settings/Django instances.

 

Thanks for your responses. Again, it's just the absence of documentation that makes all of this a bit opaque, as the author I'm sure it seems completely obvious to you. I had to spend quite a bit of time reading the mailing list and then following the trail of code to get just a basic idea of what was going on, but that still doesn't explain 'why' or 'how' this was intended to be used. Your answers definitely clarify that. I'll see if I can at least distill this into a brief paragraph to add to the documentation.

If you do, we'll all appreciate it.  More documentation, especially in this area would help everyone.

[Stuart Laughlin]

Just to clarify (and I see Bruce just replied in this same vein) you
actually can achieve this setup (i.e. example.com/shop1 and
example.com/shop2) with satchmo -- this is precisely what I am doing
-- just not with threaded_multihost. This setup just requires two
django projects, i.e. two settings files. But both of my sites are
being maintained with one integrated admin and are using the same
satchmo (et. al.) installations -- even using the same templates and
media.

So don't be discouraged just yet. :)

--Stuart

[John-Scott Atlakson]

Am working up a doc patch right now, will send a pull request on bitbucket when I've got something readable.

Thanks,

John-Scott

--
Bruce Kroeze
http://www.ecomsmith.com
It's time to hammer your site into shape.

--
You received this message because you are subscribed to the Google Groups "Satchmo users" group.
To post to this group, send email to satchm...@googlegroups.com.
To unsubscribe from this group, send email to satchmo-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.

[Stuart Laughlin]

On Thu, Jul 29, 2010 at 10:00 AM, Stuart Laughlin <stu...@bistrotech.net> wrote:
>
> Just to clarify (and I see Bruce just replied in this same vein) you
> actually can achieve this setup (i.e. example.com/shop1 and
> example.com/shop2) with satchmo -- this is precisely what I am doing
> -- just not with threaded_multihost. This setup just requires two
> django projects, i.e. two settings files. But both of my sites are
> being maintained with one integrated admin and are using the same
> satchmo (et. al.) installations -- even using the same templates and
> media.
>
> So don't be discouraged just yet. :)
>

Ha! I had missed that one of your links was pointing to a prior list
posting by me. As I said, this is the setup I am using, so I'll keep
an eye on the list to see if you have any further questions about
this.

--Stuart

[John-Scott Atlakson]

Right! I saw that your solution was separate settings files. I was holding out hope that this could be managed somehow via a single settings file for a single domain (would have kept the discussion on your thread even but Google Groups wouldn't let me reply on it).

Yes, yesterday was just detective work trying to sort out exactly what Satchmo supported. So now that I have a decent handle on that, I'll have to think through the implications with the current project I'm working on to see how this plays out. It's a fairly complex site, integrating with external order systems via SOAP and all kinds of fun stuff. Anyway, will definitely hit you up if I hit a wall.

Thanks,

John-Scott