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 <[email protected]> > 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 -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
