I like the idea of introducing a creation and last modified
time stamps for nodes in the object table. As, I thought,
Andre pointed out, it makes checking for changes easy,
but I think that in a lot of situations, this provides valueable
information.

Wilbert.
----- Original Message ----- 
From: "Andr� van Toly" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 04, 2003 5:31 PM
Subject: Re: [EDITWIZARD] remaining issues


Kees Jongenburger heeft op dinsdag, 3 jun 2003 om 10:16
(Europe/Amsterdam) het volgende geschreven:

> On Monday 02 June 2003 08:18 pm, Andr� van Toly wrote:
>> Pierre van Rooden heeft op maandag, 2 jun 2003 om 16:21
>> (Europe/Amsterdam) het volgende geschreven:
>>
>> [...]
>>
>>> [1c] Since MMBase has no locking mechanism, the wizard maintains a
>>> 'original data' xml tree. The Dove uses this tree to validate changes
>>> (so if someone changes the object, the wizard issues an error).
>>> Perhaps a less memory-consuming way can be found to check on changes
>>> in an object (so the original data tree is not needed), but I gather
>>> this would either require versioning (or 'last modified dates'), or
>>> another method to make comparison easy (hashcodes?).
>>
>> All nodes in MMBase have at least two fields: number and owner. These
>> are deeply rooted in the core but is it not worth investigating to add
>> an extra field 'updated' or 'modified'? Or would that involve a
>> complete rewrite of MMBase?
> This is quite possible (at least for new installation) and it's a nice
> to have
> but i don't think this solves the problem. it still doesn't allow
> locking.
> it is something like a timestamp field

Some thoughts: I think it is difficult to manage and implement the
locking of a node (when do you lock a node and when will it be
released? setting a lock boolean in the database would require a
database commit while retrieving the node, but when do you know that a
node is being retrieved for editing? put a boolean lock in memory
then?). But it is easier to check whether a node is updated or not (a
check for updated and a commit when you commit the changed node).
Locking a node has to be managed at a low level in MMBase, the same can
be done with a mechanism that checks for an update but doesn't
necessary has to be at a low level. Checking whether a node is updated
could easily be implemented in every kind of editor currently available
in MMBase, also on a voluntary or optional basis.

Kees has a point that you would lose your edits (which you won't when
you lock a node cause you would not be able to edit it), but i believe
that a mechanism with updated or modified fields is easier to implement
in all the current available editors in MMBase.

---Andr�

------------------------------------------->><<---------
Andr� van Toly
http://www.toly.nl
06-27233562



Reply via email to