On Jul 29, 2010, at 10:55 AM, Bruce Kroeze wrote: > 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.
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 [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. -- 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.
