Hm, the product must have a heck of a lot of variations for recalculating prices for a single product and its variations to take a long time.
What if we were to create a livesetting -- if set to true, we'll recalculate for just the product whose variations we're managing, and if set to false, prices will not be recalculated until the management command is run manually / via cron job? Help text for the livesetting could explain to set to false and run manually/via cron if you're seeing a performance hit when creating variations. On Apr 12, 7:20 am, hynekcer <[email protected]> wrote: > Yes, this is dead simple. > It is not good to add 'satchmo_rebuild_pricing' to variation manager. > Previous dead simle solution was to remove automatic price update of > _one_ configurable product, because it have taken long time for some > users. Now it was done all in a batch aftewards. > > Doing the whole batch for every products after one product update > would be even worse than the original state. > > On Apr 12, 2:58 am, Nan <[email protected]> wrote: > > > > > > > > > To follow up, I've added a (dead simple) patch implementing this fix, > > available at [1]. > > > [1]https://bitbucket.org/ringemup/satchmo-clean/changeset/5f6f0c74f42b -- 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.
