MoinMoin: StorageRefactoring/ReName

Semantic

After renaming page A to B

• A does not exist any more
  • old revisions of A are now old revisions of B
• B has the content of A
• info of B shows the revisions of A

Is this supposed to be a problem description? I don't see any problem here.

Test case

Scenarios that might reveal weaknesses of single implementations

1. Scenario
   • rename A to B
   • edit B
   • rename B back to A
   • edit A
2. Scenario
   • rename A to B
   • create A
3. Scenario
   • rename A to B
   • create A
   • delete B
   • rename A to B

Implementations

Move directory

• revisions of A are not longer accessable with their old URL (?action=recall&rev=XXX)

  • Because A does not exists any more, the url changed.

Copy and Delete

• B doesn't have revisions of A

Why?

Extented Copy and Delete

• Copy A to B
  • Meta: "copied from A"
• Delete A
  • new meta: "renamed to B"
• info B reads revs of B
  • sees "copied from A" in first rev
  • reads revs from A and prepends them

If A get recreated info could hide the old revs. (not sure yet if this makes sense)

• How about linking each revision separately? That is much more consistent than doing "prepend maths".

I don't see any reason for this madness.

• You would have to query different items in order to get fundamental information about the requested item. This would be quite complex and slow.

rename by aliasing

• store "aliases: A" in MetaData. A is the first name of that item.

• when renaming to B, either:

  • store "aliases: A,B" in MetaData (item can be found under both old and new name), or

  • store "aliases: B" in MetaData (we don't want old name any longer)

• advantage: aliases can be useful for other stuff (some items simply have multiple equivalent names)
• advantage: easier to process, storage doesn't fragment, subitems don't need to get duplicated

• disadvantage: dict lookup itemname -> storagename

Alias is a good idea, but we already have these, just create a redirect page.

A redirect is currently handled at http level and shows some msg why you got to another URL. An alias is handled internally (at storage level) and stays at the URL and pagename you requested.

We can remove the message or make it a small status message, and there is noting wrong with handling the redirect at the http level.

rename by internal redirect

• rename pagedir A to B
• create new pagedir A with item meta containing "renamedto: B", nothing else
• when requesting A, make storage code jump internally to B

And what happen when A is recreated with new content? There is not need to keep the old name when renaming. If the old name was good, then why the page was renamed?

Basically the the concept of create an alias for rename is broken. Rename should rename, Create Alias should create alias. After rename, the old name should be free, not lead to the new name.

The only real problem I see with rename is existing links to a page in other pages. Those links should be updated as part of the rename.