Sorry for the late reply, been a while since I've used Google Groups and thought I'd get an automatic email notice on replies to this thread. Anyway.
On Jun 18, 3:55 pm, Tay Ray Chuan <[email protected]> wrote: > Hi, > > On Thu, Jun 17, 2010 at 10:25 PM, John-Scott > > <[email protected]> wrote: > > I have a site that is encountering this error intermittently. Example > > full traceback here =>http://dpaste.com/hold/208436/ > > Nice - thanks for the report. > > > This error can occur during a 'change quantity' action on the cart > > detail page, on the 'add to cart' action and the 'remove from cart' > > action. > > In other words, this is reproducible? I was not able to reproduce the problem myself. I really have no idea why it was so random. This was on a live e-com site and I only received a few alerts per week. I tried hitting the same views repeatedly both in staging and production and never managed to trigger this error. > > > The only thing that is clear is that when Satchmo fires off > > ``remove_partial_order``, Django then goes on to > > ``_collect_sub_objects`` to delete them as well. It seems reasonable > > that the DownloadLink is either being implicitly or explicitly > > imported at some point even though the dowloadable module is not > > installed. > > Hmm, some investigation shows this is being imported in the shop view, > send_file(). I've just committed a changeset (4d23ed40f534) that > shifts this out, such that this "secret" import doesn't happen - do > give it a shot. My fix was just to wrap the download related urls in satchmo_store.shop.urls with a 'if 'product.modules.downloadable' in settings.INSTALLED_APPS:'. I pushed this into production and have not seen an email alert since. These urls were the only 'downloadable' related bit of code I could find that linked to 'satchmo_store.shop.views.download' which imports the 'DownloadLink' model. On a side note, I find Satchmo a little too voodoo when I need to debug stuff. A lot of this has to do with idiosyncrasies in the code that depart from conventions in not very well documented ways. When sorting out urls, I tend to expect to find them in a urls module. Any technical reason these need to be tucked inside a listener? Couldn't we just give the 'downloadable' module its own set of urls and then conditionally 'include' these in the shop urls if it's an installed app? That seems straightforward enough but I can't say I fully understand the purpose of the 'collect_urls' and related magic or what, if any, implications there would be with such a change. > > > FYI, I have upgraded the site to use the 0.9.1 release, cleared out > > all *.pyc files (have done several micro upgrades throughout the rc > > process) just to ensure I was dealing with a clean install. > > Though I'm pretty sure that shift should do it, here's some other > things to try out: > > - have you cleared the cache? > - have you migrated your content types? (0012_update_contenttypes). > > -- > Cheers, > Ray Chuan Thanks, 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.
