Re: [cowiki-dev] Someone had to set dev.cowiki.org up

Re: your comment below--  I have been thinking about this problem 
(admittedly a dangerous thing...)  Some observations

    * When a new page is created it exists in the node list.
    * When that page is edited, the original page is copied to the
      history list and the new page replaces it.
    * Each time the page is edited, the original is copied to history
      and the new one replaces it in the node list.

So far, so good.  That is exactly what we see when pages are edited.  
Now, the historical records are in a completely different table than the 
current records.  How is it possible for something to move from the 
history list back into the current list?

Answer: some code is executing that shouldn't.  Nothing else could copy 
the old record back from history to the current list.  The only place I 
found that seems to address this functionality is near line 1518 and 
following in class.DocumentDAO.php:

                // Recovery triggered because getNodeById returned false?
                // Does this logic make sense?

                $LastHistNode = $this->getHistNodeForId($Node->get('id'));

                // This is a recover insert: add required fields
                $aInitial = array(
                    'node_id'    => $Node->get('id'),
                    'tree_id'    => $Node->get('treeId'),
                    'rec_state'  => 'R',
                    'author_id'  => $LastHistNode->get('authorId'),
                    'revision'   => $LastHistNode->get('revision') + 1,
                    'created'    => $LastHistNode->get('created'),
                    'sort_order' => $this->getNextSortOrder($Node),
                    'views'      => $LastHistNode->get('views'),
                    'menu'       => $Node->get('menu'),
                    'foot'       => $Node->get('foot')
                );

                // Set further data for insert
                $aInsert = array(
                    'table'  => $this->sNodeTable,
                    'fields' => array_merge($aFields, $aInitial)
                );

                // Execute insert
                $this->Storage->insert($aInsert);

I suspect this is our culprit.  I still haven't figured out how to 
trigger it.

It was a nice little creek in the forest which I sat by, as I read code 
and thought "How would I make this happen on purpose?"  :-)

Paul

Daniel T. Gorski wrote:

>Cave: this might be IMPORTANT:
>
>I have noticed the behaviour concerning the "bad magic bug" on coWiki.org:
>
>It always occured if a "guest user" (and only a guest) changed or created a
>document - then an other "document/page" get magically recovered. This is
>not very new impression, but I thought about this for a while and came to
>the conclusion that the "recovery-methods" provided by Kai Schröder[1]
>should be reviewed, as I am 101% sure that this error wasn't there for
>almost two years before (of course because the code for recovery wasn't
>there), but I have the suspicion that the problem lies somewhere in the
>DocumentDAO class, thats has beend changed and provided by Kai: the recovery
>stuff.
>
>Fortunately you have all the CVS history from the beginning on and you can
>locate these changes made by Kai[1]. 
>
>If the problem is not solved the next weeks (or until the next release), I
>would even suggest to disable these recovery methods for the next release:
>losing documents is very annoying and not worth spreading with a new coWiki.
>
>OTOH, a stress testing or extensively testing coWiki with unit tests (not
>only Archies parser) seems necessary to me.
>
>  
>
>>Besides I'm fighting other dragons for the moment.  Back in a day or so...
>>    
>>
>
>Please do not talk about your wife this way. It's inappropriate ;-D
>  
>
In this case, it's school and job hunting.  :-(

>greetings to you both, Paul & Becky, dtg
>
>[1] I don't want to blame Kai for this behaviour, it is only a suspicion.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
>
>  
>