@Fred: The information that only n more products exist will come from (@product.order_limit - @product.orders.count) >= n. It's a bit more complicated than that, because I plan to have optional per- ProductVariant limits too, but let's leave it there for now.
@Fred & @Hassan: I don't really want to have "unsold" ProductVariants hanging around in the database, because the availability of ProductVariants is largely procedural. If the order_limit on the Product as a whole was 20, the order_limit on ProductVariant A was 10, and ProductVariant B had no order_limit, then I'd end up with a whole lot of questions as to how many unsold ProductVariants to create of each type, and which ones to destroy when others were sold. Bah, too much mess! @Charles: I like the idea of an OrderTaker global queue, but global queue means worker process, and worker process means extra messy infrastructure, right? I'm all for it, I'm just wondering if anyone has a better mousetrap. @Fred: Row-level locks are out of the question, since I'm not interested in blocking updates to a given row, but the creation of rows that don't yet exist in the Orders table. That said, I found this today – named locks in MySQL. It's a database-specific solution, but perhaps an easy one? http://gist.github.com/95977 Named locks in MySQL: http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_get-lock Shopify's locking implementation: http://github.com/Shopify/locking/blob/835469ed48f4c2de95856fe2f221eaa624b267a2/lib/locking.rb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
