Also wiki uploading is not simple, there could be several use scenarios.
- Remove current wiki content and upload new one. Something like similar "backup" and "restore" option in databases, new wiki content is a clone of the content read from source file.
- Merge existing content with the new one. But what to do if there exists a page with the same name. May be the solution is to add an "overwrite" option, globally set or per case. But there is a risk that wiki content could be a chaotic mesh of old and new pages.
- Merge content and in the case of the pages with the same name page content read from source is added as a new version to the existing. It sounds much better then before but there is a risk that the number of version will double, quadruple etc after every upload.
- Merge content and in the case of the pages with the same page recognize also page version. Overwrite page content at the page and version level.
- Merge content and add only the last version from the input.
- ....
There could be a lot of scenarios. Finally I decided to implement the scenario number 4. I cannot tell for certain if it is the best one but for the time being it seems to me as being the most sound.
The next and very important task is to change the database schema and reduce the number of reads by adding a cache for pages. The current implementation is very inefficient in terms of number of reads and Google App Engine quota for free access is hit very quickly causing the freezing the application for 24 hours until quotas are reset.
Brak komentarzy:
Prześlij komentarz