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