[Vtigercrm-developers] Has anyone addressed this data overwriting issue?

Mike Crowe mike at mikeandkellycrowe.com
Sat Feb 4 04:45:46 PST 2006


My adodb updates were related to xmlschema, not this issue.

This is an issue where we do not "lock" the record when we load the 
record in edit mode.  The problem is leaving the record and releasing 
the lock.  Determining how/when to do this must be defined.  For 
instance, if you open a record for editing, and then reboot, close, or 
navigate to another record, how do you release the lock?

Mike

Mike Fedyk wrote:
> Jeff Kowalczyk wrote:
>
>   
>> --- Mike Fedyk <mfedyk at mikefedyk.com> wrote:
>>  
>>
>>     
>>>> Mike Crowe has a lot of adodb schema infrastructure that he wanted
>>>> to get in.
>>>>      
>>>>
>>>>         
>>> I want to see this code.  I'm not familiar with adodb right now and if 
>>> there are bug reports we should be able to get this in if it isn't too 
>>> intrusive.
>>>    
>>>
>>>       
>> http://forums.vtiger.com/viewtopic.php?t=1439&highlight=adodb+schema
>>
>> Mike may have made more recent patches than this.
>>  
>>
>>     
>
> Crowe, can you give us an update on this issue?
>
>   
>>  
>>
>>     
>>>> This meant that last committer on a given field wins, but if you didn't
>>>> change a field in your form, you weren't going to write that column, or be
>>>> affected if it changed while your recordset was open.
>>>>      
>>>>
>>>>         
>>> Yes, I was thinking about something just like this for vtiger.
>>>    
>>>
>>>       
>> I would consider any update behaviour beside that a bug, and a potentially
>> dangerous one at that. Is it this way all over vtiger?
>>
>>  
>>
>>     
> I think we should avoid the possibility of overwriting data that the 
> latest saver never even saw.
>
> dkmeans on the forum has proposed "You could I suppose have 3 sets of 
> variables -- the "original" state, the "edited by me" state, and then 
> before you hit save, compare the "original" against the database for 
> anydatabases, and then alert the user -- This record was changed by user 
> X. Continue?"
>
> I think this is a good way to go.  In the future 4.3.x tree we need a 
> way to show the data conflict and allow the user to resolve the conflict.
>
> Fedyk
> _______________________________________________
> vtigercrm-developers mailing list
> vtigercrm-developers at lists.vtigercrm.com
> http://lists.vtigercrm.com/mailman/listinfo/vtigercrm-developers
>   




More information about the vtigercrm-developers mailing list