On Sat, Dec 03, 2016 at 12:56:43PM -0500, Tedd Sperling wrote: > > Paul: > > > On Dec 1, 2016, at 1:11 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > > I think you're *far* better off doing your "locking" by record. > > Yes, I agree. Now that I look back on what I’ve written, I‘ve been mixing locking tables with locking records. I’ve always meant the end result would be locking records — no real reason to lock tables. I only started experimenting with locking table to see if I could get locking to work, which it didn’t in php. My end solution would have been locking records and not tables. > > > But this whole sequence is why I've never tried to implement any kind of > > a scheme like this. The idea of taking a run at a record (after edit), > > compare content, presenting a "diff", running at a record again, > > possibly taking another "diff", etc. would be maddening. The repetitive > > processing of a single record, possibly ad infinitum, would be > > "cost-prohibitive", not to mention technically unbelievably complex. > > Imagine that for every "Save" screen, you have to do an "Are you sure?" > > screen. > > Not exactly that. > > What I am currently focusing my efforts on is: > > Let’s say two (or more) users open the same record at the same time. > > At the start of their editing — ALL users scripts read the current record timestamp (i.e., the time the record was last modified by the last user). That timestamp becomes pivotal in permitting future saves — let’s call it T. > > When any of these users attempt to save their data, their script looks again at the record’s timestamp. > > If the record’s timestamp is the same as the one they started with (i.e., T) , then save is permitted without any interference whatsoever and a new record timestamp is established. The user never knows a "compare and verify" has been preformed. > > However, if the record’s timestamp is different than their T, then the record they are working on has changed. Their script then compares the current record data with the data provided by the user AND establishes a new record timestamp and a new T. > > If the data is the same, then no need to save and the user moves on as is they had saved. > > If the data is not the same, then the user is shown ONLY the data that is different between the record’s current data and the data the user entered and asked “Which data do you want to save?”. > > After the user makes their choices and attempts to save again, the record’s timestamp is again read and compared to T. If they are the same, then the data is saved and a new record timestamp is established. > > However, if the timestamp has changed again, then the user goes through another “Which data do you want to save?” procedure. > > This “compare and verify" procedure repeats until all users have their say. > > Note: This method does not require every user’s save to go through a multi-confirm save. It only requires the “compare and verify" IF there is a conflict in data as suggested by new and old timestamps. > > I think this will work — what do you think? I like this. It sounds economical (at least so far as you can be when going in this direction), and it looks like the programmer is mostly staying out of the user's way, always a good idea. You didn't mention the case where the two users start out with different timestamps (because someone else has gotten in there and changed the data as well). But it's relatively simple to follow your logic and see that the result would be rational in the same way as the rest of your example is. Another issue comes to mind in this day of multiple simultaneous platforms. A user "Ezekial" begins to edit the record on his tablet and *silently* abandons the effort. Later, he goes to edit the record on his smartphone. This time, he actually goes through with the edit. Comes back to what he was doing on his tablet the next day. Hopefully, he abandons the effort, knowing he completed it on his smartphone the day before. Still seems like it would work out, but it's worth keeping in mind. Of course, I don't envy you trying to implement this. And I'm not sure that it scales. All of a sudden, a simple save turns into at least three record accesses (initial fetch, later verify, final save), possibly many more. If I were implementing this, I would make it derive from the database class as a child class. Maybe call it "safety_save". That way, the coder could opt to use it or not, depending on the importance of the data and the interest in seeing that the data as stored was as "right" as it could be. Some data wouldn't need it, like the user's address data from a form, since it's highly unlikely anyone else would be in there trying to change it, and if they did, how much would it matter? Thinking some more about it, it's possible you could do a lot of this as AJAX. Although, I envy you doing it that way even less. Paul > > Cheers, > > tedd > > _______________ > tedd sperling > tedd@xxxxxxxxxxxx > > > -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
