Re: Database schema

["Alexey Parshin" <alexeyp@gmail.com>]

In any case, that timeout idea is incorrect. Only author(s) should decide - for how long the UMO is locked. If someone locks the UMO and has a bunch of changes, but it took too long and timeout released the lock, then someone else can edit the same UMO. Now, the first editor may ether push the changes, overriding the second editor's changes, or he can receive the error message that he should lock the UMO again and start over. In both cases - it's incorrect.

BTW, I still wanna know - what kind of problem we are trying to solve by timeout? If someone locked the UMO, and he is an author - that's his god-given right. If it's taking him too long - it's his right to do so. If he disappeared from the face of Earth - then other author (if any) or administrator can release the lock. There could be many reason why the UMO editing is delayed, especially if it is a complex UMO, such as verification, review of the changes by other authors, etc..

2007/1/21, 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

-- 
Alexey Parshin,
http://www.sptk.net