On Thu, Jul 29, 2010 at 5:27 AM, John-Scott Atlakson < [email protected]> 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. -- 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.
