Hi Sergiu, > On 15 Aug 2016, at 18:18, Sergiu Dumitriu <[email protected]> wrote: > > Why does that value have to be stored in the wiki document?
Sure, we could use another store. However the goal of XWiki is also to provide a generic store which can be used to store metadata (through xobjects) related to wiki pages. And install count for an extension really looks like a good metadata candidate for a wiki page. Using another store would also be more work. So, I’d prefer if we could find a way to support this use case which seems legitimate. We have several such use cases, which consist in having some system user perform modifications to wiki pages: * scheduler which updates scheduled jobs with the last fire time xproperty * this extension scheduler which updates install counts * (I’m sure we have more examples but I can’t find one right now ;)) My personal POV is that long term we should have: * Introduce a proper reserved (you cannot create a user named after it) and virtual “System” user (and don’t use “Admin” or “superadmin” which are users which should be used by admins) * Filter out System user changes by default in Activity Stream, History, etc (with options to display them) * Refactor the Versioning store (and possibly get get rid of JRCS) to have a scalable system which supports an unlimited number of revisions without impacting performances * Add an API to merge several revisions into one (this could be useful for auto save too). This is related to what you called “pseudoversion” too: http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Publication+Workflow+Application > Personally, I'd make it a Computed Field, and always get the current > value from an external service. This has the disadvantage that the > livetable can't filter/order by the number of installations. > > If the cost of fetching data from an external service is a concern, then > add a TTL cache. Thanks -Vincent > On 08/15/2016 06:54 AM, Vincent Massol wrote: >> Hi Thomas and all, >> >> Back from holidays! :) >> >> I’ve noticed that the new feature of counting installed extensions on e.x.o >> is having a drawback: it saturates the activity stream, making it very hard >> to see real edits by users. Every day the scheduler modifies lots of wiki >> pages to set the new install count. See for example: >> http://www.xwiki.org/xwiki/bin/view/Main/News >> >> I think a simple change would be for the scheduler to make modifications as >> minor edits. This should prevent the edits from being visible in the AS. >> >> WDYT? >> >> Now this is going to cause another real issue very soon: pages will soon >> start to have a lot of revisions and we know this is currently a performance >> issue. It’s also hiding real edits in the history making the history a bit >> less clean. >> >> I guess an option would be for the scheduler to delete the last revision >> after it updates a page. Although not very nice, it could work for now. WDYT? >> >> Thanks >> -Vincent > > > -- > Sergiu Dumitriu > http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
