Chris Mayan wrote: > Something akin to a subscriber/publisher design pattern, where I can > subscribe to the DB from rails and say, "Notify me when anything to do with > this row" has changed.. and then when something does change the DB is the > one that communicates back through the db connection signalling to call > .reload…
The thing is, you're working in a stateless web world. Even if there was some way for the DB to notify you're AR instance that the underlying data has changed, that instance may have been garbage collected 30 minutes ago when the original HTTP request was completed. Meanwhile the user has been staring at their web form for 30 minutes and has only just decided to hit submit. Given the nature of HTTP, your realistic options are: * accept occasional data loss when changes are over-ridden * optimistic locking like that provided by lock_version * big chunky application layer locks. Create an AR model called Lock, have your edit action create a lock, and subsequent requests to the same action are denied until the user submits the form. Messy, but sometimes required. -- James Healy <[email protected]> Fri, 19 Nov 2010 11:18:50 +1100 -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
