Re: Database schema

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

There is no need for that. This would be even more
complex then my proposition, without adding any ease of use.

Anatoly Volynets wrote:
> Can it work this way: until, say, there are 3 co-authors locking is not
> enforced and it is after there are more than 3 of them there?
>
> Alexey Parshin wrote:
>   
>> I just spent a really long time building databases where every single
>> transaction is a subject to locking.
>>
>> In the current case, most UMOs should have a single author, so during
>> editing there is no need in overriding the lock. In other cases, we can
>> allow a lock to be shared between all the authors of the object. Allowing
>> anybody but authors to override the lock is incorrect logically.
>>
>> 2007/1/20, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>>     
>>> In massively shared environment locks should be overridable.
>>> I would agree that in reality, if we lock an object to user, not to
>>> session
>>> it should not be a problem 99.9% of time, but for the 0.1% of time
>>> that overriding lock will be needed, it'll be extremely annoying.
>>>
>>> I highly suspect you are very lucky person, and never had to deal
>>> with SCM like MS VSS, or RCS or SCCM, all of which are using
>>> unconditional
>>> locks. Trust me - it's real pain.
>>>
>>> Alexey Parshin wrote:
>>>       
>>>> I agree with the idea of locking. However, what problem exactly you're
>>>> trying to solve with timeout? So far I see more complications due to
>>>> using timeout then any practical use of it.
>>>>
>>>> 2007/1/20, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
>>>> <mailto:ilya@total-knowledge.com>>:
>>>>
>>>>     We can do it in many different ways.
>>>>     Easiest is, of course, a hard-coded value.
>>>>     Next one is a value configurable by admin.
>>>>     Another option is to make it per-user or even per-object
>>>>         
>>> preference,
>>>       
>>>>     with defaults configurable by admin.
>>>>
>>>>     Important thing is not to require user to set this timeout every
>>>>     time he edits an object.
>>>>
>>>>     sergey@total-knowledge.com <mailto:sergey@total-knowledge.com>
>>>>         
>>> wrote:
>>>       
>>>>     >> This solution is way too complex for user, from my perspective.
>>>>     >> And annoying.
>>>>     >>
>>>>     >> Better way, I think, is following use case:
>>>>     >>
>>>>     >> 1. Author locks object for editing
>>>>     >>
>>>>     >
>>>>     > It's not clear if Author sets timeout by himself or UU does it
>>>>     for him
>>>>     > right after step 1.
>>>>     >
>>>>     >
>>>>
>>>>     --
>>>>     Ilya A. Volynets-Evenbakh
>>>>     Total Knowledge. CTO
>>>>     http://www.total-knowledge.com
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alexey Parshin,
>>>> http://www.sptk.net
>>>>         
>>> -- 
>>> Ilya A. Volynets-Evenbakh
>>> Total Knowledge. CTO
>>> http://www.total-knowledge.com
>>>
>>>
>>>       
>>     
>
>   

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com