> On Dec 5, 2016, at 9:50 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > <snip> >> >> I think this will work — what do you think? > > 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. That shouldn’t happen. Each user accesses *the* record that is uniquely tied to a timestamp. Until the record is changed (or in process of editing), the timestamp will not changed. Maybe I’ll have to use a transaction to assure data-timestamp integrity, but a timestamp should be uniquely tied to the data of the record. > 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. You can imagine all sorts of possibilities, but the process will still follow a series of binary operations: Either "Ezekiai” saves the data, or he does not. If he saves the data (and there no conflict), then the data is saved and a new timestamp is generated and recorded. If he does not choose to save the data, then the record’s timestamp remains as it was. If he tries to save the data and there is a conflict, then he must resolve the differences — or — not. In both cases a new timestamp is generated. If he resolves the conflict, then the data is saved and a new timestamp is generated. If he resolves (or not) the conflict, and does not save the data then the timestamp (set by him) remains. At any time during any of the above operation another user enters the process, the new user will follow the same process AND will use the current timestamp for reading; and another for resolving a conflict; or another after a permitted save. None of these timestamps will cause any problems for any other user. If you will plot out all possibilities, you’ll see that tying data to a timestamp will work regardless of how many users access the same record at ANY time (or so I think). > 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. I’ve already written and tested the code under my limited resources, but I have not tested the process under high traffic. The only point where I think the process might fail is when two users are actually and simultaneously writing to the same record at the exact same time — thus, I may need to use a transaction (BEGIN/COMMIT/ROLLBACK) to resolve that possibility (unless I don’t understand transactions). > 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? The “resolve” portion of the save actually shows the user both the user’s data and the record’s data where there is conflict. The data is presented via name of the field, the user’s data for that field, and the record’s data for that field with radio buttons for the user to select “which one?”. After which, upon clicking save the new revisions are compared with the current record’s timestamp, which may have changed during “which one?” editing. If so, then rinse and repeat another “compare and verify” procedure until a proper save is permitted. ------ > 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. That may be the best solution. I have written an AJAX/PHP script that uses javascript triggers (onClick, onBlur, onSelect, onChange, etc.) to write the “the user’s field of interest” change of data to the record and then read back in the entire record to automagically update the data in the form the user is viewing. Additionally, I can make the instant update of that field a transaction so no conflict should occur. Furthermore, even other users will see updates to their forms when they edit a field. You see, each “read the record” is generated when a user triggers a javascript event. Each user is only (at most) an event away from seeing the current record’s data. The only downsides I imagine of this AJAX process will be as the user is editing a record, the data might instantly change because other user(s) are editing the same record/field — that might be deserting when the field the user is editing suddenly changes — or — when the user is editing the record and assumes the data he has already inspected hasn’t changed. But this downside could be lessened by highlighting changes in the record since the user started editing. For example, showing all the data that has changed since the user first read the record be shown in red. In any event, the above are the two "solutions" I am currently working on. Thanks for your review and comment. Cheers, tedd _______________ tedd sperling tedd@xxxxxxxxxxxx -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
