On Tuesday 03 June 2003 01:42 pm, Pierre van Rooden wrote: > << 1 is it not a good idea to store all this data in de database for the > length of their use? i can imagine the memory use weighs more than the > database overhead > > > I don't think so. You would rather not store temporary data in a database. > I don't agree. I really depends on what you defines as temporary nodes. but my feeling is that the memory consumption of keeping a few nodes in memory should not be a problem anyway
I think we are just thinking the wrong way. if you want to edit a node and be shure that nobody else may edit the same node you have to lock the node before you start editing the node. the way we do it now can not result in a working system. situation 1 (current way dove works): when we commit a node we are somtiime able to detect the node was changed in the meawhile. result -we loose the last commit situation 2(like the bridge works). we don't detect that the node was changed. with a bit of luck not al the fields are overwritten -we loose the first commit > > << 2 am i right those form xml's don't change till the wizard is being > altered (like jsp's) , can't they be cached? >> > > form xmls are a combination of data-being-edited with the wizard sceham. > They change with every invocation of te wizard (in fact, they are > re-created with every call). > > << 2 is it not a good idea to add checkout function to nodes? this will > allso make things easyer? >> yes checkout or clone.... > > There is a sort of thing like that (not really checkout, but you can make > 'temporary'nodes for editing). The main problem of a checkout system is > that this works on one machine only: if you use two servers, they are > unaware of ecach others edits. You might solve that using multicast, but > there is a delay, so it's not really safe. Other problems with temporary nodes is that they do not behave like real nodes and are not included in lists and such. and of course they are in memory > You also need to determine when to release a lock in case someone aborts a > session without properly closing the transaction (either in the editwizards > or another editor). I.e. in the editwizards a session can last an hour - > which means a 'lock' could conceivably last the same length if someone > aborts his editor by (for isnatnce) closing his browser. that's a good thing and you can react on that (maybe tell who was editing the node and show both nodes if they are different
