Hi all, I need to develop an Rails app where all changes should be done on a "shadow copy" of the data and then committed all at once. Only one user may edit the data at any given time. Other users should not see the changes until the commit is done. Before commiting the changes, the user should be able to review a summary of the changes made since the editing began. These are basically ACID requirements, but the fact that the changes will span multiple HTTP requests -and potentially multiple editing sessions spread out over several days - I''m not sure that database transactions are the best solution (or even feasible) There is not a huge amount of data involved, so copying the entire database when a user enters edit mode is a possibility. Does anybody have any input on this? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 15 Apr 2008, at 10:53, Abigail Headroom wrote:> > Hi all, > > I need to develop an Rails app where all changes should be done on a > "shadow copy" of the data and then committed all at once. Only one > user > may edit the data at any given time. Other users should not see the > changes until the commit is done. Before commiting the changes, the > user > should be able to review a summary of the changes made since the > editing > began. >Perhaps acts_as_versioned could be subverted for this ? Fred> These are basically ACID requirements, but the fact that the changes > will span multiple HTTP requests -and potentially multiple editing > sessions spread out over several days - I''m not sure that database > transactions are the best solution (or even feasible) > > There is not a huge amount of data involved, so copying the entire > database when a user enters edit mode is a possibility. > > Does anybody have any input on this? > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I am assuming that ALL data needs to be locked. That is, every row in every table is locked. A simple way to do it would be to have a check_outs table. It would only ever have one row, and it would have a user_id column. If nobody had anything checked out, then user_id would be nil. Upon checkout the current user''s user_id would be stored in this table. You can then add a validation to every model (except the CheckOut model) that disallows the model from being updated except when current_user.id == CheckOut.user_id. Does that make sense? Paul On Apr 15, 2:53 am, Abigail Headroom <rails-mailing-l...@andreas- s.net> wrote:> Hi all, > > I need to develop an Rails app where all changes should be done on a > "shadow copy" of the data and then committed all at once. Only one user > may edit the data at any given time. Other users should not see the > changes until the commit is done. Before commiting the changes, the user > should be able to review a summary of the changes made since the editing > began. > > These are basically ACID requirements, but the fact that the changes > will span multiple HTTP requests -and potentially multiple editing > sessions spread out over several days - I''m not sure that database > transactions are the best solution (or even feasible) > > There is not a huge amount of data involved, so copying the entire > database when a user enters edit mode is a possibility. > > Does anybody have any input on this? > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thank you both for helping out, I really appreciate it. Fred: I think acts_as_versioned could be helpful in a couple of ways here. It could implement the snapshot which the read-only users will see while someone else is in edit mode. Basically it''s just a matter of storing a list of all object types and a corresponding version number. The revision history per object which acts_as_versioned provides can perhaps be used to keep track of changes made by a user since entering the edit session. Finally, the revert_to method could be used to rollback changes if the user in edit mode decides not to commit anything. Paul: Yes, all data needs to be locked. The check_outs table is a good idea for implementing the concurrency lock, I''ll probably use it! -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I would also need acts_as_paranoid to be able to rollback deletes, and by the looks of it, also do some hacking of both these plugins: http://ward.vandewege.net/blog/2007/02/27/116/ The more I think about it, this journalling alternative feels kinda messy and risky. I would really prefer a solution where edits didn''t affect the real data until the user commits. The extreme case scares me: the user enters edit mode, deletes everything and creates a completely different set of objects, and finally decides not to commit... :-/ Another motivator for another solution (which I accidently omitted yesterday) is that external systems will read the data using SQL and I really don''t want them to be aware of any journalling and snapshot stuff. Does anybody have *any* alternative approaches to this problem? Just thinking out loud - would it be possible to temporarily "short circuit" AR to only operate on in-memory objects for example? (The changes made during an edit session can be considered expendable until committed) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I''m giving this thread a last chance. I feel stuck and would really appreciate any hints on how to solve this. Basically what I''m looking for is the semantics of a full database copy for the duration of the edit session, without having to, ermm.. copy the database. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 21 Apr 2008, at 07:50, Abigail Headroom wrote:> > I''m giving this thread a last chance. I feel stuck and would really > appreciate any hints on how to solve this. >Don''t save changes at all, just persist them in something like memcached until ready? it''s definitely not trivial (for example do you need to worry if the changes made during the edit session don''t apply any more (eg user edits records a,b,c. while they are editing b gets deleted. do you still apply remaining changes to a & c ?) Fred> Basically what I''m looking for is the semantics of a full database > copy > for the duration of the edit session, without having to, ermm.. copy > the > database. > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Frederick Cheung wrote:> Don''t save changes at all, just persist them in something like > memcached until ready?Thanks again for your input, Fred. Yeah.. Working with in-memory objects during the edit session is probably the way to go. I''ll make an attempt to overload ActiveRecord save() etc to see what happens.> do you > need to worry if the changes made during the edit session don''t apply > any more (eg user edits records a,b,c. while they are editing b gets > deleted. do you still apply remaining changes to a & c ?)No, I don''t have to deal with that since two users cannot be in edit mode simultaneously. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---